# Kryptert klient Hei og DoH: Hva perimeterbrannmurer ikke lenger kan se

> ECH (RFC 9849) skjuler det virkelige vertsnavnet i TLS-håndtrykket og DoH skjuler DNS-oppslaget. Hva som tar bort fra nettverksbrannmurer, hva det ikke gjør, og hvor synligheten beveger seg.

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/no/blog/encrypted-client-hello-ech-doh-blind-perimeter-firewalls

I tjue år har nettverksbrannmurer og proxyer støttet seg på ett ukryptert felt for å vite hvor kryptert trafikk gikk: Server Name Indication (SNI), vertsnavnet en klient kunngjør i den første meldingen i et TLS-håndtrykk. DNS over HTTPS (DoH, [RFC 8484](https://www.rfc-editor.org/rfc/rfc8484.html)) skjulte allerede DNS-oppslaget som går foran en tilkobling. Kryptert klient Hallo, nå publisert som [RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html), skjuler selve SNI. Sammen fjerner de de to signalene som mest utgangsfiltrering ble bygget på.

## Hvordan ECH fungerer: en indre og en ytre ClientHello

Med ECH bygger klienten to ClientHello-meldinger. Den indre bærer den virkelige destinasjonen og sensitive parametere og er kryptert med HPKE til en offentlig nøkkel serveren publiserte på forhånd. Den ytre, sendt i klartekst, har et felles offentlig navn, vanligvis navnet på leverandørens grensesnitt, slik at en observatør bare får vite at klienten snakker med den leverandøren ([RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html); [Cloudflares forklaring](https://blog.cloudflare.com/encrypted-client-hello/)).

*Hva en nettverksobservatør ser (illustrerende)*

```text
TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

```

## Hvor nøkkelen kommer fra: HTTPS DNS-posten

Klienten trenger serverens ECH offentlige nøkkel før håndtrykket. Den henter den fra DNS, i HTTPS-ressursposten (type 65, [RFC 9460](https://www.rfc-editor.org/rfc/rfc9460.html)), hvis `ech`-parameter har en ECHConfigList. Vi spurte en ekte en. `dig` som leveres med macOS kjenner ikke posten ved navn, så be om den etter nummer:

*Terminal, macOS 26.7, 25. september 2026*

```console
$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com
```

Hvis den DNS-spørringen selv går over DoH, ser en nettverksobservatør verken oppslaget eller, med ECH, vertsnavnet i håndtrykket. Det er kombinasjonen denne artikkelen handler om.

## Om ECH benyttes avhenger av oppdragsgiver

ECH er ikke noe et nettverk slår på; hver klient bestemmer. Nettlesere har levert støtte ([Chrome-plattformstatus](https://chromestatus.com/feature/6196703843581952)), vanligvis knyttet til kryptert DNS som er i bruk. Massevis av programvare bruker det ikke i det hele tatt. Cloudflares sporingsendepunkt rapporterer hva det mottok, og `curl` som er innebygd i macOS sender fortsatt vertsnavnet i klartekst:

```console
$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext
```

Så det realistiske bildet i dag er en blanding: nettlesere skjuler i økende grad vertsnavnet, mange andre programmer gjør det ikke, og programvare skrevet for å unngå overvåking kan velge å bruke ECH og DoH bevisst.

## Hva en perimeter brannmur mister, og hva den beholder

| Signal | Vanlig TLS + DNS | ECH + DoH |
| --- | --- | --- |
| DNS-oppslag (hvilket navn) | Synlig på port 53 | Skjult inne i HTTPS til løseren |
| SNI (hvilket vertsnavn) | Synlig | Bare det delte offentlige navnet |
| Destinasjons-IP og port | Synlig | Fremdeles synlig |
| Hvilken enhet på LAN | Synlig | Fremdeles synlig |
| Hvilket program på enheten | Ikke synlig | Ikke synlig |

*På et delt leverandørgrensesnitt identifiserer destinasjons-IP-en ofte leverandøren, ikke nettstedet.*

Den ærlige oppsummeringen er at vertsnavnbasert filtrering ved kanten slutter å fungere for ECH-trafikk, mens IP-baserte kontroller ikke gjør det. Et nettverk kan fortsatt nekte tilkoblinger til kjente DoH-resolvere, noe som i praksis også hindrer nettlesere i å hente ECH-nøkler over kryptert DNS, og det kan fortsatt blokkere adresseområder. Det den ikke lenger kan gjøre er å skille to nettsteder bak samme leverandør fra hverandre, eller tillate den ene og blokkere den andre, uten å bryte TLS på måter ECH er designet for å oppdage.

> **Warning:** Påstander om at ECH gjør trafikk "usporbar" eller perimeterfiltrering "foreldet" går for langt: IP-er, timing, volumer og enheten er fortsatt synlige. Det som går tapt er vertsnavnet, og med det den enkleste policy-spaken.

## Synlighet flyttes til endepunktet

Det ene stedet hvor vertsnavnet aldri skjules er maskinen som oppretter forbindelsen: programmet ba om det ved navn. Det er derfor ECH flytter utgangskontroll mot endepunktet. En vertsbasert brannmur trenger ikke å lese håndtrykket i det hele tatt; den ser hvilken prosess som åpnet forbindelsen, til hvilken adresse og, når programmet løste et navn, hvilket navn, før noen krypterte byte forlater. Den ser også den ene tingen en nettverksenhet aldri kunne, selv før ECH: hvilken applikasjon på maskinen som snakker.

- Bestem per applikasjon, ikke per vertsnavn: en nettleser, en synkroniseringsklient og en ukjent binær får forskjellige regler.
- Behandle et program som starter sin egen DoH med en resolver systemet ikke konfigurerte som et signal verdt en titt.
- Hold IP-baserte blokkeringslister på kanten; de fungerer fortsatt, og de koster ingenting.

## Hvor FireAI og HisnLabs kommer inn

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (FireAI Pilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.

Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på [FireAI, fra HisnLabs](https://hisnlabs.com/fireai/no/download).

## Sources

- [RFC 9849: TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849.html)
- [RFC 9460: SVCB and HTTPS DNS resource records](https://www.rfc-editor.org/rfc/rfc9460.html)
- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.html)
- [Cloudflare: Good-bye ESNI, hello ECH!](https://blog.cloudflare.com/encrypted-client-hello/)
- [Chrome Platform Status: Encrypted Client Hello](https://chromestatus.com/feature/6196703843581952)