• Perspective
Publié le 20 avril 2018

HSTS, ou comment mitiger une attaque SSL Stripping

1. HTTP vs HTTPS

La sécurité d’une application repose en partie sur la protection de ses données et doit être conforme à plusieurs critères de sécurité. L’un de ces critères est la confidentialité des informations qui transitent entre le client et le serveur.

La confidentialité des données assure que les données ne sont accessibles qu’aux personnes autorisées, les empêchant d’être lues par des personnes tierces.

Pour garantir cela, le chiffrement permet de mettre en place une protection contre l’interception des données empêchant ainsi l’attaquant d’accéder à ces dernières en clair.

Dans la pratique, la confidentialité des données d’un site web est assurée par le chiffrement en combinant le protocole HTTP avec un certificat SSL/TLS.

HTTP et HTTPS sont deux protocoles de la couche « application » du modèle OSI :

  • HTTP est un protocole non sécurisé assurant le transfert des données en clair entre le client et le serveur
  • HTTPS quant à lui utilise un tunnel sécurisé (SSL/TLS) pour le transfert et la réception des données (d’où le suffixe « S » rajouté à HTTP).

Cependant, dans la plupart des cas, la mise en place de ce protocole sécurisé se fait par le biais d’une redirection 301 (Moved Permanently) ou une redirection permanente de HTTP vers HTTPS. Ce type de redirection induit un risque d’attaque appelée « SSL Stripping ».

 

2. L’attaque « SSL Stripping »

L’attaque « SSL Stripping » a été introduite en 2009 par le chercheur américain Moxie Marlinspike. Elle consiste en l’interception du trafic transitant en clair entre le client et le serveur sécurisé.

Il s’agit d’une attaque de type « Homme du milieu » permettant à une personne malveillante de transférer la requête de la victime vers sa machine à la suite d’une première connexion non sécurisée au serveur.

Un scénario d’attaque simple :

  • Une personne malveillante conduit une attaque de type « homme du milieu » en créant un point d’accès Wifi auquel doit se connecter la machine de la victime,
  • Une fois connectée au Wifi, la victime accède à l’application cible en HTTP : exemple.fr/login,
  • L’attaquant reçoit cette requête et la transmet par la suite au serveur sécurisé qui, lui, répondra à la requête par https://exemple.fr/login. Le tunnel de communications est ainsi sécurisé entre le serveur et l’attaquant, alors que le trafic entre ce dernier et la victime ne l’est pas,
  • L’attaquant reçoit la réponse du serveur en HTTPS et la modifie pour la transmettre en HTTP à la victime : http://exemple.fr/login. Par conséquent, toutes les communications entre la victime et l’attaquant seront envoyées en clair et ce dernier peut donc intercepter les données d’authentification du client,
  • La victime renseigne son login et mot de passe sur le site non sécurisé,
  • L’attaquant reçoit les identifiants de la victime en clair, ainsi que toute donnée sensible envoyée par la victime.

Le schéma suivant résume le déroulement de l’attaque :

BSSI-SSL_Stripping

Cependant, pour le bon déroulement d’une attaque SSL Stripping, certains prérequis doivent être présents :

  • L’accès en HTTP sur le site de la victime doit être possible,
  • L’attaquant doit préalablement être positionné entre le client et le serveur, et ceci en réalisant une attaque de type « Homme du milieu » en étant, par exemple, leur point d’accès Wifi.

Pour mitiger l’attaque, une solution triviale serait de n’utiliser que le protocole HTTPS et ainsi interdire l’utilisation du protocole HTTP. Or, pour une question d’accessibilité, les sites sont souvent accédés via le protocole HTTP en priorité, en optant pour une redirection vers HTTPS afin d’éviter l’affichage d’une page d’erreur à un utilisateur qui essaye d’accéder à www.exemple.fr/login.

Cependant, cette façon de faire rend le site web vulnérable aux attaques SSL Stripping.

Pour pallier ça, le mécanisme HSTS a vu le jour en 2010.

 

3. HTTP Strict Transport Security (HSTS), le Supercookie

HTTP Strict Transport Security (HSTS) ou Supercookie, est un mécanisme qui exige au navigateur de ne communiquer avec le serveur que via le protocole HTTPS.

A l’issue d’une première communication entre le site et le serveur, le navigateur enregistre l’en-tête HSTS envoyé dans la réponse du serveur (à l’image d’un cookie persistant). Ainsi, lorsque l’utilisateur visite le site une deuxième fois, le navigateur impose automatiquement que toutes les communications soient réalisées en HTTPS avec le serveur.

Une bonne configuration de ce mécanisme exige toutefois un certain nombre de conditions :

  • L’utilisation d’un certificat SSL/TLS valide,
  • La présence d’une redirection de HTTP vers HTTPS (301 ou permanente),
  • L’envoi d’un attribut « Strict Transport Security» dans l’en-tête de la réponse du serveur,
  • La définition, à minima, de deux paramètres :
    • includeSubdomains pour que les sous-domaines du site soient également concernés par la protection HSTS ;
    • max-age pour définir la durée pendant laquelle le HSTS reste valide, une valeur de 2 ans (63072000 secondes) est recommandée.

En-tête d’une réponse envoyée par un serveur web comprenant le paramètre HSTS

Cependant, HSTS tel qu’il a été configuré ci-dessus, assure la confidentialité des données tant que l’attaquant n’a pas intercepté le trafic lors de la première connexion transitant via le protocole HTTP.

 

4. La liste « preload HSTS »

Le préenregistrement HSTS permet d’indiquer au navigateur qu’une liste d’hôtes souhaite forcer l’utilisation du protocole HTTPS, afin de ne communiquer avec le serveur que via un canal sécurisé, et ce dès le premier accès au site web.

Cette liste est compilée par Google et est utilisée par les navigateurs Chrome, Firefox et Safari. Ainsi, le navigateur sait préalablement si un site nécessite une politique HSTS ou pas avant toute communication avec le serveur. Cela permet de mitiger fortement le risque d’une interception des données en clair par un attaquant.

Afin d’enregistrer son domaine sur la liste « Preload HSTS », un site est mis à disposition aux utilisateurs souhaitant inclure leurs sites : https://hstspreload.org/.

Toutefois, et afin de s’assurer qu’il s’agit bien de l’auteur du domaine qui souhaite l’intégrer dans la liste « preload HSTS », le paramètre « preload » doit être rajouté à l’en-tête HSTS dans la réponse du serveur comme suit :

add_header Strict-Transport-Security « max-age=63072000 ; includeSubDomains ; preload » ;

En ajoutant le paramètre « preload » au sein de l’en-tête HSTS, le site https://hstspreload.org sait que la personne a souhaité ajouter son domaine à la liste avec son consentement, et lui valide sa demande d’ajout. Ainsi les navigateurs utilisant la liste « preload HSTS » forcent toutes les communications en provenance de ce domaine à utiliser HTTPS dès la première communication.

 

5. Conclusion

Malgré les conséquences qu’une attaque de type « SSL Stripping » peut avoir sur un serveur Web, elle reste toutefois difficile à mettre en œuvre, aux vues des conditions qui doivent être présentes pour exploiter ce type de vulnérabilité.

Néanmoins, l’en-tête HSTS rajoute une protection majeure contre une interception malveillante des données envoyées en clair, sachant qu’en présence d’un certificat SSL/TLS valide et d’une redirection HTTPS, sa configuration ne nécessite que deux étapes supplémentaires : l’ajout de l’en-tête « Strict Transport Security » et la déclaration du domaine auprès du projet « preload HSTS » géré par Google.

Article rédigé par
Imane Belhaous