Mozilla har annonceret inklusion af support til brugere af den stabile gren af Firefox til ECH (Encrypted Client Hello) mekanismen, som fortsætter udviklingen af ESNI (Encrypted Server Name Indication) teknologi og er designet til at kryptere information om parametrene for TLS sessioner , såsom det anmodede domænenavn. Kode til at arbejde med ECH blev oprindeligt tilføjet til Firefox 85-udgivelsen, men blev deaktiveret som standard. Chrome begyndte gradvist at inkludere ECH-understøttelse, startende med udgivelsen af Chrome 115.
Da der udover at have forbindelse til server Anmodede domæneoplysninger lækkes via DNS. For fuld beskyttelse skal du, udover ECH, bruge DNS over HTTPS eller DNS over TLS til at kryptere DNS-trafik. Firefox bruger ikke ECH uden at aktivere DNS over HTTPS i indstillingerne. Du kan tjekke ECH-understøttelse i din browser på denne side.
En af de faktorer, der aktiverede ECH-understøttelse som standard i Firefox, var Cloudflares inkludering af ECH-understøttelse i sit indholdsleveringsnetværk for et par dage siden. På den praktiske side, da data om de anmodede værter ved brug af ECH er skjult for analyse, vil filtrering og blokering af uønskede websteder ved hjælp af Cloudflare CDN nu kræve blokering af hele Cloudflare-netværket, blokering af alle anmodninger fra ECH eller organisering af HTTPS-aflytning ved hjælp af falske rodcertifikater på brugersystemet.
Til at starte med at organisere arbejde på én IP-adresse på flere HTTPS-websteder, blev TLS-udvidelsen SNI brugt, hvor navnet på den anmodede vært blev angivet i ClientHello-meddelelsen, der blev sendt, før der blev etableret en krypteret kommunikationskanal. Denne funktion gjorde det muligt at distribuere anmodninger på tværs af virtuelle værter på et tidligt stadium af forbindelsesbehandlingen, men gjorde det også muligt på ISP-siden selektivt at filtrere HTTPS-trafik og analysere, hvilke websteder brugeren åbner, hvilket ikke gjorde det muligt at opnå fuldstændig fortrolighed ved brug HTTPS.
For at løse dette problem og forhindre lækage af oplysninger om det anmodede websted, blev der senere foreslået en ESNI-udvidelse, der implementerer datakryptering med værtsnavnet. Under implementeringen af ESNI blev det afsløret, at den foreslåede mekanisme ikke dækker alle mulige kilder til værtsdatalækage, og brugen af den er ikke nok til at sikre fuldstændig fortrolighed af HTTPS-sessioner. Især når man genoptager en tidligere etableret session, fortsatte domænenavnet i klartekst med at blive specificeret blandt parametrene for PSK (Pre-Shared Key) TLS-udvidelsen. Derudover har bestræbelserne på at implementere ESNI identificeret kompatibilitets- og skaleringsproblemer, der har forhindret udbredt anvendelse af ESNI.
Under hensyntagen til de identificerede mangler ved ESNI blev der udviklet en ny universel ECH-mekanisme, der tillader kryptering af parametrene for alle TLS-udvidelser. Teknisk set er den største forskel mellem ECH og ESNI, at i stedet for individuelle felter, krypteres hele ClientHello-meddelelsen på én gang. ECH involverer opdeling af ClientHello i to separate meddelelser - den krypterede ClientHelloInner-meddelelse (SNI Inner) og den ukrypterede underliggende ClientHelloOuter-meddelelse (SNI Outer). En ukrypteret SNI Outer bærer ikke-privatlivsdata, såsom TLS-versionen og en liste over anvendte cifre, samt et almindeligt domænenavn, der ikke overlapper med det faktiske navn på det anmodede domæne. For alle Cloudflare-klienter angiver den ukrypterede SNI Outer f.eks. den fælles vært "cloudflare-ech.com", men det faktiske navn på den anmodede vært transmitteres i den krypterede SNI Indre og er ikke tilgængelig til analyse.
ECH bruger også en anden distributionsordning for krypteringsnøgler: information om offentlige nøgler transmitteres i HTTPSSVC DNS-poster i stedet for TXT-poster. Autentificeret end-to-end-kryptering baseret på HPKE-mekanismen (Hybrid Public Key Encryption) bruges til at indhente og kryptere nøglen. ECH understøtter også sikker nøgleretransmission fra serveren, som kan bruges i tilfælde af nøglerotation. server og for at løse problemer med at hente forældede nøgler fra DNS-cachen.
Kilde: opennet.ru
