Il y a deux manières d’accéder à un site web, via HTTP ou HTTPS. HTTPS est le même protocole que HTTP avec la différence qu’il utilise une technologie de cryptage appelé TLS (plus connu sous son ancien nom SSL).

De plus en plus de sites utilisent HTTPS pour permettre à leur visiteurs une navigation privée, pour prévenir des publicités ou des « malwares » d’être injectés dans les pages lors de leur chargement et pour protéger les données confidentielles dans les comptes utilisateurs. Avec l’arrivée de « Let’s Encrypt » c’est même devenu gratuit.

Malheureusement, l’utilisation de HTTPS seul présente encore des risques pour les utilisateurs, même sur des sites utilisant HTTPS sur toutes les pages. Voici ce qui ce passe si vous tapez par exemple « apio.systems » dans la barre d’adresse d’un navigateur relativement vieux sans HSTS :

● Le navigateur tente de charger http://apio.systems .
● Le serveur web d’Apio systems répond : ceci n’est par l’URL recherché, essayez https://apio.systems .
● Le navigateur tente de charger https://apio.systems .
● Le serveur web d’Apio systems répond : OK, ceci est la page demandé, et la présente au navigateur pour téléchargement.

Le navigateur a donc fait deux requêtes, et seulement la seconde se fait via un connexion HTTPS sécurisée. Pourquoi ceci arrive ? Dans un souci de compatibilité de vieux systèmes. Le navigateur ne peut pas savoir en avance que le serveur supporte HTTPS donc il essaie HTTP en premier lieu, en attendant que le serveur signale explicitement « Non, utilisez HTTPS à la place ».

Ceci est un problème sérieux. Sans parler du gaspillage de temps et d’octets, ceci rend le site vulnérable à une attaque de type « SSL stripping ». Dans ce type d’attaque, le pirate intercepte et modifie ou remplace des paquets échangés entre le navigateur et le serveur web.

En interceptant la requête qui a eu lieu sur une connexion HTTP non-sécurisée, le pirate peut facilement se faire passer pour le serveur qui est attendu par l’utilisateur (par exemple une page de connexion donnant accès à des données personnelles et/ou confidentielles) et empêcher le navigateur d’utiliser HTTPS.

HSTS (« HTTP Strict Transport Security ») est la solution à ce problème. HSTS permet à un serveur web de demander le navigateur de l’utilisateur de se souvenir que le site en question est disponible en HTTPS. A chaque visite vers ce site, le navigateur se souviendra d’utiliser HTTPS directement sans que ceci soit explicitement demandé par l’utilisateur.

A chaque fois le navigateur trouve un lien, une balise <img>, une balise <script> ou toute autre élément invoquant l’URL du site en question, il récrira automatiquement http:// en https:// si nécessaire. Une fois le navigateur a eu connaissance qu’un site web a HSTS d’activé, il ne communiquera plus avec le serveur en HTTP rendant ainsi une attaque de type « SSL stripping » impossible.

Comment un site web peut-il activer HSTS ?

Maintenant que tous les navigateurs modernes supportent effectivement HSTS (Google Chrome et Chromium ≥ 4.0.211, Mozilla Firefox ≥ 4.0, Opera ≥ 12, Microsoft Internet Explorer ≥11, Safari ≥ 10.9 pour n’en citer que quelques-uns répandus), il faut encore le paramétrer côté serveur pour que ce soit complet.

Afin d’activer cette protection contre le « SSL stripping », le serveur doit renvoyer une en-tête HTTP spéciale au navigateur en réponse à chaque requête. Dès que le navigateur voit cette en-tête, il prendra en compte le fait que le site a HSTS d’activé. L’entête ressemble a ceci :

Strict-Transport-Security: max-age=15552000

ou encore :

Strict-Transport-Security: max-age=15552000; includeSubDomains

L’en-tête HSTS doit être envoyé via HTTPS. Le navigateur ignorera l’en-tête si elle est envoyée pour une ressource http:// .

L’en-tête a deux parties :

1. max-age : indique combien de temps en secondes le navigateur doit se souvenir que ce site a HSTS d’activé. Dans l’exemple, c’est 15552000 secondes correspondant à 180 jours. Du moment que l’utilisateur visite le site au moins une fois tous les 6 mois, il restera protégé. A des fins de tests il peut être utile d’utiliser une faible valeur, par exemple 60 secondes, de manière temporaire pour vérifier que le mécanisme fonctionne bien comme attendu.

2. includeSubDomains : est optionnel. Sans cet argument, HSTS s’appliquera uniquement sur le host exact et non pas sur les sous-domaines y afférent. En le spécifiant, on peut activer HSTS pour l’ensemble des hosts, comme *.apio.systems desservant aussi bien apio.systems comme www.apio.systems ou encore extranet.apio.systems .

Un sous-domaine ne peut affecter son domaine parent par contre, indépendamment si includeSubDomains est spécifié.

Activer HSTS avec Apache :

Il est possible que vous devez activer mod_headers d’abord si ce n’est pas déjà fait. Ensuite, dans la configuration Apache du site concerné, il faut ajouter la configuration suivante dans chaque hôte virtuel SSL :

Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

Activer HSTS avec Nginx :

Dans une configuration Nginx, il faut ajouter la configuration suivante dans chaque bloc serveur SSL :

add_header Strict-Transport-Security "max-age=15552000; includeSubDomains"

Apio systems vous accompagne dans la mise en place de vos serveurs web sécurisés et intégrant parfaitement les standards HSTS. Contactez-nous pour nous parler de votre projet et obtenir des solutions simple et solide.

Pourquoi vous devriez utiliser « HTTP Strict Transport Security » (HSTS) sur votre site web