Scénario
La meilleure façon de décrire HSTS est de présenter le scénario qu'il permet d'améliorer.
Un site web sécurisé
Responsable d'un service de courrier électronique, vous avez mis un webmail à disposition de vos utilisateur. Puisqu'ils sont amenés à y taper leur mot de passe, vous avez sécurisé l'accès à ce site avec HTTPS.
Un problème d'interface chaise-clavier
L'ennui, c'est que vos utilisateurs sont fainéants : dans la barre d'adresse de leur navigateur web, ils ne tapent pas « https://webmail.example.com/ » mais simplement « webmail.example.com ». Le comble, c'est qu'ils s'attendent à ce que cela fonctionne ainsi !
Une mauvaise solution
Pour servir vos utilisateurs, vous avez donc mis en place un site web non sécurisé répondant à l'adresse « http://webmail.example.com/ », qui redirige immédiatement sur le site sécurisé « https://webmail.example.com/ ».
C'est cette solution qui introduit une faille. Vos utilisateurs ont maintenant l'habitude de se connecter sur « webmail.example.com » sans réfléchir : ils tombent alors sur le site non sécurisé, qui redirige normalement sur le site sécurisé. Si tout va bien, l'accès à votre webmail est donc sécurisé.
Mais un pirate peut maintenant s'introduire entre un utilisateur et votre webmail : en supprimant la redirection vers le site sécurisé, il peut forcer l'utilisateur à rester sur un site non sécurisé, et lire toutes les données qu'il envoie. Habitué à ne pas saisir l'indicateur de protocole « https », il y a de bonnes chances que votre utilisateur ne s'en rende pas compte.
La solution HSTS
Avec HSTS, lorsqu'un utilisateur se connecte pour la première fois à votre site web sécurisé « https://webmail.example.com/ », votre serveur web lui indique que ce site est sécurisé et doit le rester. Le navigateur réagit en enregistrant cette information : par la suite, il n'accèdera plus jamais au site web non sécurisé, même si on lui demande, mais utilisera le site web sécurisé à la place.
En somme, puisqu'on ne peut pas se fier à l'utilisateur pour accéder volontairement au site web sécurisé, on demande au navigateur de le faire.
Mise en œuvre
Principe
En pratique, HSTS est un en-tête HTTP spécialisé :
Strict-Transport-Security: max-age=31536000
La variable max-age indique le temps, en secondes, pendant lequel cette « politique HSTS » doit être conservée par le navigateur. Après cette durée, ici un an, le navigateur considérera à nouveau ce site web comme normal — sauf qu'en réalité, à moins que le webmestre n'ait décidé de l'enlever, le navigateur aura entre-temps reçu de nouveau cet en-tête.
Serveur web
Du côté du serveur, il s'agit donc d'ajouter un en-tête particulier dans la réponse HTTP. Par exemple, avec Apache Web Server, cela se fait en ajoutant les lignes suivantes dans la définition de votre site sécurisé :
Header set Strict-Transport-Security "max-age=31536000"
La directive équivalent pour Nginx n'est guère plus compliquée :
add_header Strict-Transport-Security "max-age=31536000";
Navigateur
Du côté du client, il faut que le navigateur web prenne en charge HSTS. Aujourd'hui, les navigateurs suivants le prennent en charge :
- Google Chrome/Chromium 4.0.211.0 ;
- Firefox 4.0.
