TLS 1.3 па-ранейшаму дасылае імя сервера адкрытым тэкстам

Абнаўленне слухача да TLS 1.3 змяняе тое, што назіральнік можа прачытаць, але не настолькі, наколькі мяркуе нумар версіі. ClientHello па-ранейшаму перадаецца да ўзгаднення любога шыфравання, і ў звычайным злучэнні запытанае імя сервера ляжыць там адкрытым тэкстам. Encrypted Client Hello — гэта механізм, які яго хавае, і гэта асобнае разгортванне з уласнымі перадумовамі. Выканайце гэтыя чатыры крокі, перш чым пісаць палітыку, якая мяркуе адзін з двух паводзінаў.

Што рукапацісканне насамрэч раскрывае

TLS 1.3 шыфруе сертыфікат сервера і большую частку рукапаціскання, якое ідзе пасля ServerHello. Усё, што кліент дасылае першым, застаецца па-за гэтай аховай, бо ключоў яшчэ не існуе. Пазначэнне імені сервера — частка гэтага першага палёту, таму пасіўны назіральнік усё яшчэ можа яго прачытаць, нічога не ўзламваючы.

Спецыфікацыя ECH, RFC 9849, змяняе гэта, шыфруючы ўнутраны ClientHello для сервера, які супрацоўнічае. Знешняе рукапацісканне застаецца і нясе публічнае імя, якое бачыць сетка, таму разгортванню ўсё яшчэ патрэбна знешняя ідэнтычнасць, зразумелая пасярэднікам. Гэтае знешняе імя — тая частка, якую людзі прапускаюць, чакаючы, што злучэнне стане ананімным. Гэта прыкрывальнае імя, а не схаванае, і яно павінна развязвацца і аўтэнтыфікавацца, як любое іншае.

Нішто з гэтага не хавае шлях дастаўкі. Адрасы крыніцы і прызначэння, порты, памеры пакетаў і таймінгі застаюцца назіральнымі, і яны часта гавораць пра тое, хто гаворыць, больш, чым імя. Развязанне імёнаў і сувязі на ўзроўні праграм — яшчэ адзін пласт, кожны са сваёй бачнасцю.

Чытайце ClientHello замест здагадак

Версія ў ServerHello не кажа, што даслаў кліент. Паглядзіце на першы палёт наўпрост, з пазіцыі, якая ўяўляе назіральніка, які вас цікавіць.

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

Першая каманда выконвае рукапацісканне і паказвае ўзгодненыя параметры, уключаючы версію пратакола і запытанае вамі імя. Другая захоплівае першыя пакеты рэальнага злучэння, а трэцяя вымае поле SNI з гэтага захопу. Калі поле запоўненае, эмуляваны вамі назіральнік можа яго прачытаць.

Захоплівайце асобна на баку кліента і на шляху, калі гэтыя два не супадаюць, бо лакальны захоп можа паказаць імя, якое прамежкавая прылада пазней перапіша або адкіне. Захоплівайце таксама з хоста, які сам не завяршае TLS, паколькі завяршальны проксі бачыць адкрыты тэкст паводле сваёй канструкцыі і нічога не даказвае пра тое, што бачыць сетка.

Стаўцеся да пашырэння ECH як да сцвярджэння, а не доказу

Пабачыць пашырэнне ECH у ClientHello не значыць, што злучэнне выкарыстала ECH. Кліенты дасылаюць GREASE ECH, калі не маюць прыдатнай канфігурацыі, менавіта для таго, каб іх рукапацісканні выглядалі аднолькава. Пашырэнне прысутнічае, унутраны hello — прынада, а сапраўднае імя ўсё яшчэ чытаецца.

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'

Першая каманда паказвае, ці публікуе крыніца запіс рэсурсу HTTPS з параметрам канфігурацыі ECH, і менавіта так кліенты даведваюцца ключ. Другая шукае звесткі пра стан рукапаціскання, хоць паведамленне пра поспех кліента — мацнейшы доказ. Важнае прыняцце: сервер без адпаведнага ключа не можа расшыфраваць унутраны hello, і злучэнне адкочваецца.

Праверце і кліент, паколькі падтрымка браўзераў і канфігурацыя розныя па версіі і платформе. Палітыка, пабудаваная на „сучасныя браўзеры выкарыстоўваюць ECH“, — гэта здагадка пра парк, а не факт пра ваш парк. Праведзіце інвентарызацыю версій, якія сапраўды падключаюцца, і пратэстуйце па адной з кожнай. Тая ж старонка, што працуе з актуальнага настольнага браўзера, можа нічога не схаваць ад старэйшага кліента ў той жа сетцы.

Запішыце вобласць назіральніка ў палітыку

Укажыце, дзе знаходзіцца назіральнік і што відаць у гэтым пункце, перш чым вырашаць, на што можа абапірацца кантроль. Злучэнне браўзера з сайтам, знешні транспарт VPN і проксі, які завяршае TLS, раскрываюць кожны свой набор фактаў, і правіла, напісанае для адной пазіцыі, рэдка пераносіцца чыста на іншую.

Калі кантроль залежыць ад чытання SNI, праверце, як паводзяць сябе разгорнутыя кліенты, калі ECH даступны і калі не. Затым зафіксуйце наступства для сумяшчальнасці, бо фільтр, які моўчкі перастае супадаць, горш за той, што ніколі не разгортваўся.

Нарэшце, захоўвайце нявызначанасць у запісе. Замена старога ўніверсальнага сцвярджэння навейшым пакідае тую ж прагаліну пад іншым імем пратакола, і наступны рэцэнзент паверыць у яго гэтак жа цвёрда.