Krypterad klient Hej och DoH: Vad perimeterbrandväggar inte längre kan se

I tjugo år har nätverksbrandväggar och proxyservrar lutat sig mot ett okrypterat fält för att veta vart krypterad trafik tog vägen: Server Name Indication (SNI), värdnamnet som en klient tillkännager i det första meddelandet i en TLS-handskakning. DNS över HTTPS (DoH, RFC 8484) gömde redan DNS-sökningen som föregår en anslutning. Krypterad klient Hej, nu publicerad som RFC 9849, döljer själva SNI:n. Tillsammans tar de bort de två signalerna som mest egressfiltrering byggdes på.

Hur ECH fungerar: en inre och en yttre ClientHello

Med ECH bygger klienten två ClientHello-meddelanden. Den inre bär den verkliga destinationen och känsliga parametrar och krypteras med HPKE till en offentlig nyckel som servern publicerade i förväg. Den yttre, som skickas i klartext, bär ett delat offentligt namn, vanligtvis namnet på leverantörens gränssnitt, så en observatör får bara veta att klienten pratar med den leverantören (RFC 9849; Cloudflares förklarare).

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

Var nyckeln kommer ifrån: HTTPS DNS-posten

Klienten behöver serverns offentliga ECH-nyckel före handskakningen. Den hämtar den från DNS, i HTTPS-resursposten (typ 65, RFC 9460), vars ech-parameter bär en ECHConfigList. Vi frågade en riktig. dig som levereras med macOS känner inte till posten vid namn, så be om den med nummer:

$ 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

Om den DNS-frågan själv går över DoH, ser en nätverksobservatör varken uppslagningen eller, med ECH, värdnamnet i handskakningen. Det är kombinationen den här artikeln handlar om.

Huruvida ECH används beror på kunden

ECH är inget som ett nätverk slår på; varje kund bestämmer. Webbläsare har levererat support (Chrome Platform Status), vanligtvis kopplat till krypterad DNS som används. Massor av programvara använder det inte alls. Cloudflares spårningsslutpunkt rapporterar vad den tog emot, och curl som är inbyggt i macOS skickar fortfarande värdnamnet i klartext:

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

Så den realistiska bilden idag är en blandning: webbläsare döljer i allt högre grad värdnamnet, många andra program gör det inte, och programvara som är skriven för att undvika övervakning kan välja att använda ECH och DoH medvetet.

Vad en perimeterbrandvägg förlorar och vad den behåller

Den ärliga sammanfattningen är att värdnamnsbaserad filtrering vid kanten slutar fungera för ECH-trafik, medan IP-baserade kontroller inte gör det. Ett nätverk kan fortfarande neka anslutningar till kända DoH-resolvers, vilket i praktiken också hindrar webbläsare från att få ECH-nycklar över krypterad DNS, och det kan fortfarande blockera adressintervall. Vad den inte längre kan göra är att skilja två sajter bakom samma leverantör åt, eller tillåta den ena och blockera den andra, utan att bryta TLS på ett sätt som ECH är designat för att upptäcka.

Synlighet flyttas till slutpunkten

Den enda plats där värdnamnet aldrig döljs är maskinen som gör anslutningen: programmet bad om det med namn. Det är därför ECH flyttar utgående kontroll mot slutpunkten. En värdbaserad brandvägg behöver inte läsa handskakningen alls; den ser vilken process som öppnade anslutningen, till vilken adress och, när programmet löste ett namn, vilket namn, innan några krypterade bytes lämnar. Den ser också det enda en nätverksenhet aldrig kunde, även före ECH: vilket program på maskinen som pratar.

• Bestäm per applikation, inte per värdnamn: en webbläsare, en synkroniseringsklient och en okänd binär får olika regler.
• Behandla ett program som startar sin egen DoH med en resolver som systemet inte konfigurerade som en signal värd en titt.
• Håll IP-baserade blockeringslistor vid kanten; de fungerar fortfarande och de kostar ingenting.

Var FireAI och HisnLabs kommer in

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 är HisnLabs eget verktyg: en AI-brandvägg som körs direkt på din Mac. Den visar varje anslutning dina appar gör, på klarspråk, och låter dig avgöra vad som lämnar din Mac — AI:n körs lokalt, så din trafik skickas aldrig till oss eller någon annan. HisnLabs säkerhetsforskningsteam är de som håller de bedömningarna tillförlitliga: de katalogiserar vilka domäner som är vanlig telemetri och vilka som är en riktig tjänst, spårar land och nätverk bakom en anslutning och tränar den lokala modellen (Autopilot-funktionen) på verkliga trafikmönster — utan att något av det lämnar din Mac.

Du kan läsa om de tekniska besluten bakom, eller prova FireAI i 17 dagar, på FireAI, från HisnLabs.