TLS 1.3 skickar fortfarande servernamnet i klartext

Att uppgradera en lyssnare till TLS 1.3 ändrar vad en observatör kan läsa, men inte så mycket som versionsnumret antyder. ClientHello färdas fortfarande innan någon kryptering förhandlats, och i en vanlig anslutning står det efterfrågade servernamnet där i klartext. Encrypted Client Hello är mekanismen som döljer det, och det är en separat driftsättning med egna förutsättningar. Kör de här fyra stegen innan du skriver en policy som förutsätter något av beteendena.

Vad handskakningen faktiskt avslöjar

TLS 1.3 krypterar serverns certifikat och det mesta av handskakningen som följer efter ServerHello. Allt som klienten skickar först ligger utanför det skyddet, eftersom nycklarna inte finns ännu. Server name indication är en del av den första sändningen, och därför kan en passiv observatör fortfarande läsa den utan att bryta något.

Den ECH-specifikationen, RFC 9849, ändrar detta genom att kryptera en inre ClientHello för en samarbetande server. Den yttre handskakningen finns kvar och bär ett offentligt namn som nätverket kan se, så driftsättningen behöver fortfarande en yttre identitet som är begriplig för mellanhänder. Det yttre namnet är den del folk missar när de förväntar sig att anslutningen ska bli anonym. Det är ett täcknamn, inte ett dolt namn, och det måste slås upp och autentiseras som vilket annat som helst.

Inget av detta döljer leveransvägen. Käll- och måladdresser, portar, paketstorlekar och tidsmönster förblir observerbara, och de säger ofta mer om vem som pratar än namnet gör. Namnuppslagning och relationer på applikationsnivå är ännu ett lager, vart och ett med sin egen synlighet.

Läs en ClientHello i stället för att anta

Versionen i ServerHello berättar inte vad klienten skickade. Titta på den första sändningen direkt, från en position som motsvarar den observatör du bryr dig om.

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

Det första kommandot utför en handskakning och visar de förhandlade parametrarna, inklusive protokollversionen och namnet du bad om. Det andra fångar de första paketen i en verklig anslutning, och det tredje extraherar SNI-fältet ur den fångsten. Om fältet är ifyllt kan observatören du emulerade läsa det.

Fånga på klientsidan och på vägen separat när de två inte stämmer, eftersom en lokal fångst kan visa ett namn som en mellanbox senare skriver om eller släpper. Fånga också från en värd som inte själv terminerar TLS, eftersom en terminerande proxy ser klartext per konstruktion och inte bevisar något om vad nätverket ser.

Behandla ett ECH-tillägg som ett påstående, inte ett bevis

Att se ett ECH-tillägg i en ClientHello betyder inte att anslutningen använde ECH. Klienter skickar GREASE ECH när de inte har någon användbar konfiguration, just för att deras handskakningar ska se enhetliga ut. Tillägget finns, det inre hello är en lockfågel, och det faktiska namnet är fortfarande läsbart.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

Det första kommandot visar om ursprunget publicerar en HTTPS-resurspost med en ECH-konfigurationsparameter, vilket är hur klienter lär sig nyckeln. Det andra söker efter statusinformation för handskakningen, även om klientens framgångsmeddelande är det starkare beviset. Acceptans är det som avgör: en server som inte har den matchande nyckeln kan inte dekryptera det inre hello, och anslutningen faller tillbaka.

Kontrollera även klienten, eftersom webbläsarstöd och konfiguration skiljer sig mellan versioner och plattformar. En policy byggd på ”moderna webbläsare använder ECH” är en gissning om en flotta, inte ett faktum om din flotta. Inventera de versioner som faktiskt ansluter och testa sedan en av varje. Samma sida som fungerar från en aktuell skrivbordswebbläsare kanske inte döljer något alls för en äldre klient i samma nätverk.

Skriv observatörens räckvidd i policyn

Ange var observatören sitter och vad som är synligt vid den punkten innan du avgör vad en kontroll kan lita på. En webbläsares anslutning till en webbplats, en yttre VPN-transport och en TLS-terminerande proxy blottar var och en en annan uppsättning fakta, och en regel skriven för en position överförs sällan rent till en annan.

Om en kontroll bygger på att läsa SNI, testa hur de driftsatta klienterna beter sig när ECH är tillgängligt och när det inte är det. Anteckna sedan kompatibilitetskonsekvensen, eftersom ett filter som tyst slutar matcha är värre än ett som aldrig driftsattes.

Slutligen, behåll osäkerheten i protokollet. Att ersätta ett gammalt universellt påstående med ett nyare lämnar samma lucka under ett annat protokollnamn, och nästa granskare kommer att tro på det lika bestämt.