HSTS : comment fonctionne l’extension d‘HTTPS ?
De plus en plus de fournisseurs sur Internet s’efforcent de faciliter un accès sécurisé aux contenus en ligne pour les internautes. Le protocole de chiffrement TLS (Transport Layer Security) a été établi pour l’utilisation sur le Web, son prédécesseur SSL (Secure Sockets Layer) est quant à lui beaucoup plus connu. Tandis que des connexions vers des sites Internet via HTTP (Hypertext Transfer Protocol) s’effectuent sans chiffrement, le protocole réseau HTTPS (« Hypertext Transfer Protocol Secure » ou « Hypertext Transfer Protocol over SSL/TLS ») offre la possibilité de sécuriser le trafic de données sur le Web grâce au chiffrement SSL/TLS.
Même Google, le géant du Web, donne le bon exemple en proposant ses services Web très fréquentés exclusivement avec le chiffrement SSL/TLS. Depuis Août 2014, HTTPS est même devenu un facteur de classement de l’algorithme de référencement naturel (organique). C’est pourquoi l’importance d’utilisation d’un protocole de sécurisation SSL/TLS pour les opérateurs de sites Web a ainsi fortement augmentée. Cependant, une sécurité fiable n‘est pas offerte dans la configuration standard d‘HTTPS. Les experts en IT découvrent toujours des lacunes en matière de sécurité. Les attaques de l’homme du milieu sont particulièrement dangereuses, elles permettent aux hackers de saper le chiffrement SSL/TLS. Ce n’est que depuis 2012 qu’il existe avec HSTS un mécanisme de sécurité pour les connexions HTTPS, notamment contre les attaques de ce type.
Les vulnérabilités de la technologie HTTPS
Lorsqu’un site Web est accessible via le protocole réseau HTTPS et un certificat SSL/TLS fiable, ce type de transport chiffré est généralement sécurisé. Cependant, dans le passé, des attaques répétées contre les organismes de certification ont eu pour conséquence la délivrance d’un grand nombre de certificats non sécurisés. De plus, des habitudes d’utilisation largement répandues et l’inattention générale dans le traitement des connexions chiffrées offrent de nombreux angles d’attaques pour les l’hameçonnage (pishing) et les attaques de l’homme du milieu (man in the middle attack).
Redirection de HTTP vers HTTPS
Rarement, les internautes saisissent de manière complète les URL. A la place, les adresses Internet sont réduites à leur domaine. Le protocole réseau HTTPS, censé sécuriser la connexion chiffrée, est ainsi souvent laissé de côté. Par exemple, si un internaute entre seulement exemple.com dans la barre d’adresse de son navigateur au lieu de https://exemple.com, le navigateur va convertir automatiquement la requête de recherche pour qu’elle soit interprétée comme le protocole réseau standard pour l’accès aux pages Web : HTTP.
example.com -> http://example.com
Si la page cible se trouve sur un site Web chiffré, elle ne s’ouvre pas tant que le serveur ne redirige pas HTTP vers HTTPS
http://example.com -> https://example.com
Ainsi, une connexion chiffrée est finalement établie, mais le détour par l’URL non chiffrée donne aux hackers la possibilité de se positionner de manière inaperçue comme « Man in the Middle » entre le navigateur et le serveur. Dans ce cas de figure, tout le trafic de données peut être lu en texte clair sans que l’attaquant ait à craquer le chiffrement SSL/TLS. Si la page cible est une banque en ligne ou un site d’e-commerce, cette faille de sécurité peut avoir des incidences graves pour les utilisateurs qui effectuent des transactions en ligne notamment.
Ceci peut-être illustré en prenant l’exemple des bornes WIFI publics (ou hotspots) qui sont désormais disponibles dans de nombreux endroits. Les utilisateurs peu prudents se connectent souvent à ces bornes sans même vérifier qui offre cet accès Internet. Les pirates informatiques profitent justement de cette imprudence en présentant leur propre ordinateur comme une borne, enregistrant ainsi tout le trafic de données. Si l’un des utilisateurs accède au site Web de sa banque en ligne via un tel hotspot (borne wifi) sous une forme non chiffrée, cela peut permettre au hacker d’introduire une redirection vers un site Web d’hameçonnage avant que le serveur de la banque en ligne n’ait eu la possibilité de rediriger la connexion HTTP vers HTTPS.
SSL-Stripping
Moxie Marlinspike, Cypherpunk et le fondateur d‘Open Whisper Systems ont présentés pour la première fois en 2009, une technique, dans le cadre de la conférence sur la sécurité Black Hat avec laquelle des connexions HTTPS habituelles peuvent être détournées à l’aide d’un SSL stripping auto-développé.
Pour démontrer la vulnérabilité d’HTTPS, Marlinspike a développé le logiciel proxy SSLStrip. Il utilise la vulnérabilité de sécurité qui se produit lors du transfert HTTP vers les URL HTTPS et convertit toutes les requêtes HTTP identiques. Tandis que SSlStrip établit une connexion HTTP non chiffrée au navigateur de l’utilisateur, le programme communique avec le serveur au niveau HTTPS. Il joue donc le rôle de passerelle et se fait passer pour le serveur Web. L’utilisateur est trompé par un favicon en forme d’un cadenas, qui représente traditionnellement une connexion sécurisée. La condition préalable pour une attaque comme celle-ci est que le pirate puisse lire la communication entre le navigateur et le serveur.
Une solution au problème de sécurité relevé par Marlinspike a été présentée par l’Internet Engineering Task Force (IETF), trois ans plus tard : en 2012, l’extension HTTPS HTTP Strict Transport Security (HSTS) a été spécifiée dans la RFC 6797.
Qu’est-ce que HSTS ?
HSTS (HTTP Strict Transport Security) est un mécanisme de sécurité qui a été développé pour protéger les connexions HTTPS contre les attaques de l’homme du milieu et les détournements de sessions (hijacking). Grâce à l’extension HTTPS, les opérateurs de sites Web peuvent signaler aux navigateurs Web les informations d’en-tête HTTP optionnelles qui permettent à un site d’être récupéré sous forme chiffrée SSL/TLS pour une période de temps définie. Côté serveur, le champ d’en-tête Strict Transport Security est utilisé. Il contient la directive obligatoire max-age et peut être étendu avec les directives optionnelles includeSubDomains et preload :
Strict-Transport-Security: max-age=31536000
La directive max-age spécifie la durée pendant laquelle un site web doit être uniquement disponible sous forme chiffrée. La période de temps est alors définie en secondes, ainsi un max-age de 31.536.000 secondes correspond à une période d’un an.
Lorsqu’un internaute visite pour la première fois un site Web sécurisé par le HSTS, le navigateur reçoit alors les instructions suivantes dans le champ d’en-tête Strict Transport Security :
- Tous les liens non chiffrés vers le site Web respectif doivent être réécrits en liens chiffrés (http:// en https://).
- Si la sécurité de la connexion ne peut pas être garantie (par exemple à cause d’un certificat invalide), elle doit être résiliée. L’utilisateur reçoit alors un message d’erreur.
En option, les informations HSTS peuvent être étendues aux sous-domaines. Dans ce cas, l’en-tête Strict Transport Security est complété de la directive includeSubDomains. Ceci indique au navigateur que l’en-tête HSTS ne s’applique pas seulement l’hôte courant (par exemple www.example.com) mais aussi à tous les sous-domaines dans le domaine spécifié (par exemple aussi pour blog.example.com ou adserver.example.com).
Strict-Transport-Security: max-age=31536000; includeSubDomains
La directive preload vous permet de marquer les pages Web pour ce que le nomme le pré-chargement, et éviter ainsi le problème de la première visite.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Sans le paramètre preload, HSTS n’affectera que les visites futures du site Web : si un navigateur connait les informations contenues dans l’en-tête HSTS d’un site Web, alors les appels suivants sont mis en œuvre en conséquence. Ce mécanisme de sécurité ne s’applique pas à la première visite du site. Les éditeurs de navigateurs comme Google et Mozilla offrent donc la possibilité d’introduire des pages Web dans des listes de pré-chargement (preload lists). Les sites Web enregistrés pour le pré-chargement ne sont accessibles que via HTTPS. Les listes « précharge » sont gérées de manière centralisée par les développeurs de navigateur et sont transmises aux navigateurs utilisateurs par le biais de mises à jour.
Liste précharge pour les pages HTTPS
Puisque le HSTS ne fonctionne que si un site Internet a été consulté au moins une fois dans le passé par l’entremise d’une connexion HTTPS non manipulée, chaque première visite est donc généralement vulnérable aux attaques SSL stripping. Pour remédier à cela, tous les navigateurs populaires utilisent aujourd’hui des listes basées sur un service de pré-chargement pour HSTS fourni par Google dans la cadre du projet Chromium.
En principe, chaque exploitant de site Web est libre d’inscrire son propre domaine dans la liste de précharge HSTS. Toutefois pour inclure un site Web, il existe des exigences de base visant à garantir la qualité du système de contrôle :
- Toutes les pages web doivent envoyer un certificat SSL valide.
- Les URLS HTTP doivent être redirigées vers les URL HTTPS du même hôte.
- Tous les sous-domaines (y compris www-Subdomain) doivent être accessibles via HTTPS.
- L’en-tête HSTS doit être délivré via le domaine de base avec les paramètres suivants:
- La valeur max-age doit être au minimum de 8 semaines (4.838.400 Secondes)
- L’en-tête HSTS doit contenir la directive includeSubDomains.
- L’en-tête HSTS doit contenir la directive preload.
- Toutes les redirections additionnelles du site Web HTTPS doivent inclure l’en-tête HSTS.
- La valeur max-age doit être au minimum de 8 semaines (4.838.400 Secondes)
Les principaux utilisateurs du service de pré-chargement pour HSTS sont Google, Paypal, Twitter et LastPass. La liste complète des domaines enregistrés est disponible sur le site Internet du projet Chromium.
Configurer HSTS : guide pour Apache2, Lighttpd et NGINX
Les fournisseurs de contenus en ligne qui souhaitent protéger leur projet contre le SSL stripping à l’aide de HSTS doivent pour cela configurer leur serveur Web en conséquence. Les rapides instructions suivantes indiquent la configuration HSTS pour Apache, NGINX, Lighttpd et Microsoft IIS.
Apache HTTP Server
Pour pouvoir utiliser HSTS sur Apache HTTP Server, vous devez d’abord activer le module d’en-tête Apache (mod_headers). Les opérateurs de sites Web écrivent la commande suivante sur le terminal:
sudo a2enmod headers
Si le module d’en-tête Apache est activé, redémarrer alors le serveur Web :
sudo service apache restart
Apache HTTP Server vous permet d’exécuter différents domaines sur le même serveur. Chacun de ces domaines est désigné dans la terminologie Apache sous le nom de VirtualHost (vHost) et est configuré indépendamment des autres domaines sur le serveur. Comme HSTS est une extension pour HTTPS, ce mécanisme de sécurité n’est disponible que pour VirutalHosts avec le port 443, le port par défaut pour HTTPS. Pour forcer la connexion chiffrée à un site Web HTTPS pour de futures visites, les opérateurs de site Web ajoutent la ligne de code suivante au VirtualHost désiré dans le fichier de configuration Apache https.conf :
Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"
Pour ce faire, l‘en-tête Strict-Transport-Security est écrit dans le conteneur VirtualHost avec les autres directives:
<VirtualHost *:443>
ServerAdmin support@example.com
ServerName www.example.com
SSLEngine on
SSLCertificateFile /path/to/www.example.com.cert
SSLCertificateKeyFile /path/to/www.example.com.key
[…]
Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"
DocumentRoot /var/www/
</VirtualHost>
Chaque fois qu’un navigateur appelle le site configuré de cette façon, Apache édite un en-tête HSTS avec les paramètres souhaités. Dans cet exemple, le navigateur est chargé de récupérer les pages Web sous le domaine example.com, y compris les sous-domaines pour les huit prochaines semaines uniquement avec un chiffrement SSL/TLS.
Pour appliquer la configuration, il est nécessaire de redémarrer Apache.
NGINX
Même sous NGINX, les connexions chiffrées SSL/TLS peuvent être exécutées par une simple ligne de code:
add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";
La personnalisation se fait dans le fichier de configuration /etc/nginx/nginx.conf. Au lieu de VirtualHosts, NGINX utilise ce qu’on appelle des blocs de serveur pour définir les directives :
server {
listen 443 ssl;
server_name example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
[…]
add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";
}
NGINX doit également être redémarré après la configuration
Lighttpd
Pour activer HSTS sur Lighttpd, il suffit de modifier le fichier de configuration /etc/lighttpd/lighttpd.conf:
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=4838400; includeSubdomains; ")
}
Les paramètres sont appliqués après le redémarrage du serveur Web.
Microsoft IIS
Contrairement à Apache, NGINX et Lighttpd, le serveur Web Internet Information Services (IIS) de Microsoft est configuré via une interface utilisateur graphique. Pour activer HSTS, les opérateurs de sites Web doivent procéder comme suit :
- Démarrer IIS-Manager et sélectionner le site web souhaité.
- Sélectionner l’élément de menu « HTTP Response Header » et cliquer sur « Add ».
- Dans la fenêtre de dialogue « Add Custom HTTP Response Header » sous « Name » entrer Strict-Transport-Security et définir la période souhaitée en secondes sous « Value ».
Il est nécessaire de redémarrer IIS à la fin.
Articles similaires
Des sites Internet plus sûrs grâce au SSL et HTTPS
Le thème de la sécurité sur Internet prend une importance grandissante, que ce soit pour un usage personnel ou un usage professionnel. En tant qu’exploitant de site Web, on devrait prendre toutes les mesures de sécurité possibles pour son site, rendre la visite des internautes la plus sûre possible et garantir des transmissions de données sans risque depuis son serveur Web. En passant votre site…
HPKP : fonctionnement de Public Key Pinning, extension de HTTP
Les certificats SSL/TLS jouent un rôle de plus en plus important dans la transmission de données sensibles. Ils garantissent en effet que les paquets de données atteignent le destinataire souhaité sans détour. Les problèmes ne surviennent que lorsque les internautes sont spécifiquement redirigés par des certificats invalides provenant d’autorités de certification douteuses : un scénario qui peut…
Google prévoit d’afficher une alerte pour les sites non sécurisés
Depuis plus de deux ans, Google encourage activement les administrateurs à sécuriser leur site Web par cryptage SSL. Si cette méthode de sécurisation des données a une influence positive sur le référencement de sites Web parmi les résultats de recherche depuis 2014, Google a annoncé aller plus loin dans cette direction. Bientôt, les utilisateurs de Chrome devraient être avertis de manière…
HTTPS : ce que cela signifie et pourquoi c’est important
Les navigateurs Web actuels se refusent de plus en plus fréquemment à accepter des sites Web non chiffrés et insistent sur la version chiffrée de l’Hypertext Transfer Protocol Secure (HTTPS). Pourquoi est-ce important ? Qu’est-ce qui s’y trouve en fait chiffré ? Quelles informations mon navigateur me donne-t-il à ce sujet ? Vous trouverez ici les réponses à ces questions.
