TLS 1.3 stuur die bedienernaam steeds onbeskermd
TLS 1.3 enkripteer die handdruk, maar nie die SNI nie. Lees die ClientHello, kyk vir 'n werklike ECH-aanvaarding, en teken op wat 'n waarnemer nog kan sien.
Om 'n luisteraar na TLS 1.3 op te gradeer verander wat 'n waarnemer kan lees, maar nie soveel as wat die weergawenommer laat vermoed nie. Die ClientHello reis steeds voordat enige enkripsie onderhandel is, en in 'n gewone verbinding staan die versoekte bedienernaam daar in gewone teks. Encrypted Client Hello is die meganisme wat dit verberg, en dit is 'n aparte ontplooiing met sy eie voorvereistes. Voer hierdie vier stappe uit voordat jy 'n beleid skryf wat een van die twee gedragswyses aanneem.
Wat die handdruk werklik blootlê
TLS 1.3 enkripteer die bediener se sertifikaat en die meeste van die handdruk wat op die ServerHello volg. Alles wat die kliënt eerste stuur, val buite daardie beskerming, omdat die sleutels nog nie bestaan nie. Die server name indication is deel van daardie eerste vlug, en daarom kan 'n passiewe waarnemer dit steeds lees sonder om iets te breek.
Die ECH-spesifikasie, RFC 9849, verander dit deur 'n binneste ClientHello te enkripteer vir 'n samewerkende bediener. Die buitenste handdruk bly en dra 'n openbare naam wat die netwerk kan sien, so die ontplooiing het steeds 'n buitenste identiteit nodig wat vir tussenpartye sin maak. Daardie buitenste naam is die deel wat mense mis wanneer hulle verwag dat die verbinding anoniem sal word. Dit is 'n deknaam, nie 'n verborge naam nie, en dit moet opgelos en geoutentiseer word soos enige ander.
Niks hiervan verberg die afleweringsroete nie. Bron- en bestemmingsadresse, poorte, pakketgroottes en tydsberekening bly waarneembaar, en dié sê dikwels meer oor wie praat as wat die naam doen. Naamoplossing en verhoudings op toepassingsvlak is nog 'n laag, elk met sy eie sigbaarheid.
Lees 'n ClientHello eerder as om te aanvaar
Die weergawe in die ServerHello sê nie vir jou wat die kliënt gestuur het nie. Kyk direk na die eerste vlug, vanaf 'n posisie wat die waarnemer verteenwoordig oor wie jy bekommerd is.
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
Die eerste opdrag voer 'n handdruk uit en wys die onderhandelde parameters, insluitend die protokolweergawe en die naam wat jy aangevra het. Die tweede vang die eerste pakkette van 'n werklike verbinding, en die derde onttrek die SNI-veld uit daardie opname. As die veld gevul is, kan die waarnemer wat jy nageboots het dit lees.
Vang afsonderlik aan die kliëntekant en op die pad wanneer die twee verskil, want 'n plaaslike opname kan 'n naam wys wat 'n middlebox later herskryf of laat val. Vang ook vanaf 'n gasheer wat nie self TLS termineer nie, aangesien 'n terminerende volmag gewone teks per ontwerp sien en niks bewys oor wat die netwerk sien nie.
Behandel 'n ECH-uitbreiding as 'n bewering, nie 'n bewys nie
Om 'n ECH-uitbreiding in 'n ClientHello te sien beteken nie die verbinding het ECH gebruik nie. Kliënte stuur GREASE ECH wanneer hulle geen bruikbare konfigurasie het nie, juis sodat hul handdrukke eenvormig lyk. Die uitbreiding is daar, die binneste hello is 'n lokmiddel, en die werklike naam is steeds leesbaar.
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'
Die eerste opdrag wys of die oorsprong 'n HTTPS-hulpbronrekord met 'n ECH-konfigurasieparameter publiseer, want dit is hoe kliënte die sleutel leer. Die tweede soek na statusinligting van die handdruk, hoewel 'n kliënt se suksesboodskap die sterker bewys is. Aanvaarding is wat saak maak: 'n bediener wat nie die bypassende sleutel het nie, kan nie die binneste hello ontsluit nie, en die verbinding val terug.
Kontroleer ook die kliënt, want blaaiersondersteuning en konfigurasie verskil per weergawe en platform. 'n Beleid wat op „moderne blaaiers gebruik ECH“ gebou is, is 'n raaiskoot oor 'n vloot, nie 'n feit oor jou vloot nie. Inventariseer die weergawes wat werklik verbind, en toets dan een van elkeen. Dieselfde bladsy wat van 'n huidige lessenaarblaaier werk, verberg miskien niks vir 'n ouer kliënt op dieselfde netwerk nie.
Skryf die waarnemer se omvang in die beleid
Sê waar die waarnemer sit en wat op daardie punt sigbaar is voordat jy besluit waarop 'n beheer kan staatmaak. 'n Blaaier se verbinding na 'n webwerf, 'n buitenste VPN-transport en 'n TLS-terminerende volmag stel elkeen 'n ander stel feite bloot, en 'n reël wat vir een posisie geskryf is, dra selde skoon oor na 'n ander.
As 'n beheer daarvan afhang om SNI te lees, toets hoe die ontplooide kliënte optree wanneer ECH beskikbaar is en wanneer nie. Teken dan die versoenbaarheidsgevolg op, want 'n filter wat stilweg ophou pas, is erger as een wat nooit ontplooi is nie.
Hou laastens die onsekerheid in die verslag. Om 'n ou universele bewering met 'n nuwer een te vervang laat dieselfde gaping onder 'n ander protokolnaam, en die volgende keurder sal dit net so vasberade glo.