2. Overview (Aperçu)

Cette section discute des cas d'usage, résume la politique HSTS et poursuit avec une discussion du modèle de menace, des menaces non traitées et des exigences dérivées.

2.1 Use Cases (Cas d'usage)

Le cas d'usage de haut niveau est une combinaison de :

• Les utilisateurs de navigateurs web qui souhaitent interagir avec divers sites web (certains arbitraires, certains connus) de manière sécurisée.

• Les déployeurs de sites web qui souhaitent offrir leurs sites de la manière la plus sécurisée possible, à la fois pour eux-mêmes et pour leurs utilisateurs.

2.2 HTTP Strict Transport Security Policy Effects (Effets de la politique HTTP Strict Transport Security)

Les effets de la politique HSTS, lorsqu'elle est appliquée dans les interactions des UA conformes avec un hôte de ressource web qui implémente une telle politique (un hôte HSTS (HSTS Host)), sont résumés comme suit :

1. Les UA transforment les références URI non sécurisées vers un hôte HSTS en références URI sécurisées avant de les déréférencer.

2. L'UA termine toute tentative de connexion de transport sécurisé lors de toutes les erreurs ou avertissements de transport sécurisé.

2.3 Threat Model (Modèle de menace)

HSTS concerne trois classes de menaces : les attaquants réseau passifs (Passive Network Attackers), les attaquants réseau actifs (Active Network Attackers) et les développeurs web imparfaits (Imperfect Web Developers). Cependant, il n'est explicitement pas un remède pour deux autres classes de menaces : le phishing et les malwares. Les menaces traitées et non traitées sont brièvement discutées ci-dessous.

Les lecteurs peuvent se référer à la section 2 de [ForceHTTPS] pour plus de détails et de références.

2.3.1 Threats Addressed (Menaces traitées)

2.3.1.1 Passive Network Attackers (Attaquants réseau passifs)

Lorsqu'un utilisateur navigue sur le web sur un réseau sans fil local (par exemple, un réseau local sans fil basé sur 802.11), un attaquant à proximité peut éventuellement écouter les connexions basées sur le protocole Internet non chiffrées de l'utilisateur, telles que HTTP, que le réseau sans fil local lui-même soit sécurisé ou non [BeckTews09]. Les kits d'outils de reniflage sans fil librement disponibles (par exemple, [Aircrack-ng]) permettent de telles attaques d'écoute passives, même si le réseau sans fil local fonctionne de manière sécurisée. Un attaquant réseau passif utilisant de tels outils peut voler des identifiants/cookies de session et détourner la session web de l'utilisateur en obtenant des cookies contenant des informations d'authentification [ForceHTTPS]. Par exemple, il existe des outils largement disponibles, tels que Firesheep (une extension de navigateur web) [Firesheep], qui permettent à leurs utilisateurs d'obtenir les cookies de session d'autres utilisateurs locaux pour diverses applications web.

Pour atténuer de telles menaces, certains sites web prennent en charge (mais n'imposent généralement pas) l'accès utilisant un transport sécurisé de bout en bout - par exemple, signalé par des URI construits avec le schéma "https" [RFC2818]. Cela peut amener les utilisateurs à supposer que l'accès à de tels services en utilisant un transport sécurisé les protège des attaquants réseau passifs. Malheureusement, ce n'est souvent pas le cas en pratique, car les identifiants de session sont souvent stockés dans des cookies non sécurisés pour permettre l'interopérabilité avec des versions de services offerts sur un transport non sécurisé (un "cookie sécurisé" est un cookie contenant l'attribut "Secure" [RFC6265]). Par exemple, si un site web (tel qu'un service de messagerie) stocke un identifiant de session dans un cookie non sécurisé, cela permet à un attaquant de détourner la session de l'utilisateur si l'UA de l'utilisateur effectue une seule requête HTTP non sécurisée vers le site.

2.3.1.2 Active Network Attackers (Attaquants réseau actifs)

Un attaquant déterminé peut monter une attaque active, soit en usurpant l'identité du serveur DNS de l'utilisateur, soit, sur un réseau sans fil, en usurpant des trames réseau ou en fournissant un point d'accès jumeau maléfique au nom similaire. Si l'utilisateur est derrière un routeur domestique sans fil, un attaquant peut tenter de reconfigurer le routeur en utilisant des mots de passe par défaut et d'autres vulnérabilités. Certains sites web, tels que les banques, s'appuient sur un transport sécurisé de bout en bout pour se protéger eux-mêmes et leurs utilisateurs de tels attaquants actifs. Malheureusement, les navigateurs permettent à leurs utilisateurs de facilement se désengager de ces protections afin d'être utilisables pour les sites qui déploient le transport sécurisé de manière incorrecte, par exemple en générant et en auto-signant leurs propres certificats (plutôt qu'en distribuant également leur certificat d'autorité de certification (Certification Authority, CA) aux navigateurs de leurs utilisateurs).

2.3.1.3 Web Site Development and Deployment Bugs (Bugs de développement et de déploiement de sites web)

La sécurité d'un site par ailleurs uniformément sécurisé (c'est-à-dire dont tout le contenu est matérialisé via des URI "https") peut être complètement compromise par un attaquant actif exploitant une simple erreur, comme le chargement d'une feuille de style en cascade (Cascading Style Sheet) ou d'un film SWF (Shockwave Flash) via une connexion non sécurisée (les feuilles de style en cascade et les films SWF peuvent tous deux scripter la page d'incorporation, un fait qui surprend de nombreux développeurs web, et, de plus, certains navigateurs n'émettent pas un avertissement dit de "contenu mixte" lorsque les fichiers SWF sont incorporés via des connexions non sécurisées). Même si les développeurs d'un site examinent attentivement leur page de connexion pour le "contenu mixte", une seule incorporation non sécurisée n'importe où sur l'ensemble du site web compromet la sécurité de leur page de connexion car un attaquant peut scripter (c'est-à-dire contrôler) la page de connexion en injectant du code (par exemple, un script) dans une autre page de site chargée de manière non sécurisée.

NOTE : Le terme "contenu mixte (Mixed content)" utilisé ci-dessus (voir également la section 5.3 de [W3C.REC-wsc-ui-20100812]) fait référence à la notion étiquetée comme "contexte de sécurité mixte (Mixed Security Context)" dans cette spécification et ne doit pas être confondu avec le même terme "contenu mixte" utilisé dans le contexte des langages de balisage tels que XML et HTML.

2.3.2 Threats Not Addressed (Menaces non traitées)

2.3.2.1 Phishing

Les attaques de phishing se produisent lorsqu'un attaquant sollicite des informations d'authentification de l'utilisateur en hébergeant un faux site web sur un domaine distinct du vrai site web, peut-être en dirigeant le trafic vers le faux site en envoyant un lien par e-mail. Les attaques de phishing peuvent être très efficaces car les utilisateurs ont du mal à distinguer les vrais sites web des faux sites web. HSTS n'est pas en soi une défense contre le phishing ; il complète plutôt de nombreuses défenses anti-phishing existantes en instruisant le navigateur de protéger l'intégrité de la session et les jetons d'authentification de longue durée [ForceHTTPS].

2.3.2.2 Malware and Browser Vulnerabilities (Malwares et vulnérabilités du navigateur)

Comme HSTS est implémenté en tant que mécanisme de sécurité du navigateur, il repose sur la fiabilité du système de l'utilisateur pour protéger les sessions. Du code malveillant s'exécutant sur le système de l'utilisateur peut compromettre les sessions de navigation, avec ou sans HSTS.

2.4 Requirements (Exigences)

Cette section identifie et énumère diverses exigences dérivées des cas d'usage et menaces ci-dessus, et liste à la fois les exigences de base détaillées que HTTP Strict Transport Security traite ainsi que les exigences auxiliaires qui ne sont pas directement traitées.

2.4.1 Overall Requirement (Exigence globale)

• Minimiser le risque pour les utilisateurs de navigateurs web et les déployeurs de sites web découlant d'attaquants réseau passifs et actifs, de bugs de développement et de déploiement de sites web, et d'actions utilisateur non sécurisées.

2.4.1.1 Detailed Core Requirements (Exigences de base détaillées)

Ces exigences de base découlent de l'exigence globale et sont traitées dans cette spécification.

1. Les sites web doivent pouvoir déclarer aux UA qu'ils doivent être accédés en utilisant une politique de sécurité stricte.

2. Les sites web doivent pouvoir instruire les UA qui les contactent de manière non sécurisée de le faire de manière sécurisée.

3. Les UA doivent conserver des données persistantes sur les sites web qui signalent l'activation de la politique de sécurité stricte, pendant des durées déclarées par les sites web. De plus, les UA doivent mettre en cache des informations de politique de sécurité stricte "fraîches" pour permettre aux sites web de les mettre à jour.

4. Les UA doivent réécrire tous les chargements URI UA "http" non sécurisés pour utiliser le schéma sécurisé "https" pour les sites web avec la politique de sécurité stricte activée.

5. Les administrateurs de sites web doivent pouvoir signaler l'application de la politique de sécurité stricte aux sous-domaines de domaines de niveau supérieur pour lesquels la politique de sécurité stricte est activée, et les UA doivent appliquer une telle politique.

   Par exemple, example.com et foo.example.com peuvent tous deux définir une politique pour bar.foo.example.com.

6. Les UA doivent interdire l'application de politique de sécurité par des domaines avec politique de sécurité stricte activée aux domaines pairs et/ou aux domaines de niveau supérieur.

   Par exemple, ni bar.foo.example.com ni foo.example.com ne peuvent définir de politique pour example.com, et bar.foo.example.com ne peut pas définir de politique pour foo.example.com. De plus, foo.example.com ne peut pas définir de politique pour sibling.example.com.

7. Les UA doivent empêcher les utilisateurs de "cliquer à travers" les avertissements de sécurité. L'arrêt des tentatives de connexion face à des exceptions de transport sécurisé est acceptable. Voir également la section 12.1, "No User Recourse".

NOTE : Cette spécification ne traite pas en particulier de la manière de sécuriser uniformément le premier contact pour satisfaire la première exigence de base ci-dessus (voir la section 14.6, "Bootstrap MITM Vulnerability"). Cela pourrait être traité dans les révisions futures de cette spécification ou dans une autre spécification. Notez également qu'il existe des moyens par lesquels les implémentations UA peuvent traiter plus pleinement la première exigence de base ; voir la section 12, "User Agent Implementation Advice".

2.4.1.2 Detailed Ancillary Requirements (Exigences auxiliaires détaillées)

Ces exigences auxiliaires découlent également de l'exigence globale. Elles ne sont pas traitées de manière normative dans cette spécification mais pourraient être satisfaites par les implémentations UA à la discrétion de l'implémenteur, bien que les satisfaire puisse être complexe.

1. Interdire les chargements de "contexte de sécurité mixte" (voir la section 2.3.1.3).

2. Faciliter la déclaration par l'utilisateur de sites web avec politique de sécurité stricte activée, que le site signale ou non la politique HSTS.