Mozilla kunngjorde at den ville erstatte bruken av ESNI med ECH (Kryptert klient Hei) i Firefox 85 (versjon som er planlagt utgitt 26. januar) for å kryptere informasjonen til TLS-øktparametrene, for eksempel det forespurte domenenavnet.
Firefox nevner at ECH fortsetter å utvikle seg fra ESNI og det er i utkastfasen å bli en IETF-standard. For å organisere arbeidet med en IP-adresse til flere HTTPS-nettsteder ble det samtidig utviklet en TLS SNI-utvidelse, som sender vertsnavnet i klar tekst i ClientHello-meldingen, overført før den krypterte kommunikasjonskanalen ble installert.
For to år siden kunngjorde vi eksperimentell støtte for ESNI-utvidelsen (Encrypted Server Name Indication) som beskytter personvernet i Firefox Nightly. Server Name Indication (SNI) TLS-utvidelse muliggjør server- og sertifikatvalg ved å overføre en kopi i klar tekst av serverens vertsnavn i TLS-klienten hallomelding.
Dette representerer en DNS-lignende personvernlekkasje, og akkurat som DNS-over-HTTPS forhindrer DNS-spørsmål fra å utsette vertsnavnet for observatører i banen, prøver ESNI å forhindre vertsnavnlekkasjer fra protokollprotokollen. TLS-kobling.
Denne funksjonen gjør det mulig å selektivt filtrere HTTPS-trafikk og analysere hvilke nettsteder brukeren åpner, som ikke tillater å oppnå fullstendig konfidensialitet ved bruk av HTTPS.
For å forhindre informasjonslekkasje om det etterspurte nettstedet, for flere år siden ble det utviklet en ESNI-utvidelse, som implementerer datakryptering med et domenenavn (i tillegg til SNI, kan DNS også være en kilde til informasjonslekkasje, derfor i tillegg til ESNI, det er nødvendig å bruke DNS over HTTPS eller DNS over TLS-teknologi). I løpet av forsøk på å implementere ESNI, ble det funnet at den foreslåtte mekanismen ikke er tilstrekkelig til å garantere fullstendig konfidensialitet for HTTPS-økter.
Spesielt når du gjenopptar en tidligere etablert økt, domenenavnet i klar tekst tilsynes mellom parametrene for TLS PSK-utvidelsen (Pre-Shared Key), det vil si kryptering av SNI-feltene var ikke nok, og det var nødvendig å lage en ESNI-analog for PSK og i fremtiden, muligens for andre felt. I tillegg har forsøk på å implementere ESNI identifisert kompatibilitets- og skaleringsproblemer,
Som svar på behovet for å kryptere parametrene for en hvilken som helst TLS-utvidelse, en universell ECH-mekanisme ble foreslått, hvis viktigste forskjell fra ESNI er at i stedet for et eget felt, blir hele ClientHello-meldingen kryptert.
ECH involverer to typer ClientHello-meldinger: en kryptert ClientHelloInner-melding og en ukryptert base ClientHelloOuter-melding, pluss hvis serveren støtter ECH og var i stand til å dekryptere ClientHelloInner, fortsetter du å bruke denne typen for TLS-økten. Ellers hentes dataene fra ClientHelloOuter.
Avslutningsvis er ECH en spennende og robust utvikling av ESNI, og Firefox kommer til å støtte protokollen. Vi jobber hardt for å sikre at den er interoperabel og kan distribueres i stor skala, og vi kan ikke vente på at brukerne skal innse fordelene ved personvern ved denne funksjonen.
ECH bruker også en annen nøkkelfordelingsplan for kryptering: Informasjon om offentlig nøkkel overføres i DNS HTTPSSVC-posten og ikke i TXT-posten. Autentisert end-to-end-kryptering basert på hybrid offentlig nøkkelkryptering (HPKE) brukes til å skaffe og kryptere nøkkelen. ECH støtter også sikker relé av nøkler fra serveren, som kan brukes i tilfelle nøkkelrotasjon på serveren og for å løse problemer med å skaffe foreldede nøkler fra DNS-cachen.
Videre vi kan påpeke beslutningen om å aktivere som standard i Firefox 86 kompatibilitet med AVIF-bildeformatet (AV1 Image Format), som bruker komprimeringsteknologier innen bilder fra AV1-videokodingsformatet. Beholderen for distribusjon av komprimerte data i AVIF er helt lik HEIF.
Fuente: https://blog.mozilla.org