"Google.com" n'est pas protégé par HSTS?

Oct 07 2020

Problème:

Souvent, les gens entrent google.comdirectement dans la barre d'adresse du navigateur sans inclure le http://ou les https://préfixes.

En utilisant Chrome DevTools sur une nouvelle session de navigation privée, j'ai exécuté l'expérience suivante:

PAS:
-----------------
Saisissez "google.com" (ou de manière équivalente "http://google.com") directement dans le champ 
la barre d'adresse du navigateur.

 1. Demande: http://google.com;
    Réponse: Code d'état: 301 déplacé définitivement
              Emplacement: http://www.google.com/
              Cache-Control: public, max-age = 2592000

 2. Demande: http://www.google.com;
    Réponse: Code d'état: 302 trouvé
              Emplacement: https://www.google.com/?gws_rd=ssl

 3. Demande: https://www.google.com/?gws_rd=ssl;
    Réponse: Code d'état: 200
              strict-transport-security: max-age = 31536000

REMARQUES: 
-----------------
* Pour obtenir les mêmes résultats, démarrez une nouvelle session de navigation privée (fermez toutes les 
  fenêtres et ouvrez-en une nouvelle). Si vous avez déjà une fenêtre de navigation privée, ouvrez-vous
  pourrait ne pas obtenir les mêmes résultats. Faire cocher "désactiver le cache" n'aidera pas non plus.

* Si vous répétez l'expérience à partir de la même session de navigation privée, vous remarquerez le 
  différences suivantes depuis la première fois:

    * Requête 1: Si "désactiver le cache" est décoché (ce qui imite le navigateur 
                 comportement lors d'une utilisation normale), la réponse proviendra du cache 
                 en raison de la réponse "Cache-Control: public, max-age = 2592000" 
                 header renvoyé la première fois. Cela signifie que le http
                 la demande n'est pas envoyée (même si elle affiche toujours un 301 
                 réponse), ce qui est probablement une bonne chose.

    * Requête 2: La réponse sera un 307 au lieu de 302. Cela est dû au 
                 "strict-transport-security: max-age = 31536000" renvoyé par le 
                 troisième demande la première fois. C'est le cas quel que soit
                 de savoir si "désactiver le cache" est coché ou non.

* Une fois que le navigateur prend conscience qu'un domaine est protégé par HSTS (soit via le 
  Préchargement HSTS ou l'en-tête de réponse STS) le navigateur redirigera "en interne"
  toutes les requêtes http à https pour ce domaine. Ces redirections sont affichées dans
  onglet réseau comme "Code d'état: 307 Redirection interne" (ce qui est en quelque sorte 
  trompeur car il semble que la réponse provienne d'un serveur lorsque 
  réalité, tout se passe dans le navigateur. Notez qu'il n'y a pas
  "Adresse distante" dans la section "Général" pour ces demandes

* Un autre moyen (peut-être plus simple) de vérifier si un domaine est protégé par HSTS est de 
  entrer le domaine dans https://hstspreload.org/ mais il y a des mises en garde! 
  https://hstspreload.org/ signale ce qui suit pour "www.google.com":
     - "Erreur de réponse: aucun en-tête HSTS n'est présent sur la réponse."
     - "` http: // www.google.com` ne redirige pas vers `https: // www.google.com`"
  Aucun de ces résultats n'est cohérent avec ce qui est observé dans le réseau 
  onglet dans l'expérience ci-dessus! J'ai envoyé la liste de diffusion hstspreload et
  a reçu la réponse intéressante suivante: "Le serveur pour 
  http://www.google.com ne redirige pas toujours http vers https, c'est pourquoi 
  une erreur apparaît. Par exemple, si j'utilise curl, je ne reçois pas la redirection. "
-----------------

Problèmes de confidentialité / sécurité:

La demande initiale à google.comest effectuée httpcar elle google.comn'est pas incluse dans la liste de préchargement HSTS. Cette requête est vulnérable aux attaques MITM.
À aucun moment le navigateur n'est redirigé vers https://google.com, par conséquent, l'en-tête STS n'est jamais défini pour ce domaine. Cela signifie que même les futures demandes google.comne seront pas protégées par HSTS et peuvent donc être vulnérables aux attaques MITM!

Il convient de noter que l'en - tête de réponse cache-control max-age = 2592000 (30 jours) inclus dans la redirection 301 initiale semble fournir un niveau de protection similaire à celui fourni par HSTS, car il entraîne http://google.comle traitement "interne" des futures requêtes. par le cache (et surtout redirigé vers le domaine protégé par HSTS "www.google.com"). D'autre part, le contrôle du cachemax-age est configuré pour expirer après 30 jours (beaucoup plus court que ce que le HSTS max-ageest généralement défini) et, plus important encore, contrairement au HSTS max-age qui est actualisé à chaque httpsdemande adressée à un domaine compatible HSTS, le cache-control max agen'est pas actualisé tant qu'une nouvelle httpdemande non sécurisée n'est pas effectuée! Cela signifie que vos demandes google.compeuvent être interceptées aussi souvent qu'une fois tous les 30 jours.
La demande à www.google.comest faite via http et est vulnérable aux attaques MITM. Au moins dans ce cas, la réponse est une redirection 302 vers https://www.google.comlaquelle inclut l'en-tête STS. Cela signifie que toutes les demandes ultérieures http://www.google.comseront redirigées «en interne» vers https par le navigateur, comme indiqué ci-dessus, le HSTS max-ageest actualisé à chaque demande. Ainsi, tant que votre navigateur fait une demande https://www.google.comau moins une fois par an (ce à quoi l' max-ageexpiration STS est définie), toutes les demandes adressées à ce domaine seront protégées par HSTS.

TL; DR - "google.com" n'est pas protégé par HSTS et il semble que les demandes puissent potentiellement faire l'objet d'attaques MITM aussi souvent qu'une fois tous les 30 jours (ou plus souvent si le cache est effacé ou si le mode de navigation privée est utilisé).

Cela peut ne pas être aussi grave que cela puisse paraître pour les raisons suivantes:

Tous les cookies importants pour .google.comet ont www.google.comtrès certainement le securedrapeau défini.
google.comsemble ne rien faire de plus que de rediriger vers, www.google.comdonc toute demande de google.comne serait de manière réaliste que vers le chemin racine (par conséquent, l'URL elle-même ne serait pas intéressante pour un espion).
Les sous-domaines Google qui envoient / reçoivent des données plus sensibles (par exemple gmail.com, accounts.google.com ...) sont sur la liste de préchargement HSTS. Ainsi, même si un attaquant configure quelque chose comme sslsplit et qu'un utilisateur se retrouve sur un attaquant contrôlé http://www.google.com(ce qui est déjà assez difficile à extraire car il oblige l'utilisateur à ne pas remarquer l'icône de cadenas manquante), les domaines préchargés HSTS seraient toujours protégés . Un attaquant devrait donc empêcher un utilisateur de naviguer vers l'un de ces sous-domaines.

Des questions

Quelles pourraient être les raisons pour lesquelles Google n'a pas activé HSTS pour google.com
Quelles pourraient être les raisons pour lesquelles Google a uniquement activé l'en-tête STS www.google.commais n'a pas ajouté ce domaine à la liste de préchargement HSTS?

Réponses

28 EsaJokinen Oct 07 2020 at 13:35

Situation actuelle

Il est vrai qu'à partir d'octobre 2020, Google n'a pas activé le HSTS google.com, mais uniquement activé www.google.com, et effectue la redirection d'abord vers wwwpuis vers https://. Même s'il y avait un en-tête HSTS activé google.com, le navigateur ne le verrait pas et pourrait le mettre en cache. Seul www.google.comest protégé par HSTS.

Les meilleures pratiques

Il est également recommandé, en tant que bonnes pratiques, par exemple par le Conseil fédéral du CIO :

Dans sa forme la plus forte et la plus recommandée, la politique HSTS inclut tous les sous-domaines et indique une volonté d'être «préchargée» dans les navigateurs:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 
Lorsque vous utilisez ce formulaire, gardez à l'esprit:

La politique doit être déployée à https://domain.gov, non https://www.domain.gov.

Tous les sous-domaines associés au domaine parent doivent prendre en charge HTTPS. (Ils ne doivent pas chacun avoir leur propre politique HSTS.)

OWASP HTTP Strict Transport Security Cheat Sheet ajoute (également noté dans la RFC 6797, 14.4 ):

Les cookies peuvent être manipulés à partir de sous-domaines, donc le fait d'omettre l' includeSubDomainsoption autorise un large éventail d'attaques liées aux cookies que HSTS empêcherait autrement en exigeant un certificat valide pour un sous-domaine. S'assurer que l'indicateur sécurisé est défini sur tous les cookies empêchera également certaines, mais pas toutes, les mêmes attaques.

Cela ne peut être réalisé qu'en redirigeant d'abord vers HTTPS.

Pourquoi?

Cependant, nous ne pouvons que dire ce qui serait mieux, mais nous ne pouvons pas expliquer pourquoi certains ne suivent pas ces lignes directrices. Seul Google sait pourquoi ils l'ont implémenté de cette façon. Ce n'est pas un manque de connaissances et de capacités, comme ils l'ont déjà fait pour, par exemple gmail.com, qui est actuellement sur la liste de préchargement HSTS.

Vous pouvez vous rapprocher de votre réponse en lisant le livre Bringing HSTS de Jay Brown sur www.google.com sur le blog de sécurité Google. À partir de cet article de juillet 2016, nous pouvons découvrir que c'est intentionnel, en raison de la complexité de l'énorme site, et pour la rétrocompatibilité avec les services hérités .