En internaute averti, vous avez pris l’habitude de vous connecter en HTTPS aux sites sensibles, et de vérifier la présence du petit cadenas à côté de la barre d’adresse, mais cela est-il vraiment suffisant ? Certaines implémentations imparfaites de HTTPS peuvent exposer les données échangées, c’est pourquoi un mécanisme de sécurité supplémentaire a été normalisé en fin d’année dernière, HTTP Strict Transport Security.
Pourquoi a-t-on besoin de HSTS ?
Malheureusement, l’utilisation de HTTPS n’est souvent pas exclusive, ouvrant la voie à trois types de menaces :
- Attaques réseau passives sur des flux non-chiffrés
Il arrive fréquemment que seule une partie des requêtes au serveur web soient chiffrées, par exemple l’authentification. Une fois authentifié, les requêtes suivantes sont en clair. Un attaquant capable d’intercepter les flux réseau (sur un Wifi ouvert, au Starbucks, par exemple), pourra alors analyser les requêtes non-chiffrées, qui contiennent les cookies de session de l’utilisateur. Il pourra ainsi usurper son identité.
- Attaques réseau actives pour détourner le trafic et l’intercepter
Il n’est pas rare de rencontrer des sites proposant une connexion sécurisée mais également une connexion HTTP traditionnelle. Il est alors possible, pour un attaquant capable d’intercepter les flux réseau, de modifier à la volée les données envoyées par le site et de remplacer les liens « https://www.site.com » par des liens vers la version en clair « http://www.site.com ». Des outils permettent d’automatiser cette tâche, comme sslstrip : à nouveau l’attaquant pourra intercepter les cookies et usurper l’identité de la victime. L’attaquant pourrait aussi bien tenter de faire accepter à l’utilisateur un certificat invalide, afin de pouvoir déchiffrer les échanges SSL à la volée.
- Erreurs de développement
Il est également possible que, volontairement ou non, certaines requêtes soient effectuées en clair, par exemple pour charger des images ou un contenu vidéo. Si les images sont hébergées sur le même serveur, les cookies seront envoyés avec la requête et là encore, l’attaquant pourra dérober les cookies et usurper l’identité de la victime.
La solution proposée par HSTS : forcer l’utilisation de HTTPS
HSTS se propose de parer à ce type d’attaques en permettant aux sites web d’indiquer au navigateur qu’il ne doit accepter d’ouvrir que des liens HTTPS vers ce site.
Pour cela, un en-tête HTTP spécifique doit être envoyé au navigateur, qui n’acceptera alors que des liens https:// pour le site en question, et ce pour un temps donné.
De plus, si une erreur de validation de certificat survenait, le navigateur refuserait d’ouvrir la page en question ; en cas d’utilisation de HSTS, l’utilisateur n’a plus la possibilité de passer outre un message d’erreur de validation du certificat : voilà une avancée judicieuse ! HSTS permet donc un premier niveau de protection contre les attaques de type Man-in-the-middle (homme du milieu).
Implémenter HSTS en ajoutant les bons en-têtes
La syntaxe de l’en-tête HTTP est la suivante :
Strict-Transport-Security: max-age=XXX; includeSubDomains
Où :
- Strict-Transport-Security : indique l’utilisation de HSTS
- max-age= : définit la période durant laquelle le navigateur doit forcer l’utilisation de HTTPS, en secondes
- includeSubdomains : permet d’indiquer que la politique s’applique également à l’ensemble des sous-domaines ; cette directive est optionnelle
Dans le cas d’un serveur web Apache, il convient d’insérer les commandes suivantes dans la configuration du site :
Header set Strict-Transport-Security "max-age=XXX"
Header append Strict-Transport-Security includeSubDomains
Il est également conseillé de paramétrer la directive « max-age » de manière dynamique, de façon à la faire coïncider avec la date d’expiration du certificat
HSTS recommande également l’utilisation d’une liste prédéfinie de domaine HSTS par les navigateurs (comme Gmail, Facebook, etc …). Ainsi, on couvre le risque de la première connexion non-chiffrée.
Il est important de noter que les en-têtes HSTS ne sont pris en compte par les navigateurs que si le certificat présenté par le site est signé par une autorité de certification racine présente dans le magasin de certificats, excluant de fait le cas des certificats auto-signés.
Tous les navigateurs sont-ils compatibles HSTS ?
Les mécanismes HSTS sont supportés depuis plusieurs années par Chrome, Firefox et Opéra, qui intègrent désormais une liste par défaut de sites HSTS.
En revanche, les navigateurs Internet Explorer de Microsoft et Safari d’Apple sont à la traîne et n’implémentent pas encore ces protections.
HSTS apporte donc une avancée significative dans la sécurisation des échanges sur Internet, et ce de manière transparente pour le grand public. En imposant la sécurité (en ne leur proposant pas d’accepter un certificat invalide), on se prémunit d’un maillon faible, l’utilisateur, qui peut permettre la réalisation d’attaques de type man-in-the-middle comme ce fut récemment le cas pour le site Github en Chine.
Cependant, d’autres menaces subsistent : on pense notamment aux fréquentes faiblesses dans le choix des protocoles et algorithmes de chiffrement. De plus, la problématique des autorités de certification, qui sont garantes des identités sur internet, reste ouverte, comme le rappellent les cas de Diginotar ou plus récemment de Turktrust.
La sécurisation des échanges sur internet reste une problématique qui requiert de l’expertise dans son implémentation, ainsi que des contrôles réguliers pour assurer la confidentialité et l’intégrité des données échangées vis-à-vis des nouvelles menaces.
