De plus en plus de four­nis­seurs sur Internet s’efforcent de faciliter un accès sécurisé aux contenus en ligne pour les in­ter­nautes. Le protocole de chif­fre­ment TLS (Transport Layer Security) a été établi pour l’uti­li­sa­tion sur le Web, son pré­dé­ces­seur SSL (Secure Sockets Layer) est quant à lui beaucoup plus connu. Tandis que des con­nexions vers des sites Internet via HTTP (Hypertext Transfer Protocol) s’ef­fec­tuent sans chif­fre­ment, le protocole réseau HTTPS (« Hypertext Transfer Protocol Secure » ou « Hypertext Transfer Protocol over SSL/TLS »)  offre la pos­si­bi­lité de sécuriser le trafic de données sur le Web grâce au chif­fre­ment SSL/TLS.

Même Google, le géant du Web, donne le bon exemple en proposant ses services Web très fré­quen­tés ex­clu­si­ve­ment avec le chif­fre­ment SSL/TLS. Depuis Août 2014, HTTPS est même devenu un facteur de clas­se­ment de l’al­go­rithme de ré­fé­ren­ce­ment naturel (organique). C’est pourquoi l’im­por­tance d’uti­li­sa­tion d’un protocole de sé­cu­ri­sa­tion SSL/TLS pour les opé­ra­teurs de sites Web a ainsi fortement augmentée. Cependant, une sécurité fiable n‘est pas offerte dans la con­fi­gu­ra­tion 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 par­ti­cu­liè­re­ment dan­ge­reuses, elles per­met­tent aux hackers de saper le chif­fre­ment SSL/TLS. Ce n’est que depuis 2012 qu’il existe avec HSTS un mécanisme de sécurité pour les con­nexions HTTPS, notamment contre les attaques de ce type.

Les vul­né­ra­bi­li­tés de la tech­no­lo­gie HTTPS

Lorsqu’un site Web est ac­ces­sible via le protocole réseau HTTPS et un cer­ti­fi­cat SSL/TLS fiable, ce type de transport chiffré est gé­né­ra­le­ment sécurisé. Cependant, dans le passé, des attaques répétées contre les or­ga­nismes de cer­ti­fi­ca­tion ont eu pour con­sé­quence la dé­li­vrance d’un grand nombre de cer­ti­fi­cats non sécurisés. De plus, des habitudes d’uti­li­sa­tion largement répandues et l’inat­ten­tion générale dans le trai­te­ment des con­nexions chiffrées offrent de nombreux angles d’attaques pour les l’ha­me­çon­nage (pishing) et les attaques de l’homme du milieu (man in the middle attack).

Re­di­rec­tion de HTTP vers HTTPS

Rarement, les in­ter­nautes sai­sis­sent 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 in­ter­naute entre seulement exemple.com dans la barre d’adresse de son na­vi­ga­teur au lieu de https://exemple.com, le na­vi­ga­teur va convertir au­to­ma­ti­que­ment la requête de recherche pour qu’elle soit in­ter­pré­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 fi­na­le­ment établie, mais le détour par l’URL non chiffrée donne aux hackers la pos­si­bi­lité de se po­si­tion­ner de manière inaperçue comme « Man in the Middle » entre le na­vi­ga­teur 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 chif­fre­ment 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 in­ci­dences graves pour les uti­li­sa­teurs qui ef­fec­tuent des tran­sac­tions en ligne notamment.

Ceci peut-être illustré en prenant l’exemple des bornes WIFI publics  (ou hotspots) qui sont désormais dis­po­nibles dans de nombreux endroits. Les uti­li­sa­teurs peu prudents se con­nec­tent souvent à ces bornes sans même vérifier qui offre cet accès Internet. Les pirates in­for­ma­tiques profitent justement de cette im­pru­dence en pré­sen­tant leur propre or­di­na­teur comme une borne, en­re­gis­trant ainsi tout le trafic de données. Si l’un des uti­li­sa­teurs 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’in­tro­duire une re­di­rec­tion vers un site Web d’ha­me­çon­nage avant que le serveur de la banque en ligne n’ait eu la pos­si­bi­lité de rediriger la connexion HTTP vers HTTPS.

SSL-Stripping

Moxie Mar­lins­pike, Cy­pher­punk 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 con­fé­rence sur la sécurité Black Hat avec laquelle des con­nexions HTTPS ha­bi­tuelles peuvent être dé­tour­nées à l’aide d’un SSL stripping auto-développé. Pour démontrer la vul­né­ra­bi­lité d’HTTPS, Mar­lins­pike a développé le logiciel proxy SSLStrip. Il utilise la vul­né­ra­bi­lité de sécurité qui se produit lors du transfert HTTP vers les URL HTTPS et convertit toutes les requêtes HTTP iden­tiques. Tandis que SSlStrip établit une connexion HTTP non chiffrée au na­vi­ga­teur de l’uti­li­sa­teur, le programme com­mu­nique avec le serveur au niveau HTTPS. Il joue donc le rôle de pas­se­relle et se fait passer pour le serveur Web. L’uti­li­sa­teur est trompé par un favicon en forme d’un cadenas, qui re­pré­sente tra­di­tion­nel­le­ment une connexion sécurisée. La condition préalable pour une attaque comme celle-ci est que le pirate puisse lire la com­mu­ni­ca­tion entre le na­vi­ga­teur et le serveur. Une solution au problème de sécurité relevé par Mar­lins­pike a été présentée par l’Internet En­gi­nee­ring 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 con­nexions HTTPS contre les attaques de l’homme du milieu et les dé­tour­ne­ments de sessions (hijacking). Grâce à l’extension HTTPS, les opé­ra­teurs de sites Web peuvent signaler aux na­vi­ga­teurs Web les in­for­ma­tions d’en-tête HTTP op­tion­nelles qui per­met­tent à 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 obli­ga­toire max-age et peut être étendu avec les di­rec­tives op­tion­nelles in­clu­de­Sub­Do­mains et preload :

Strict-Transport-Security: max-age=31536000

La directive max-age spécifie la durée pendant laquelle un site web doit être uni­que­ment dis­po­nible sous forme chiffrée. La période de temps est alors définie en secondes, ainsi un max-age de 31.536.000 secondes cor­res­pond à une période d’un an. 

Lorsqu’un in­ter­naute visite pour la première fois un site Web sécurisé par le HSTS, le na­vi­ga­teur reçoit alors les ins­truc­tions 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 cer­ti­fi­cat invalide), elle doit être résiliée. L’uti­li­sa­teur reçoit alors un message d’erreur.

En option, les in­for­ma­tions HSTS peuvent être étendues aux sous-domaines. Dans ce cas, l’en-tête Strict Transport Security est complété de la directive in­clu­de­Sub­Do­mains. Ceci indique au na­vi­ga­teur 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; in­clu­de­Sub­Do­mains

La directive preload vous permet de marquer les pages Web pour ce que le nomme le pré-char­ge­ment, et éviter ainsi le problème de la première visite.  

Strict-Transport-Security: max-age=31536000; in­clu­de­Sub­Do­mains; preload

Sans le paramètre preload, HSTS n’affectera que les visites futures du site Web : si un na­vi­ga­teur connait les in­for­ma­tions contenues dans l’en-tête HSTS d’un site Web, alors les appels suivants sont mis en œuvre en con­sé­quence. Ce mécanisme de sécurité ne s’applique pas à la première visite du site. Les éditeurs de na­vi­ga­teurs comme Google et Mozilla offrent donc la pos­si­bi­lité d’in­tro­duire des pages Web dans des listes de pré-char­ge­ment (preload lists). Les sites Web en­re­gis­trés pour le pré-char­ge­ment ne sont ac­ces­sibles que via HTTPS. Les listes « précharge » sont gérées de manière cen­tra­li­sée par les dé­ve­lop­peurs de na­vi­ga­teur et sont trans­mises aux na­vi­ga­teurs uti­li­sa­teurs par le biais de mises à jour.

Liste précharge pour les pages HTTPS

Puisque le HSTS ne fonc­tionne 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é­ra­le­ment vul­né­rable aux attaques SSL stripping. Pour remédier à cela, tous les na­vi­ga­teurs po­pu­laires utilisent aujourd’hui des listes basées sur un service de pré-char­ge­ment pour HSTS fourni par Google dans la cadre du projet Chromium. En principe, chaque ex­ploi­tant 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 cer­ti­fi­cat SSL valide.
  • Les URLS HTTP doivent être re­di­ri­gées vers les URL HTTPS du même hôte.

  • Tous les sous-domaines (y compris www-Subdomain) doivent être ac­ces­sibles via HTTPS.
  • L’en-tête HSTS doit être délivré via le domaine de base avec les pa­ra­mè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 in­clu­de­Sub­Do­mains.

    • L’en-tête HSTS doit contenir la directive preload.

    • Toutes les re­di­rec­tions ad­di­tion­nelles du site Web HTTPS doivent inclure l’en-tête HSTS.

Les prin­ci­paux uti­li­sa­teurs du service de pré-char­ge­ment pour HSTS sont Google, Paypal, Twitter et LastPass. La liste complète des domaines en­re­gis­trés est dis­po­nible sur le site Internet du projet Chromium.

Con­fi­gu­rer HSTS : guide pour Apache2, Lighttpd et NGINX

Les four­nis­seurs de contenus en ligne qui sou­hai­tent protéger leur projet contre le SSL stripping à l’aide de HSTS doivent pour cela con­fi­gu­rer leur serveur Web en con­sé­quence. Les rapides ins­truc­tions suivantes indiquent la con­fi­gu­ra­tion 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é­ra­teurs de sites Web écrivent la commande suivante sur le terminal: 

sudo a2enmod headers

Si le module d’en-tête Apache est activé, re­dé­mar­rer alors le serveur Web :

sudo service apache restart

Apache HTTP Server vous permet d’exécuter dif­fé­rents domaines sur le même serveur. Chacun de ces domaines est désigné dans la ter­mi­no­lo­gie Apache sous le nom de Vir­tual­Host (vHost) et est configuré in­dé­pen­dam­ment des autres domaines sur le serveur. Comme HSTS est une extension pour HTTPS, ce mécanisme de sécurité n’est dis­po­nible que pour Vi­ru­tal­Hosts 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é­ra­teurs de site Web ajoutent la ligne de code suivante au Vir­tual­Host désiré dans le fichier de con­fi­gu­ra­tion 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 Vir­tual­Host avec les autres di­rec­tives: 

<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 na­vi­ga­teur appelle le site configuré de cette façon, Apache édite un en-tête HSTS avec les pa­ra­mètres souhaités. Dans cet exemple, le na­vi­ga­teur est chargé de récupérer les pages Web sous le domaine example.com, y compris les sous-domaines pour les huit pro­chaines semaines uni­que­ment avec un chif­fre­ment SSL/TLS.

Pour appliquer la con­fi­gu­ra­tion, il est né­ces­saire de re­dé­mar­rer Apache.

NGINX

Même sous NGINX, les con­nexions 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 per­son­na­li­sa­tion se fait dans le fichier de con­fi­gu­ra­tion /etc/nginx/nginx.conf. Au lieu de Vir­tual­Hosts, NGINX utilise ce qu’on appelle des blocs de serveur pour définir les di­rec­tives :

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 con­fi­gu­ra­tion

Lighttpd

Pour activer HSTS sur Lighttpd, il suffit de modifier le fichier de con­fi­gu­ra­tion /etc/lighttpd/lighttpd.conf:

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=4838400; includeSubdomains; ")
}

Les pa­ra­mètres sont appliqués après le re­dé­mar­rage du serveur Web.

Microsoft IIS

Con­trai­re­ment à Apache, NGINX et Lighttpd, le serveur Web Internet In­for­ma­tion Services (IIS) de Microsoft est configuré via une interface uti­li­sa­teur graphique. Pour activer HSTS, les opé­ra­teurs de sites Web doivent procéder comme suit : 

  • Démarrer IIS-Manager et sé­lec­tion­ner le site web souhaité.
  • Sé­lec­tion­ner 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é­ces­saire de re­dé­mar­rer IIS à la fin.

Aller au menu principal