TLS 1.3 ankoraŭ sendas la servilan nomon en klara teksto

Ĝisdatigi aŭskultanton al TLS 1.3 ŝanĝas tion, kion observanto povas legi, sed ne tiom, kiom sugestas la versinumero. ClientHello ankoraŭ vojaĝas antaŭ ol iu ajn ĉifrado estas interkonsentita, kaj en ordinara konekto la petita servila nomo staras tie en klara teksto. Encrypted Client Hello estas la mekanismo, kiu kaŝas ĝin, kaj ĝi estas aparta lanĉo kun propraj antaŭkondiĉoj. Plenumu ĉi tiujn kvar paŝojn antaŭ ol verki regularon, kiu supozas unu el la du kondutoj.

Kion la manpremo efektive malkaŝas

TLS 1.3 ĉifras la atestilon de la servilo kaj la plej grandan parton de la manpremo, kiu sekvas ServerHello. Ĉio, kion la kliento sendas unue, restas ekster tiu protekto, ĉar la ŝlosiloj ankoraŭ ne ekzistas. La indiko de la servila nomo estas parto de tiu unua flugo, tial pasiva observanto ankoraŭ povas legi ĝin sen rompi ion ajn.

La ECH-specifikaĵo, RFC 9849, ŝanĝas tion ĉifrante internan ClientHello por kunlabora servilo. La ekstera manpremo restas kaj portas publikan nomon, kiun la reto povas vidi, do la lanĉo ankoraŭ bezonas eksteran identecon, kiu havas sencon por perantoj. Tiu ekstera nomo estas la parto, kiun homoj maltrafas, kiam ili atendas, ke la konekto fariĝos anonima. Ĝi estas kovra nomo, ne kaŝita, kaj ĝi devas solviĝi kaj aŭtentiĝi kiel ĉiu alia.

Nenio el tio kaŝas la liveran vojon. Fontaj kaj celaj adresoj, pordoj, paketaj grandecoj kaj tempoj restas observeblaj, kaj ili ofte diras pli pri tio, kiu parolas, ol la nomo. Nomtradukado kaj aplik-nivelaj rilatoj estas ankoraŭ alia tavolo, ĉiu kun sia propra videbleco.

Legu ClientHello anstataŭ supozi

La versio en ServerHello ne diras al vi, kion la kliento sendis. Rigardu la unuan flugon rekte, de pozicio, kiu reprezentas la observanton, pri kiu vi zorgas.

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

La unua komando plenumas manpremon kaj montras la interkonsentitajn parametrojn, inkluzive de la protokola versio kaj la nomo, kiun vi petis. La dua kaptas la unuajn pakaĵojn de reala konekto, kaj la tria eltiras la SNI-kampon el tiu kaptaĵo. Se la kampo estas plenigita, la observanto, kiun vi imitis, povas legi ĝin.

Kaptu aparte ĉe la klienta flanko kaj sur la vojo, kiam la du malkongruas, ĉar loka kaptaĵo povas montri nomon, kiun mezaĵo poste reskribas aŭ forĵetas. Kaptu ankaŭ de gastiganto, kiu mem ne finas TLS, ĉar finanta prokuro vidas klaran tekston laŭ sia konstruo kaj pruvas nenion pri tio, kion vidas la reto.

Traktu ECH-etendaĵon kiel aserton, ne kiel pruvon

Vidi ECH-etendaĵon en ClientHello ne signifas, ke la konekto uzis ECH. Klientoj sendas GREASE ECH, kiam ili ne havas uzeblan agordon, ĝuste por ke iliaj manpremoj aspektu unuforme. La etendaĵo ĉeestas, la interna hello estas logaĵo, kaj la reala nomo ankoraŭ estas legebla.

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'

La unua komando montras, ĉu la origino publikigas HTTPS-rimedon kun ECH-agorda parametro, kaj tiel klientoj lernas la ŝlosilon. La dua serĉas statusinformojn de la manpremo, kvankam sukcesa mesaĝo de kliento estas la pli forta pruvo. Akcepto estas tio, kio gravas: servilo, kiu ne havas la kongruan ŝlosilon, ne povas malĉifri la internan hello, kaj la konekto retropaŝas.

Kontrolu ankaŭ la klienton, ĉar retumila subteno kaj agordo varias laŭ versio kaj platformo. Regularo bazita sur „modernaj retumiloj uzas ECH“ estas konjekto pri floto, ne fakto pri via floto. Inventaru la versiojn, kiuj efektive konektiĝas, poste testu po unu el ĉiu. La sama paĝo, kiu funkcias el aktuala labortabla retumilo, eble kaŝos nenion al pli malnova kliento en la sama reto.

Skribu la amplekson de la observanto en la regularon

Indiku, kie la observanto sidas kaj kio estas videbla en tiu punkto, antaŭ ol decidi, sur kio kontrolo povas sin apogi. La konekto de retumilo al retejo, ekstera VPN-transporto kaj TLS-finanta prokuro ĉiu malkaŝas alian aron da faktoj, kaj regulo verkita por unu pozicio malofte transiriĝas pure al alia.

Se kontrolo dependas de legado de SNI, testu, kiel kondutas la lanĉitaj klientoj, kiam ECH estas havebla kaj kiam ne. Poste registru la kongruecan konsekvencon, ĉar filtrilo, kiu silente ĉesas kongrui, estas pli malbona ol tiu, kiu neniam estis lanĉita.

Fine, konservu la necerton en la protokolo. Anstataŭigi malnovan universalan aserton per pli nova lasas la saman breĉon sub alia protokola nomo, kaj la sekva revizianto kredos ĝin same firme.