🌐 Contexte
Publié le 3 mars 2026 sur le datatracker de l’IETF (https://datatracker.ietf.org/doc/rfc9849/), ce document constitue la RFC 9849, un standard de la catégorie Standards Track produit par le groupe de travail TLS de l’IETF. Les auteurs sont Eric Rescorla (Independent), Kazuho Oku (Fastly), Nick Sullivan (Cryptography Consulting LLC) et Christopher A. Wood (Apple).
🔐 Objet du standard
La RFC 9849 spécifie le mécanisme TLS Encrypted Client Hello (ECH), une extension TLS permettant aux clients de chiffrer leur message ClientHello sous la clé publique du serveur. Ce mécanisme protège notamment :
- Le Server Name Indication (SNI), qui révèle en clair le domaine cible dans TLS 1.3
- La liste ALPN (Application-Layer Protocol Negotiation)
- D’autres champs potentiellement sensibles du ClientHello
🏗️ Architecture et fonctionnement
ECH opère selon deux topologies :
- Shared Mode : le serveur client-facing et le backend sont le même équipement
- Split Mode : le serveur client-facing relaie la connexion vers un backend séparé, sans accès au contenu chiffré
Le mécanisme repose sur HPKE (Hybrid Public Key Encryption, RFC 9180). Le client construit un ClientHelloInner (privé, chiffré) et un ClientHelloOuter (public, contenant l’extension encrypted_client_hello). La configuration ECH est publiée via des enregistrements DNS SVCB/HTTPS (RFC 9460, RFC 9848).
🛡️ Objectifs de sécurité et de confidentialité
- Rendre indiscernables les connexions vers des serveurs d’un même ensemble d’anonymat
- Maintenir la forward secrecy
- Mitiger les attaques actives : cut-and-paste, HelloRetryRequest hijack, ClientHello malleability, packet amplification
- Compatibilité avec TLS 1.3 (RFC 8446), DTLS 1.3 (RFC 9147) et versions ultérieures
📋 Type d’article
Il s’agit d’une publication de standard technique (RFC) dont le but principal est de définir formellement le mécanisme ECH pour interopérabilité et déploiement à grande échelle dans l’écosystème TLS.
🔗 Source originale : https://datatracker.ietf.org/doc/rfc9849/