Pourquoi utiliser HTTPS Everywhere lorsque nous avons des navigateurs pris en charge par HSTS?
Je sais que le protocole par défaut du navigateur pour accéder à n'importe quel site est http:// quand https:// n'est pas explicitement mentionné, mais même si nous naviguons sur un site Web, disons www.facebook.com, l'en-tête de réponse des serveurs Facebook aurait HSTS mentionné et notre navigateur nous dirigerait de http:// à https:// alors pourquoi avons-nous besoin d'un autre plugin pour le faire alors que le navigateur lui-même le fait pour l'utilisateur? Quel est le but de HTTPS Everywhere lorsque notre navigateur fait son travail par défaut.
même si nous naviguons sur un site Web, par exemple www.facebook.com, l'en-tête de réponse des serveurs Facebook mentionnerait HSTS
J'ai fait une demande de curl à http://www.facebook.com et voici ce que j'ai obtenu:
< HTTP/1.1 302 Found
< Location: https://www.facebook.com/
< Content-Type: text/html
< X-FB-Debug: zgK/A+8XSlghi/vWvAivsZ04gawpdr+3BuO7yuQaKDdrP/+B14oSVDSreHh0GbchyNPnav39pQq9Zgw5mSXX5A==
< Date: Sat, 29 Apr 2017 19:23:25 GMT
< Connection: keep-alive
< Content-Length: 0
Comme vous pouvez le voir, il n'y a pas d'en-tête HSTS ici, car selon sa spécification (RFC6797) :
Un hôte HSTS NE DOIT PAS inclure le champ d'en-tête STS dans les réponses HTTP transmises via un transport non sécurisé.
les navigateurs Web ignorent également les en-têtes HSTS dans les réponses HTTP:
Remarque: L'en-tête Strict-Transport-Security est ignoré par le navigateur lorsque votre site est accessible via HTTP; En effet, un attaquant peut intercepter les connexions HTTP et injecter l'en-tête ou le supprimer. Lorsque votre site est accessible via HTTPS sans erreur de certificat, le navigateur sait que votre site est compatible HTTPS et honorera l'en-tête Strict-Transport-Security.
Le but de HSTS est de dire au client de NE PAS basculer vers HTTP une fois qu'il a accédé à un site Web via HTTPS, et non l'inverse. De Wikipedia :
HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité Web qui aide à protéger les sites Web contre les attaques de déclassement de protocole et le détournement de cookies.
attaque de rétrogradation du protocole :
Une attaque de rétrogradation est une forme d'attaque d'un système informatique ou d'un protocole de communication qui lui fait abandonner un mode de fonctionnement de haute qualité (par exemple une connexion cryptée) au profit d'un mode de fonctionnement ancien et de moindre qualité (par exemple en texte clair) qui est là pour la compatibilité descendante avec les anciens systèmes.
Un en-tête HSTS n'est donc pas utilisé pour rediriger une nouvelle connexion HTTP vers HTTPS, mais plutôt pour empêcher un navigateur de faire des requêtes HTTP vers un site HTTPS existant.
Le plugin HTTPS Everywhere , d'autre part, garantit que le navigateur Web établit des connexions HTTPS avec des sites Web qui prennent en charge HTTPS, mais sont également accessibles via HTTP.
De nombreux sites sur le Web offrent une prise en charge limitée du cryptage via HTTPS, mais rendent son utilisation difficile. Par exemple, ils peuvent par défaut utiliser HTTP non chiffré ou remplir des pages chiffrées avec des liens qui renvoient au site non chiffré. L'extension HTTPS Everywhere résout ces problèmes en utilisant une technologie intelligente pour réécrire les requêtes vers ces sites vers HTTPS.
HSTS utilise un modèle Trust on First Use . Si votre première connexion au site a déjà été compromise, il est possible que vous ne receviez pas d'erreur HSTS lors des demandes suivantes.
Le HTTPS Everywhere bouche ce trou, en faisant savoir à votre navigateur que le site est un site HTTPS uniquement dès la première connexion.
De plus, certains sites Web n'annoncent pas d'en-tête HSTS même lorsqu'ils prennent en charge HTTPS. Ou ils peuvent avoir leur HTTPS dans un domaine/chemin différent (par exemple http://www.example.com mais https://secure.example.com), HTTPS Everywhere tente de résoudre ces situations en réécrivant les URL du site.
HTTPS Everywhere est côté client et HSTS est côté serveur.
La réponse est donc que HTTPS Everywhere doit se défendre dans les cas où le serveur ne définit pas d'en-tête HSTS.
HSTS est à la discrétion de l'exploitant du site Web. Ils doivent décider si les avantages de sécurité du HTTPS obligatoire valent la charge supplémentaire du serveur, le blocage des utilisateurs qui ne peuvent pas utiliser le HTTPS et le rendu des procurations de mise en cache inefficaces. HTTPS obligatoire est une condition préalable pour HSTS.
De nombreux sites proposent HTTPS en option, mais le fait de l'utiliser ou non est normalement choisi non par l'utilisateur final mais par la personne fournissant un lien ou une URL. HTTPS Everywhere permet aux utilisateurs d'utiliser HTTPS sur ces sites, même lorsque le lien ou l'URL tapée utilise HTTP.
Comme de plus en plus de sites rendent le HTTPS obligatoire et introduisent le HSTS pour réduire le risque de sécurité des redirections en clair, il y aura moins besoin de "HTTPS partout", mais jusqu'à/à moins que tous les sites qui proposent le HTTPS le fassent, ce sera toujours un plugin utile.
La question repose sur de fausses prémisses.
... si nous naviguons sur un site Web, par exemple www.facebook.com, l'en-tête de réponse des serveurs Facebook aurait mentionné HSTS et notre navigateur nous dirigerait de
http://àhttps://...
ce n'est pas vrai*. Bien que le Strict-Transport-Security header est un en-tête HTTP, la spécification HSTS exige que les serveurs l'incluent uniquement dans les réponses qui sont envoyées sur un canal crypté, et oblige les clients à l'ignorer s'il est envoyé sur un canal non crypté. De RFC 6797 :
Hôte de sécurité de transport strict HTTP: est un hôte conforme implémentant les aspects du serveur HTTP de la stratégie HSTS. Cela signifie qu'un hôte HSTS renvoie le champ d'en-tête de réponse HTTP "Strict-Transport-Security" dans ses messages de réponse HTTP envoyés via le transport sécurisé.
...
Un hôte HTTP se déclare hôte HSTS en émettant aux UA une politique HSTS, qui est représentée et transmise via le champ d'en-tête de réponse HTTP Strict-Transport-Security via un transport sécurisé (par exemple, TLS).
...
Un hôte HSTS NE DOIT PAS inclure le champ d'en-tête STS dans les réponses HTTP transmises via un transport non sécurisé.
...
Si une réponse HTTP est reçue via un transport non sécurisé, l'agent d'utilisateur DOIT ignorer tout champ d'en-tête STS actuel.
* Ok, j'exclus la possibilité que le serveur de Facebook et votre navigateur violent la spécification HSTS. Et il est vrai qu'un serveur bien configuré avec HSTS sera généralement également configuré pour ne pas écouter sur le port 80 ou envoyer une redirection permanente vers une URL HTTPS. Mais voir la section 7.2 de la RFC sur les limites de cela.
Je vois qu'aucune des réponses n'a encore abordé le préchargement HSTS. Pour résumer: les mises en garde mentionnées dans les réponses existantes, telles que @ Lie Ryan :
HSTS utilise un modèle Trust on First Use . Si votre première connexion au site a déjà été compromise, il est possible que vous ne receviez pas d'erreur HSTS lors des demandes suivantes.
(…)
De plus, certains sites Web n'annoncent pas d'en-tête HSTS même lorsqu'ils prennent en charge HTTPS.
ne s'appliquent pas aux sites Web qui sont préchargés ; c'est-à-dire qu'ils figurent sur une liste intégrée au navigateur Web. Les sites de cette liste, comme avec HTTPS Everywhere, seront toujours réécrits en HTTPS, même lors de la première visite.
Pour cette raison, les responsables de HTTPS Everywhere ont décidé que les sites Web de la liste de préchargement ne seront pas ajoutés à (et peuvent être supprimés) de la base de données HTTPS Everywhere des URI à réécrire.
De nombreux domaines n'ont pas HSTS configuré correctement. Par exemple, Google a HSTS sur www.google.com et ses sous-domaines, mais pas sur google.com et ses sous-domaines. Par conséquent, HSTS n'est pas appliqué sur mail.google.com ou drive.google.com suite à la visite https://google.com ou https://www.google.com
La raison pour laquelle Google a une telle configuration est complexe.Les conditions requises pour figurer sur la liste de préchargement Chrome HSTS sont que vous avez HSTS pour un domaine et ses sous-domaines. Je suppose que Google a des fonctionnalités internes et peut-être publiques -facing services qui ne fonctionnent pas sur HTTPS. Donc, HSTS pour tous les sous-domaines de Google.com romprait ces services. HSTS pour tous les domaines www.google.com ne couvre vraiment que www.google.com, car il n'a pas de sous-domaines à * .www.google.com.
Cependant, HTTPS Everywhere peut avoir des règles beaucoup plus complexes que HSTS qui permettent de tels cas d'utilisation complexes.
J'utilise HTTPS Everywhere spécifiquement pour Stack Exchange lui-même. La dernière fois que j'ai vérifié (il y a plusieurs mois), il n'utilisait pas HSTS et ne redirigeait même pas de HTTP vers HTTPS. Cependant, il a fourni HTTPS, donc le module complémentaire m'a sauvé de l'écoute potentielle.
Quant à Stack Exchange, la situation peut avoir changé maintenant.