Mozilla heeft aangekondigd dat het ondersteuning voor het ECH-mechanisme (Encrypted Client Hello) beschikbaar maakt voor gebruikers van Firefox stable. Dit is een voortzetting van de ESNI-technologie (Encrypted Server Name Indication) en is ontworpen om informatie over TLS-sessieparameters, zoals de aangevraagde domeinnaam, te versleutelen. De code voor het werken met ECH werd aanvankelijk toegevoegd in Firefox 85, maar was standaard uitgeschakeld. In Chrome is ECH-ondersteuning geleidelijk toegevoegd, te beginnen met de release van Chrome 115.
Omdat naast het contact leggen met server De opgevraagde domeininformatie lekt via DNS. Voor volledige bescherming moet u, naast ECH, ook DNS over HTTPS of DNS over TLS gebruiken om DNS-verkeer te versleutelen. Firefox gebruikt ECH niet zonder dat DNS over HTTPS in de instellingen is ingeschakeld. U kunt op deze pagina controleren of uw browser ECH ondersteunt.
Een van de factoren die ertoe heeft geleid dat Firefox ECH-ondersteuning standaard heeft ingeschakeld, was dat Cloudflare enkele dagen geleden ECH-ondersteuning in zijn content delivery network (CDN) heeft ingeschakeld. Omdat de gegevens over aangevraagde hosts bij gebruik van ECH niet geanalyseerd kunnen worden, vereist het filteren en blokkeren van ongewenste sites via Cloudflare's CDN nu het blokkeren van het volledige Cloudflare-netwerk, het blokkeren van alle verzoeken met ECH, of het organiseren van HTTPS-onderschepping met behulp van valse rootcertificaten op het systeem van de gebruiker.
Aanvankelijk werd de SNI TLS-extensie gebruikt om het werk op één IP-adres van meerdere HTTPS-sites te organiseren, waarbij de naam van de gevraagde host werd gespecificeerd in het ClientHello-bericht dat werd verzonden vóór het opzetten van een versleuteld communicatiekanaal. Deze functie maakte het mogelijk om verzoeken al in een vroeg stadium van de verbindingsverwerking over virtuele hosts te verdelen, maar stelde de internetprovider ook in staat om HTTPS-verkeer selectief te filteren en te analyseren welke sites de gebruiker opent, wat geen volledige vertrouwelijkheid bij gebruik van HTTPS mogelijk maakte.
Om dit probleem op te lossen en het lekken van informatie over de gevraagde site te voorkomen, werd later de ESNI-extensie voorgesteld, die encryptie van gegevens met de hostnaam implementeerde. Tijdens de implementatie van ESNI werd vastgesteld dat het voorgestelde mechanisme niet alle mogelijke bronnen van hostdatalekken dekt en dat het gebruik ervan onvoldoende is om de volledige vertrouwelijkheid van HTTPS-sessies te garanderen. Met name bij het hervatten van een eerder tot stand gebrachte sessie werd de domeinnaam in platte tekst nog steeds gespecificeerd tussen de parameters van de PSK (Pre-Shared Key) TLS-extensie. Bovendien brachten pogingen om ESNI te implementeren compatibiliteits- en schaalproblemen aan het licht die de brede verspreiding van ESNI in de weg stonden.
Rekening houdend met de geconstateerde tekortkomingen van ESNI, is een nieuw universeel mechanisme (ECH) ontwikkeld, waarmee parameters van alle TLS-extensies kunnen worden versleuteld. Technisch gezien is het belangrijkste verschil tussen ECH en ESNI dat in plaats van afzonderlijke velden het volledige ClientHello-bericht in één keer wordt versleuteld. ECH houdt in dat ClientHello wordt gesplitst in twee afzonderlijke berichten: een versleuteld ClientHelloInner-bericht (SNI Inner) en een ongecodeerd basisbericht (ClientHelloOuter-bericht (SNI Outer)). De ongecodeerde SNI Outer verzendt niet-gevoelige gegevens, zoals de TLS-versie en de lijst met gebruikte encryptiesleutels, evenals een gemeenschappelijke domeinnaam die niet overlapt met de daadwerkelijke naam van het opgevraagde domein. Zo specificeert de ongecodeerde SNI Outer voor alle Cloudflare-clients de gemeenschappelijke host "cloudflare-ech.com", terwijl de daadwerkelijke naam van de opgevraagde host wordt verzonden in de versleutelde SNI Inner en niet beschikbaar is voor analyse.
ECH maakt ook gebruik van een ander schema voor de distributie van encryptiesleutels: informatie over de publieke sleutel wordt verzonden in HTTPSSVC DNS-records in plaats van TXT-records. Geauthenticeerde end-to-end-encryptie op basis van het HPKE-mechanisme (Hybrid Public Key Encryption) wordt gebruikt om de sleutel te verkrijgen en te versleutelen. ECH ondersteunt tevens veilige herverzending van de sleutel vanaf de server, wat handig kan zijn in geval van sleutelrotatie. server en om problemen op te lossen met het ophalen van verouderde sleutels uit de DNS-cache.
Bron: opennet.ru
