TLS 1.3 lähettää yhä palvelimen nimen selkokielisenä
TLS 1.3 salaa kättelyn mutta ei SNI:tä. Lue ClientHello, varmista todellinen ECH-hyväksyntä ja kirjaa, mitä tarkkailija voi yhä nähdä.
Kuuntelijan päivittäminen TLS 1.3:een muuttaa sitä, mitä tarkkailija voi lukea, mutta ei niin paljon kuin versionumero antaa ymmärtää. ClientHello kulkee edelleen ennen kuin salauksesta sovitaan, ja tavallisessa yhteydessä pyydetty palvelimen nimi on siinä selkokielisenä. Encrypted Client Hello on mekanismi, joka sen piilottaa, ja se on erillinen käyttöönotto omine edellytyksineen. Suorita nämä neljä vaihetta ennen kuin kirjoitat käytännön, joka olettaa jomman kumman toimintatavan.
Mitä kättely oikeasti paljastaa
TLS 1.3 salaa palvelimen varmenteen ja suurimman osan ServerHellon jälkeisestä kättelystä. Kaikki, minkä asiakas lähettää ensin, jää tämän suojan ulkopuolelle, koska avaimia ei ole vielä olemassa. Palvelimen nimen osoitus on osa tuota ensimmäistä lentoa, minkä vuoksi passiivinen tarkkailija voi yhä lukea sen rikkomatta mitään.
Spesifikaatio ECH, RFC 9849, muuttaa tätä salaamalla sisemmän ClientHellon yhteistyöhaluiselle palvelimelle. Ulompi kättely säilyy ja kantaa julkista nimeä, jonka verkko näkee, joten käyttöönotto tarvitsee yhä ulkoisen identiteetin, joka on järkevä välittäjille. Tuo ulkoinen nimi on se osa, jonka ihmiset jättävät huomaamatta odottaessaan yhteyden muuttuvan anonyymiksi. Se on peitenimi, ei piilotettu nimi, ja sen täytyy ratketa ja todennua kuin minkä tahansa muun.
Mikään tästä ei piilota toimitusreittiä. Lähde- ja kohdeosoitteet, portit, pakettikoot ja ajoitus pysyvät havaittavina, ja ne kertovat usein enemmän siitä, kuka puhuu, kuin nimi. Nimien selvitys ja sovellustason suhteet ovat vielä yksi kerros, kukin omalla näkyvyydellään.
Lue ClientHello olettamisen sijaan
ServerHellon versio ei kerro, mitä asiakas lähetti. Katso ensimmäistä lentoa suoraan asemasta, joka vastaa sinua kiinnostavaa tarkkailijaa.
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
Ensimmäinen komento suorittaa kättelyn ja näyttää sovitut parametrit, mukaan lukien protokollaversion ja pyytämäsi nimen. Toinen tallentaa todellisen yhteyden ensimmäiset paketit, ja kolmas poimii SNI-kentän tallenteesta. Jos kenttä on täytetty, jäljittelemäsi tarkkailija voi lukea sen.
Tallenna erikseen asiakkaan puolella ja reitillä, kun ne kaksi eivät täsmää, koska paikallinen tallenne voi näyttää nimen, jonka välilaite myöhemmin kirjoittaa uudelleen tai pudottaa. Tallenna myös isännältä, joka ei itse päätä TLS:ää, sillä päättävä välityspalvelin näkee selkokielen suunnittelunsa puolesta eikä todista mitään siitä, mitä verkko näkee.
Kohtele ECH-laajennusta väitteenä, ei todisteena
ECH-laajennuksen näkeminen ClientHellossa ei tarkoita, että yhteys käytti ECH:tä. Asiakkaat lähettävät GREASE ECH:tä, kun niillä ei ole käyttökelpoista kokoonpanoa, juuri siksi että niiden kättelyt näyttäisivät yhtenäisiltä. Laajennus on läsnä, sisempi hello on houkutin, ja todellinen nimi on yhä luettavissa.
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'
Ensimmäinen komento näyttää, julkaiseeko alkuperä HTTPS-resurssitietueen, jossa on ECH-kokoonpanoparametri, ja näin asiakkaat oppivat avaimen. Toinen etsii kättelyn tilatietoja, vaikka asiakkaan onnistumisviesti on vahvempi todiste. Hyväksyntä ratkaisee: palvelin, jolla ei ole vastaavaa avainta, ei voi purkaa sisempää helloa, ja yhteys palaa takaisin.
Tarkista myös asiakas, sillä selaintuki ja kokoonpano vaihtelevat version ja alustan mukaan. Käytäntö, joka perustuu siihen, että ”nykyaikaiset selaimet käyttävät ECH:tä”, on arvaus laivueesta, ei tosiasia sinun laivueestasi. Inventoi versiot, jotka todella yhdistävät, ja testaa sitten yksi kutakin. Sama sivu, joka toimii nykyisestä työpöytäselaimesta, ei ehkä piilota mitään vanhemmalta asiakkaalta samassa verkossa.
Kirjoita tarkkailijan laajuus käytäntöön
Ilmoita, missä tarkkailija istuu ja mikä on näkyvissä siinä kohdassa, ennen kuin päätät, mihin valvonta voi nojata. Selaimen yhteys verkkosivustoon, ulompi VPN-siirto ja TLS:n päättävä välityspalvelin paljastavat kukin eri tosiasioiden joukon, ja yhtä asemaa varten kirjoitettu sääntö siirtyy harvoin puhtaasti toiseen.
Jos valvonta riippuu SNI:n lukemisesta, testaa, miten käyttöönotetut asiakkaat käyttäytyvät, kun ECH on saatavilla ja kun se ei ole. Kirjaa sitten yhteensopivuuden seuraus, koska suodatin, joka lakkaa hiljaa täsmäämästä, on huonompi kuin sellainen, jota ei koskaan otettu käyttöön.
Pidä lopuksi epävarmuus kirjauksessa. Vanhan yleispätevän väitteen korvaaminen uudemmalla jättää saman aukon toisen protokollan nimen alle, ja seuraava arvioija uskoo siihen yhtä lujasti.