1 – Présentation du protocole HSTS
La grande majorité des requêtes effectuées sur Internet reposent sur le protocole HTTP ou sa version HTTPS protégée via TLS.
Si rien n’empêche une tierce partie en position «d’homme du milieu» d’écouter, voire d’altérer les communications HTTP, ce n’est pas le cas du protocole HTTPS. Dans ce cadre, TLS assure alors l’intégrité et le chiffrement des données ainsi que l’authentification du serveur au moyen de certificats X.509.
Malgré l’emploi du protocole HTTPS par le serveur, le client reste sujet à deux attaques :
- une tierce partie peut utiliser le protocole HTTP pour les communications avec le client puis transférer celles-ci vers le serveur au moyen du protocole HTTPS. Ce type d’attaque est possible si le client n’impose pas la mise en œuvre du protocole HTTPS ;
- une tierce partie peut utiliser le protocole HTTPS pour les communications avec le client, déchiffrer celles-ci, puis transférer les communications vers le serveur au moyen du protocole HTTPS. Ce type d’attaque est possible si le client ne valide pas correctement le certificat d’authentification du serveur ou que l’attaquant s’est procuré un certificat permettant de se faire passer pour le serveur (par exemple en récupérant un certificat frauduleux auprès d’une autorité compromise ou en installant une fausse autorité de certification).
Afin de se prémunir de ces attaques, deux technologies peuvent être employées :
- HTTP Strict Transport Security ou « HSTS » ;
- Certificate pinning.
La technologie HSTS permet d’éviter en partie la première menace décrite en imposant au client de n’utiliser que le protocole HTTPS pour toutes les connexions avec le serveur.
Dès lors, toute communication HTTP vers le serveur sera refusée automatiquement par le client. Notons néanmoins qu’un attaquant interceptant le tout premier échange entre le client et le serveur, soit la requête définissant l’utilisation du HSTS, est en mesure de jouer le premier scénario d’attaque.
Le certificate pinning permet, quant à lui :
- de détecter le changement de certificat du serveur ;
- de s’assurer que l’autorité de certification ayant signé le certificat du serveur est bien celle attendue.
La deuxième mesure prend la forme de listes associant des domaines, des URL à des autorités de certification. Ces listes peuvent être intégrées aux produits, configurées manuellement ou spécifiées au moyen de politiques HPKP (HTTP Public Key Pinning).
Ainsi tout attaquant ayant réussi, d’une manière ou d’une autre, à obtenir un certificat valide pour le serveur cible (c’est-à-dire avec le bon Common Name) sera dans l’incapacité d’intercepter les communications, car ce certificat ne sera pas signé par l’autorité attendue. L’utilisation du certificate pinning s’avère donc être complémentaire à l’emploi du HSTS.
L’utilisation de la technologie HSTS par un serveur Apache est possible après avoir ajouté au fichier de configuration les lignes suivantes :
LoadModule headers_module modules/mod_headers.so<VirtualHost ip_concernee:port> #la valeur de max-age correspond ici a 180 jours Header always set Strict-Transport-Security « max-age=15552001; includeSubdomains; » </VirtualHost>
L’utilisation du certificate pinning est, quant à elle, intégrée à Firefox ou Chrome ou peut être mise en œuvre par EMET pour les systèmes Windows.
Rappel des avis émis
Dans la période du 22 au 28 août 2016, le CERT-FR a émis les publications suivantes :
- CERTFR-2016-AVI-285 : Multiples vulnérabilités dans les produits NVIDIA
- CERTFR-2016-AVI-286 : Multiples vulnérabilités dans les produits VMware
- CERTFR-2016-AVI-287 : Vulnérabilité dans les noyaux Linux de Red Hat
- CERTFR-2016-AVI-288 : Multiples vulnérabilités dans Apple iOS
Durant la même période, les publications suivantes ont été mises à jour :
- CERTFR-2016-AVI-283 : Vulnérabilité dans le micrologiciel Fortigate de Fortinet
- CERTFR-2016-AVI-284 : Multiples vulnérabilités dans les produits Cisco
