12. User Agent Implementation Advice (Conseils d'Implémentation de l'Agent Utilisateur)
Cette section est non normative.
Pour fournir une protection plus efficace aux utilisateurs et aux sites Web, et pour le contrôle de la gestion de leur cache de politique HSTS des UA, les implémenteurs de UA devraient envisager d'inclure des fonctionnalités telles que les suivantes :
12.1. No User Recourse (Aucun Recours Utilisateur)
L'établissement d'une connexion sécurisée échouant sur tout avertissement ou erreur (conformément à la section 8.4 ("Errors in Secure Transport Establishment")) devrait être complété avec "aucun recours utilisateur (no user recourse)". Cela signifie qu'un dialogue ne devrait pas être présenté à l'utilisateur lui permettant de choisir de continuer. Au lieu de cela, cela devrait ressembler au traitement des erreurs de serveur, où l'utilisateur ne peut rien faire de plus en termes d'interaction avec l'application Web cible, à part attendre et réessayer.
Essentiellement, "tout avertissement ou erreur" signifie tout ce qui ferait qu'une implémentation de UA annoncerait à l'utilisateur que quelque chose n'est pas tout à fait correct avec l'établissement de la connexion.
Ne pas le faire, c'est-à-dire permettre un recours utilisateur, par exemple "cliquer sur le dialogue d'avertissement/erreur", est une recette pour une attaque de l'homme du milieu. Si une application Web émet une politique HSTS, elle choisit alors implicitement l'approche "aucun recours utilisateur", c'est-à-dire que toutes les erreurs ou avertissements de certificat entraînent la terminaison de la connexion, sans possibilité de "tromper" l'utilisateur pour qu'il prenne une mauvaise décision et se mette en danger.
12.2. User-Declared HSTS Policy (Politique HSTS Déclarée par l'Utilisateur)
Une politique HSTS déclarée par l'utilisateur est la capacité pour un utilisateur de déclarer explicitement qu'un nom de domaine donné représente un hôte HSTS, l'amorçant ainsi comme hôte HSTS connu avant toute interaction réelle avec lui. Cela aiderait à prévenir la vulnérabilité de bootstrap MITM, comme discuté dans la section 14.6 ("Bootstrap MITM Vulnerability").
NOTE : Une telle fonctionnalité est difficile à bien faire sur une base par site. Voir la discussion sur les "règles de réécriture" dans la section 5.5 de [ForceHTTPS]. Par exemple, un site Web arbitraire peut ne pas concrétiser tous ses URI avec le schéma "https", donc si le UA tente d'accéder exclusivement au site en utilisant uniquement de tels URI, il pourrait "casser". Notez également que cette fonctionnalité compléterait, mais serait indépendante de, la fonctionnalité de "liste préchargée HSTS" (voir section 12.3).
12.3. HSTS Pre-Loaded List (Liste Préchargée HSTS)
Une liste préchargée HSTS est une facilité par laquelle les administrateurs de sites Web peuvent faire en sorte que les fournisseurs de UA pré-configurent la politique HSTS de leur site de manière similaire à la façon dont les certificats CA racine sont intégrés dans les navigateurs "en usine" -- la soi-disant "liste préchargée". Cela aiderait à prévenir la vulnérabilité de bootstrap MITM (section 14.6).
NOTE : Une telle facilité compléterait la fonctionnalité de "politique HSTS déclarée par l'utilisateur" (section 12.2).
12.4. Disallow Mixed Security Context Loads (Interdire les Chargements de Contexte de Sécurité Mixte)
Un chargement de "contexte de sécurité mixte (mixed security context)" se produit lorsqu'une ressource d'application Web obtenue par un UA via un transport sécurisé entraîne ensuite l'obtention d'une ou plusieurs autres ressources sans utiliser de transport sécurisé. Ceci est également généralement appelé un chargement de "contenu mixte (mixed content)" (voir section 5.3 ("Mixed Content") de [W3C.REC-wsc-ui-20100812]).
NOTE : Pour fournir une cohérence comportementale entre les implémentations de UA, le concept de contexte de sécurité mixte nécessitera davantage de travail de normalisation, par exemple, définir plus clairement les termes et définir des comportements spécifiques qui y sont liés.
12.5. HSTS Policy Deletion (Suppression de Politique HSTS)
La suppression de politique HSTS est la capacité de supprimer la politique HSTS mise en cache du UA sur une base par hôte HSTS.
NOTE : L'ajout d'une telle fonctionnalité devrait être fait très soigneusement à la fois dans l'interface utilisateur et les sens de sécurité. La suppression d'une entrée en cache d'un hôte HSTS connu devrait être une action très délibérée et réfléchie -- ce ne devrait pas être quelque chose que les utilisateurs ont l'habitude de faire de manière routinière : par exemple, juste "cliquer" pour faire le travail. De plus, les implémentations doivent se prémunir contre la possibilité qu'un attaquant injecte du code (par exemple, ECMAscript) dans le UA qui supprimerait silencieusement et programmatiquement des entrées du cache d'hôtes HSTS connus du UA.