Bonjour à tous,

Dans cet article, nous verrons que le HTTPS, c’est bien, mais que ce n’est pas suffisant pour garantir la confidentialité totale de vos échanges.

On commencera tout d’abord la base avec le protocole TLS avant d’arriver sur le SNI puis son extension l’ESNI.

TLS

TLS signifie à Transport Layer Security, soit Sécurité de la Couche Transport en français (la couche Transport correspondant à la couche 4 du modèle OSI). TLS est donc un protocole de chiffrement qui a succédé un SSL qui permet pour un client de:

• Garantir l’authentification du serveur (voir même du client dans certains cas).
• Garantir la confidentialité des données échangées (c’est grossièrement cette partie dont on parle quand il est question de chiffrement des données).
• Garantir l’intégrité des données échangées (pas d’altération des données).

En résumé, le protocole TLS permet de garantir que l’on parle bien à la bonne personne, que personne d’autre ne peut comprendre nos échanges et que les échanges ne sont pas altérés.

Le HTTPS n’est en réalité que du simple HTTP posé sur du TLS. Le TLS est utilisé pour un bon nombre de cas d’usage autre que le HTTPS comme pour le chiffrement des mails.

Un certificat TLS consiste grossièrement en une clé privée (qui n’appartient qu’au serveur) et une clé publique (qu’il diffuse aux clients). Les connexions TLS démarrent par un handshake (poignée de main en français) qui permettent au client (navigateur de l’utilisateur par exemple) et au serveur de communiquer pour s’accorder sur les clés à utiliser lors de la session.

En réalité, ils vont générer (à partir des clés privées et publiques) une clé de session qui sera utilisée tout au long de la session. Cet échange ne dure que quelques millisecondes et sera répété à chaque nouvelle session.

SNI

Si on se concentre sur le tout début du handshake, on retrouve le client qui initie la connexion (ClientHello) et le serveur qui lui répond en envoyant son certificat.

Imaginons un serveur où l’on héberge plusieurs sites avec leurs propres noms de domaines. Chaque nom de domaine sera associé à un certificat TLS pour que le site puisse être accédé en HTTPS. En début de connexion avec un client, le SNI (Server Name Indication) consiste simplement à indiquer au serveur web quel certificat TLS doit être utilisé lors de l’échange.

Sans le SNI, si vous essayez d’accéder à www.pofilo.fr, le serveur pourrait vous renvoyer le certificat associé à www.nogoma.fr (un autre site que j’héberge !) et vous verrez alors une jolie erreur du type “Your connection is not private”.

D’un point de vue confidentialité des données, le SNI n’est pas terrible dans le sens où la communication se fait en clair.

Une personne interceptant ce type de données pourra notamment surveiller les sites auxquels vous accédez mais également bloquer d’éventuelles connexions vers des serveurs spécifiques.

ESNI

L’ESNI, pour Encrypted SNI, permet donc de résoudre cette dernière problématique. En effet, grâce à l’ESNI, le début de handshake est chiffré, ce qui empêche à un éventuel pirate de voir le site que nous tentons d’accéder. Mais c’est là où ça devient un peu coriace, nous aurions besoin du SNI pour communiquer le SNI, il faut donc imaginer une solution faisant intervenir une autre technologie.

Pour arriver à communiquer de façon chiffrée en tout premier échange, la solution choisie a été d’ajouter une clé publique dans l’enregistrement du nom de domaine. On a donc une correspondance entre: le nom de domaine, l’adresse IP associée et la clé publique à utiliser pour engager le handshake.

En résumé, l’ESNI est en réalité une fonctionnalité supplémentaire améliorant la confidentialité des utilisateurs en chiffrant la partie SNI dans le handshake TLS.

En revanche, l’ESNI est une fonctionnalité récente qui n’est pas encore standardisée. Un projet de RFC est cependant en cours et vous pouvez retrouver le draft ici.

Schéma de séquencement

Voici un petit schéma qui récapitule les différents échanges lors d’une session avec ESNI.

Les plus observateurs d’entre vous auront remarqué qu’il reste une partie non chiffrée dans ce schéma: les échanges DNS. C’est ce que nous allons voir dans la prochaine partie.

Conclusion

L’ESNI est donc un moyen supplémentaire de garantir la confidentialité des échanges. En revanche, ce n’est pas encore un standard défini par une RFC, donc il n’est que très peu déployé.

Dans de futurs articles, on pourra voir d’autres moyens de garantir la confidentialité de nos échanges. Il existe notamment des protocoles tels que DNS over TLS, DNS over HTTPS, DNSSEC, OCSP … Si l’un de ces protocoles (ou d’autres) vous intéresse plus particulièrement, n’hésitez pas à l’indiquer dans la section commentaires. Pour ma part, je ne connaissais que très peu l’ESNI donc j’ai pensé intéressant de vous le partager en premier.