Ipinapadala pa rin ng TLS 1.3 ang pangalan ng server sa plaintext

Ang pag-upgrade ng listener sa TLS 1.3 ay nagbabago kung ano ang mababasa ng observer, pero hindi kasing dami ng ipinahihiwatig ng numero ng bersyon. Ang ClientHello ay dumadaan pa rin bago pag-usapan ang anumang encryption, at sa ordinaryong koneksyon ang hiniling na pangalan ng server ay naroon sa plaintext. Ang Encrypted Client Hello ang mekanismong nagtatago nito, at hiwalay itong deployment na may sariling mga paunang kondisyon. Isagawa ang apat na hakbang na ito bago magsulat ng patakarang ipinapalagay ang alinman sa dalawang pag-uugali.

Ano ang talagang inilalantad ng handshake

Iniencrypt ng TLS 1.3 ang sertipiko ng server at ang malaking bahagi ng handshake na sumusunod sa ServerHello. Lahat ng unang ipinapadala ng client ay nasa labas ng proteksyong iyon, dahil wala pa ang mga key. Ang indikasyon ng pangalan ng server ay bahagi ng unang lipad na iyon, kaya nababasa pa rin ito ng passive observer nang walang nasisira.

Ang espesipikasyon ng ECH, RFC 9849, ay nagbabago nito sa pamamagitan ng pag-encrypt ng panloob na ClientHello para sa server na nakikipagtulungan. Ang panlabas na handshake ay nananatili at nagdadala ng pampublikong pangalan na nakikita ng network, kaya kailangan pa rin ng deployment ng panlabas na pagkakakilanlan na may saysay sa mga tagapamagitan. Ang panlabas na pangalang iyon ang bahaging hindi napapansin kapag inaasahang magiging anonymous ang koneksyon. Ito ay pangalan ng takip, hindi nakatagong pangalan, at kailangan itong malutas at ma-authenticate tulad ng iba.

Wala sa mga ito ang nagtatago ng landas ng paghahatid. Ang mga address ng pinagmulan at patutunguhan, port, laki ng packet at timing ay nananatiling nakikita, at madalas na mas marami ang sinasabi nito tungkol sa kung sino ang nagsasalita kaysa sa pangalan. Ang paglutas ng pangalan at mga ugnayan sa antas ng application ay isa pang layer, bawat isa may sariling visibility.

Magbasa ng ClientHello sa halip na magpalagay

Ang bersyon sa ServerHello ay hindi nagsasabi kung ano ang ipinadala ng client. Tingnan ang unang lipad nang direkta, mula sa posisyong kumakatawan sa observer na mahalaga sa iyo.

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

Ang unang utos ay nagsasagawa ng handshake at nagpapakita ng napagkasunduang parameter, kasama ang bersyon ng protocol at ang pangalang hiniling mo. Ang pangalawa ay kumukuha ng mga unang packet ng tunay na koneksyon, at ang pangatlo ay kumukuha ng SNI field mula sa capture na iyon. Kung puno ang field, mababasa ito ng observer na ginaya mo.

Kumuha nang hiwalay sa panig ng client at sa landas kapag hindi nagtutugma ang dalawa, dahil ang lokal na capture ay maaaring magpakita ng pangalang muling isinusulat o itinatapon ng middlebox mamaya. Kumuha rin mula sa host na hindi mismo nagtatapos ng TLS, dahil ang proxy na nagtatapos ay nakakakita ng plaintext ayon sa disenyo at walang pinatutunayan tungkol sa nakikita ng network.

Ituring ang ECH extension bilang pag-aangkin, hindi patunay

Ang makakita ng ECH extension sa ClientHello ay hindi nangangahulugang gumamit ng ECH ang koneksyon. Nagpapadala ang mga client ng GREASE ECH kapag wala silang magamit na configuration, para lang magmukhang pareho ang kanilang handshake. Naroon ang extension, pain ay ang panloob na hello, at nababasa pa rin ang tunay na pangalan.

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'

Ipinapakita ng unang utos kung naglalathala ang origin ng HTTPS resource record na may ECH configuration parameter, at ganoon natututunan ng mga client ang key. Hinahanap ng pangalawa ang impormasyon ng katayuan ng handshake, kahit na ang success message ng client ang mas matibay na patunay. Ang pagtanggap ang mahalaga: hindi kayang i-decrypt ng server na walang tugmang key ang panloob na hello, at bumabalik ang koneksyon.

Suriin din ang client, dahil nagkakaiba ang suporta ng browser at configuration ayon sa bersyon at platform. Ang patakarang nakabatay sa „gumagamit ng ECH ang mga modernong browser“ ay haka-haka tungkol sa isang fleet, hindi katotohanan tungkol sa iyong fleet. I-inventory ang mga bersyong aktuwal na kumokonekta, pagkatapos ay subukan ang isa sa bawat isa. Ang parehong pahina na gumagana mula sa kasalukuyang desktop browser ay maaaring walang maitago sa mas lumang client sa parehong network.

Isulat ang saklaw ng observer sa patakaran

Sabihin kung nasaan ang observer at ano ang nakikita sa puntong iyon bago magpasya kung ano ang maaaring asahan ng isang kontrol. Ang koneksyon ng browser sa isang website, panlabas na VPN transport at proxy na nagtatapos ng TLS ay naglalantad bawat isa ng ibang hanay ng mga katotohanan, at ang patakarang isinulat para sa isang posisyon ay bihirang malinis na mailipat sa iba.

Kung ang isang kontrol ay umaasa sa pagbasa ng SNI, subukan kung paano kumikilos ang mga naka-deploy na client kapag available ang ECH at kapag hindi. Pagkatapos ay itala ang kahihinatnan sa compatibility, dahil ang filter na tahimik na tumitigil sa pagtutugma ay mas masahol pa kaysa sa hindi kailanman na-deploy.

Sa huli, panatilihin ang kawalan ng katiyakan sa rekord. Ang pagpapalit ng lumang pangkalahatang pag-aangkin ng mas bago ay nag-iiwan ng parehong puwang sa ilalim ng ibang pangalan ng protocol, at ang susunod na tagasuri ay maniniwala rin ito nang kasing tindi.