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.

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.

Cet article vous a-t-il été utile ?
Aller au menu principal