GuiGui's Show

Encrypted SNI (ESNI) n'est toujours pas normalisé à l'IETF que Cloudflare propose déjà la suite : Encrypted Client Hello (ECH). On ne chiffre plus seulement le nom demandée, mais aussi le début de la poignée de main TLS qui le contient.

Apports :

• ESNI impose une récupération de la clé publique par un autre canal (le DNS). Or, il gère insuffisamment l'expiration desdites clés (pense renouvellement fréquent et TTL DNS). TLS ne prévoit pas de négociation, donc que faire si la clé connue d'un client TLS n'est pas bonne ?
  
  
• Chiffrer l'intégralité de la poignée de main TLS, dont les paramètres de la négociation (algos, etc.). En effet, TLS 1.3 ne garantit pas la confidentialité et l'intégrité de la totalité de la poignée de main (voir ici les apports de TLS 1.3).
  
  
• Le dernier argument, plusieurs serveurs chez plusieurs opérateurs / CDN, donc avec des clés différentes, peuvent répondre pour un même nom DNS, n'est plus d'actualité depuis le type DNS « HTTPS ».

La solution proposée par CF ressemble à EAP TTLS que l'on retrouve dans 802.1X : un tunnel extérieur "générique" (sans infos confidentielles) sert à établir un tunnel interne dans lequel circulera le nom d'hôte demandé (SNI) et les échanges entre client et serveur (requête web, réponse, etc.). Si le client tente d'établir le tunnel interne en connaissant une mauvaise clé, le serveur peut lui proposer la bonne dans le tunnel extérieur (après échec de la négociation du tunnel intérieur), et le client peut tenter d'établir un nouveau tunnel intérieur avec. Concrètement, le tunnel interne est une extension TLS.

Je pense que ça a un intérêt uniquement sur de l'hébergement mutualisé (au sens propre ou CDN), sinon le SNI du tunnel externe, qui doit être valide pour être vérifié (et garantir l'authenticité de l'éventuelle clé reçue en repli), révèle lui-même le nom du site web que l'on veut consulter.