TLS 1.3 stjoert de tsjinnernamme noch altyd yn platte tekst

In listener opwurdzje nei TLS 1.3 feroaret wat in waarnimmer lêze kin, mar net safolle as it ferzjenûmer suggerearret. De ClientHello reizget noch altyd foardat der inige fersifering úthannele is, en yn in gewoane ferbining stiet de oanfrege servernamme dêr yn platte tekst. Encrypted Client Hello is it meganisme dat it ferstoppet, en it is in aparte útrulling mei eigen betingsten. Doch dizze fjouwer stappen foardat jo in belied skriuwe dat ien fan beide gedragingen oannimt.

Wat de hânskudding echt bleatleit

TLS 1.3 fersiferet it sertifikaat fan de tsjinner en it grutste part fan ‘e hânskudding dy’t nei de ServerHello folget. Alles wat de kliïnt as earste stjoert, leit bûten dy beskerming, om’t de kaaien noch net besteane. De server name indication is diel fan dy earste flecht, dêrom kin in passive waarnimmer it noch lêze sûnder eat te brekken.

De ECH-spesifikaasje, RFC 9849, feroaret dit troch in ynterne ClientHello te fersiferjen foar in gearwurkjende tsjinner. De bûtenste hânskudding bliuwt en draacht in iepenbiere namme dy’t it netwurk sjen kin, dus de útrulling hat noch altyd in bûtenste identiteit nedich dy’t foar tuskenpartijen sin makket. Dy bûtenste namme is it part dat minsken misse as se ferwachtsje dat de ferbining anonim wurdt. It is in deknamm, gjin ferstoppe namme, en it moat him as alle oaren oplosse en autentisearje.

Neat hjirfan ferstoppet it leveringspaad. Boarne- en bestimmingsadressen, poarten, pakketgrutten en timing bliuwe waarnimber, en dy sizze faak mear oer wa’t praat as de namme. Nammeoplossing en relaasjes op applikaasjenivo binne noch in laach, elk mei syn eigen sichtberens.

Lês in ClientHello ynstee fan oan te nimmen

De ferzje yn ‘e ServerHello fertelt jo net wat de kliïnt stjoerd hat. Sjoch de earste flecht direkt, fan in posysje dy’t de waarnimmer fertsjintwurdiget dêr’t jo om tinke.

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

It earste kommando docht in hânskudding en toant de úthannele parameters, wêrûnder de protokolferzje en de namme dy’t jo oanfrege hawwe. It twadde fangt de earste pakketten fan in echte ferbining, en it tredde hellet it SNI-fjild út dy opfangst. As it fjild fol is, kin de waarnimmer dy’t jo neibearde it lêze.

Fang apart oan ‘e kliïntkant en op it paad as de twa net oerienkomme, om’t in lokale opfangst in namme sjen litte kin dy’t in middlebox letter oerskriuwt of weilitten. Fang ek fan in host dy’t TLS sels net beëiniget, om’t in beëinigjende proxy platte tekst fan ûntwerp ôf sjucht en neat bewiist oer wat it netwurk sjucht.

Behannelje in ECH-útwreiding as in bewearing, net as bewiis

In ECH-útwreiding yn in ClientHello sjen betsjut net dat de ferbining ECH brûkte. Kliïnten stjoere GREASE ECH as se gjin brûkbere konfiguraasje hawwe, krekt sadat har hânskuddings itselde lykje. De útwreiding is oanwêzich, de ynterne hello is in lokies, en de werklike namme is noch lêsber.

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'

It earste kommando toant oft de oarsprong in HTTPS-boarnerekord publisearret mei in ECH-konfiguraasjeparameter, en sa leare kliïnten de kaai. It twadde siket nei statusynformaasje fan ‘e hânskudding, hoewol’t it súksesberjocht fan in kliïnt it sterkere bewiis is. Akseptaasje is wat telt: in tsjinner dy’t de byhearrende kaai net hat, kin de ynterne hello net ûntsiferje, en de ferbining falt werom.

Kontrolearje ek de kliïnt, om’t browserstipe en konfiguraasje ferskille per ferzje en platfoarm. In belied boud op „moderne browsers brûke ECH“ is in gissing oer in float, gjin feit oer jo float. Ynventarisearje de ferzjes dy’t eins ferbine, en test dan ien fan elk. Deselde side dy’t fan in aktuele desktopbrowser wurket, ferstoppet miskien neat foar in âldere kliïnt yn itselde netwurk.

Skriuw it berik fan ‘e waarnimmer yn it belied

Jou oan wêr’t de waarnimmer sit en wat op dat punt sichtber is foardat jo beslute wêr’t in kontrôle op fertrouwe kin. De ferbining fan in browser mei in webside, in bûtenste VPN-transport en in TLS-beëinigjende proxy lizze elk in oare set feiten bleat, en in regel skreaun foar ien posysje wurdt selden skjin oerdroegen nei in oare.

As in kontrôle ôfhinget fan it lêzen fan SNI, test dan hoe’t de útrôle kliïnten har gedrage as ECH beskikber is en as net. Skriuw dan de kompatibiliteitsgefal op, want in filter dy’t stilwei ophâldt te passen is slimmer as ien dy’t nea útrôle waard.

Hâld úteinlik de ûnwissichheid yn it ferslach. It ferfangen fan in âlde universele bewearing troch in nijere lit deselde leechte ûnder in oare protokolnamme, en de folgjende beoardieler sil it like fêst leauwe.