I. Présentation

Dans cet article, nous allons nous intéresser au mécanisme et à la fonction de l'HSTS - HTTP Strict Transport Security. Nous finirons par un point de détail qui peut poser problème lors de l'utilisation d'un proxy (type BurpSuite) lorsque HSTS est implémenté sur un site web.

II. HSTS - Qu'est-ce que c'est ?

Le but principale d'HSTS est de renforcé la sécurité d'un site web et de ses utilisateur via deux actions :

• Remplacer tous les liens non sécurisés (HTTP) par des liens sécurisés (HTTPS). Le site devient alors full-HTTPS
• Afficher un message d'erreur en cas de connexion non sécurisée, exemple : certificat auto-signé ou signé par une une autorité de certification (CA) non reconnue par le navigateur

Il arrive en effet que la sécurité des transmissions effectuées via HTTPS soit mise à mal, et ceci via différents scénarios :

• Lorsqu'un attaquant souhaite écouter les transmissions réseau et que l'HTTPS est utilisé, il peut mettre en place une attaque MITM (Man-In-The-Middle), puis SSLStrip. Concrètement, cette attaque consiste à se positionner entre les deux parties de la communication (client-serveur) puis à remplacer à la volée le certificat utilisé entre le client et le serveur. En imposant son propre certificat au client, l'attaquant est alors en mesure de lire les informations (déchiffrées) envoyées par le client. Côté client, cette attaque peut être détectée par un changement du certificat utilisé lors des transmission HTTPS. Celui-ci devient un certificat auto-signé, que tous les navigateurs mettent en avant en forçant une validation explicite de l'utilisateur.

• Dans d'autres scénarios, on retrouve des cas où le cookie de session utilisé n'implémente pas le flag Secure (qui impose un envoi des cookies uniquement par connexion sécurisée - HTTPS). Je vous oriente vers mon précédent article pour plus d'information (Sécurité des sites web : L’utilité des flags Secure et HttpOnly). Lorsqu'un utilisateur est en possession d'un cookie de session et qu'il transmet au serveur ce cookie via une requête HTTP, alors le cookie de session est envoyé en clair sur le réseau.

Nous venons ici de voir les deux contextes où HSTS peut être mis en place afin de renforcer la sécurité d'un site web et de ses visiteurs.

• Dans le contexte du MITM/SSLStrip, HSTS va permet au navigateur de strictement refuser la connexion. Concrètement, cela va se traduire par une impossibilité pour l'utilisateur d'effectuer les actions manuelles permettant l'utilisation du certificat auto-signé. Si le certificat est auto-signé ou signé par un CA non reconnu par le navigateur, alors la communication est impossible.

• Dans le cas d'une transmission HTTP, HSTS va ordonner au navigateur de leur interdire tout échange pour le domaine/site concerné. Outre l'utilisation du flag "Secure" qui permet de résoudre ce problème, HSTS permet alors de protéger les cookies contre les écoutes réseaux lors des transmissions HTTP, toutes les requêtes HTTP seront remplacées par des requêtes HTTPS avant leur envoie. Ainsi même si le site web est techniquement disponible en HTTP (port 80), le navigateur utilisera forcément l'HTTPS.

Note : Tous les navigateurs possèdent une liste des autorités de certifications de confiance, lorsqu'un site web présente un certificat signé par l'une de ces autorités de certification (CA), alors le certificat est dit "de confiance", autrement, le navigateur émet une alerte.

III. Fonctionnement de HSTS

HSTS est défini par le serveur, c'est une instruction que le serveur web va passer au navigateur du visiteur. De son côté, le navigateur saura alors de quelle manière interagir avec le serveur. En exemple, voici l'entête HTTP réponse d'un serveur configuré pour utiliser HSTS :

Ici, la directive "includeSubDomains", permet de protéger également les sous-domaines avec HSTS, la directive "max-age" permet d'indiquer pour combien de temps à partir de la réception de cette réponse les "règles" HSTS sont à respecter pour le navigateur. Dans le contexte de l'exemple, le navigateur n'acceptera pas d'effectuer une requête en HTTP jusqu'à 31536000 secondes après la réception de cette réponse. Au delà, la directive HSTS sera "oubliée" et le navigateur acceptera d'effectuer des requêtes HTTP ou de proposer la validation d'un certificat auto-signé.

Pour cette raison, la directive HSTS est généralement incluse dans chaque réponse du serveur web, et non pas juste la première de l'échange.

Et la directive preload ?

Parlons un peu du "preload" au niveau HSTS. Si l'on analyse bien la situation, un navigateur qui n'a jamais fait de requête vers le site abcd.fr ne sait pas si celui-ci utilise HSTS ou non, il est donc susceptible d'y faire une requête via un canal non sécurisé (HTTP ou certificat Auto-signé). Les navigateurs ont alors mis en place une "preload list" intégrée aux navigateurs, qui savent alors si, pour un site donné, ceux-ci doivent utiliser HSTS ou non. Concrètement, il s'agit d'une liste "hard-codée" que l'on trouve dans les navigateurs, à l'image des autorités de certification. Pour information, il est possible d'inscrire sont site à cette preload list ici : https://hstspreload.appspot.com/.

e lien amène vers la liste gérée pour le navigateur Chrome, cette liste est elle même incluse dans la preload-list des navigateur concurrents.

Sachez toutefois que tous les navigateurs ne prennent pas en charge HSTS, voici une liste, récupérée au moment de l'écriture de cette article, qui détaille les navigateurs et versions compatibles :

Concrètement, le RFC  697 HTTP Strict Transport Security (HSTS) de novembre 2012 ne fait pas mention de la présence de la directive "preload" dans le header HTTP réponse du serveur, son rôle n'est donc pas clair et je suis preneur d'informations à ce sujet 🙂

Le cas BurpSuite + HSTS

Lorsque l'on utilise BurpSuite pour le deboggage ou lors d'un test d'intrusion web, il est possible de rencontre un problème si le site web visé implémente HSTS. Plus précisément, un problème de ce type (cas burpSuite + google.fr) :

Ici, et pour ceux qui ont bien compris les notions précédentes de cet article, le message est clair : HSTS est implémenté pour le site visité et Firefox ne peut établir de connexion dans un contexte non sécurisé (pas en https OU avec un certificat non signé par une autorité de certification de confiance).

Pour saisir pourquoi ce problème peut survenir dans les cas d'utilisation d'un proxy, il faut revoir rapidement le fonctionnement du proxy dans un contexte HTTPS.

Note : Ce contexte peut apparaitre dans le cas d'un Proxy SSL web, qui vise alors le trafic des utilisateur vers internet, ou alors un proxy "local" type BurpSuite ou similaire.

Lorsque l'on fait passer un trafic auprès d'un outil capable de l'analyse (Proxy/sniffeur réseau), aucun problème n'est à traiter lorsque celui-ci est en clair. Cependant, lorsque ce trafic est chiffré (via SSL, donc en HTTPS dans un contexte web), l'outil qui s'interpose entre le client et le serveur membre de la communication n'est plus capable de comprendre ce qui passe sur le réseau.

Afin de pouvoir comprendre ce trafic chiffrer, un proxy ou un analyseur réseau doit s'interposer également dans l'échange chiffré de la manière suivante :

On voit ici que le certificat utilisé entre le serveur et le Proxy (qui intercepte puis retransmet les requêtes des clients web) utilise le certificat signé du serveur web comme le ferait un client web sans présence du proxy. En revanche le trafic entre le client et le proxy utilise le certificat du proxy, ainsi le proxy peut déchiffrer le trafic en provenance et direction du client. Hors, ce certificat est dans la grande majorité des cas auto-signé ou signé par une autorité de certification locale et non inclue dans la liste par défaut des CA dans les navigateurs. Pour cette raison, la présence d'un proxy peut amener les utilisateurs à cet affichage :
L'utilisateur peut alors valider en tout conscience l’utilisation  d'un certificat signé par une autorité de certification qui n'est pas de confiance (dite "non trustée" en franglais).

C'est là qu'HSTS peut devenir bloquant, nous avons vu qu'en présence d'une implémentation HSTS, le navigateur doit refuser toute connexion dans un contexte non sécurisé, hors la présence d'un certificat signé par un CA qui n'est pas de confiance est un cas de figure de transmission non sécurisée. Dans un contexte HSTS, il nous est tout simplement pas autorisé d'ajouter un exception au navigateur, car cela irait à l'encontre de l'instruction HSTS fixée par le serveur web.

A noter que d'autres proxys dans le même type que BurpSuite ou même des proxys d'entreprise (Squid) sont aussi concernés.

Il est alors nécessaire de faire croire à notre navigateur que l'autorité de certification qui a signé le certificat utilisé par notre proxy est de confiance, cela en l'ajoutant à notre liste des autorités de certifications (CA) de confiance du navigateur.

IV. Résoudre le problème de l'HSTS lors de l'utilisation d'un proxy

Cette manipulation est documentée pour tous les navigateurs, je vous montre néanmoins la manière de procéder pour l'extraction dans BurpSuite et l'ajout dans Firefox :

Il faut commencer par aller récupérer le certificat du CA de BuprSuite, après avoir démarré BurpSuite puis avoir configuré Firefox pour passer au travers celui-ci, il faut saisir "http://burp" dans le navigateur :

Ensuite, il faut cliquer sur "CA Certificat" puis télécharger le fichier "cacert.der" :

Ce certificat devra ensuite être  ajouté dans Firefox, pour cela, aller dans "Options", puis dans "Avancé" > "Certificats" > "Afficher les Certificats" > "Autorités" > "Importer", nous allons alors devoir aller chercher le certificat nouvellement exporté de BurpSuite et cocher "Confirmer cette AC pour identifier des sites web." :

Une fois cela fait, Firefox considérera BurpSuite comme une autorité de certification de confiance, en conséquence, les conditions requises pour communiquer avec un site web ayant implémenté HSTS seront satisfaites. Voici un exemple de site possédant une implémentation HSTS dont les flux sont passés au travers BurpSuite :

Cette procédure peut être opérée sur tous les navigateurs.

Du point de vu sécurité, ce "bypass HSTS" est toutefois difficile à mettre en place si l'on souhaite effectuer une attaque par Man-In-The-Middle, en effet, il faut déjà avoir un accès au poste utilisateur pour effectuer la procédure d'ajout du certificat CA.

Voici une ressource complémentaire sur le fonctionnement et l'implémentation de l’analyse des flux HTTPS en entreprise, des recommandations de l'ANSSI qui détailles comment implémenter un proxy d'entreprise en position Man-In-The-Middle et interceptant le trafic HTTPS : Recommandations de sécurité concernant l’analyse des flux HTTPS

N'hésitez pas à partager vos recommandations et vos avis dans les commentaires !