Gesaan dan skop
TLS 1.3 menyulitkan sebahagian besar kandungan handshake, tetapi ClientHello tradisional boleh mendedahkan SNI dan membolehkan pemerhati membuat inferens tentang perkhidmatan sasaran. Terangkan peranan protokol ECH, penghantaran konfigurasi kunci, dan tingkah laku kegagalan, serta bezakan antara menyembunyikan SNI dengan menyembunyikan semua ciri trafik.
Ini sesuai untuk peranan rangkaian, keselamatan, platform dan protokol umum. Kemahiran terasnya ialah jabat tangan TLS dan sempadan privasi, jadi ia tergolong dalam general.
Perkara yang dinilai oleh penemu duga
Pertama, adakah anda memahami ClientHello luaran (outer) dan dalaman (inner)? ClientHelloOuter menyediakan bentuk keserasian manakala sasaran sebenar diletakkan dalam ClientHelloInner yang disulitkan dengan kunci awam pelayan yang dikonfigurasikan.
Kedua, bolehkah anda menerangkan penghantaran konfigurasi? ECHConfig mengandungi kunci awam dan metadata algoritma; ia boleh ditemui melalui rekod DNS SVCB/HTTPS, tetapi ketulenan (authenticity) dan kesegaran (freshness) tetap penting.
Ketiga, adakah anda tahu bahawa ECH bukanlah kerahsiaan nama (anonymity) hujung ke hujung? DNS, IP, pemasaan, sijil dan laluan tanpa ECH masih boleh mendedahkan maklumat.
Keempat, bolehkah anda menerangkan fallback kegagalan? Klien boleh mencuba semula atau menghantar ClientHello biasa apabila ECH tidak tersedia. Dasar tidak boleh mengira percubaan privasi yang gagal sebagai kejayaan.
Kelima, bolehkah anda mereka bentuk pengesahan? Periksa sambungan handshake, metrik edge, kadar hit konfigurasi, dan kadar fallback daripada hanya memeriksa kejayaan HTTPS semata-mata.
Soalan untuk dijelaskan terlebih dahulu
- Adakah klien, proksi edge, dan pustaka TLS menyokong RFC 9849?
- Bagaimanakah ECHConfig dihantar, dan bagaimanakah DNSSEC atau DNS tersulit dikendalikan?
- Adakah perkhidmatan tersebut mempunyai bahagian hadapan (frontend) yang dikongsi dan berbilang nama bahagian belakang (backend)?
- Adakah fallback SNI teks biasa dibenarkan, atau adakah kegagalan privasi mesti menjadi kegagalan mutlak (hard failure)?
- Adakah kita melindungi domain, nama penyewa (tenant), atau metadata trafik yang lebih luas?
- Bolehkah telemetri merekodkan kejayaan ECH tanpa melog nama dalaman?
Rangka jawapan 30 saat
"ECH meletakkan sasaran sebenar dalam ClientHelloInner dan menyulitkannya dengan HPKE menggunakan kunci awam yang diterbitkan dalam ECHConfig; ClientHelloOuter mengekalkan keserasian handshake. ECHConfig boleh dihantar melalui DNS SVCB/HTTPS, dengan pemeriksaan ketulenan dan kesegaran. Apabila berlaku kegagalan, dasar memilih fallback atau hard failure, dan kejayaan TLS bukan bermakna kejayaan privasi. Pengesahan menggabungkan sambungan handshake, metrik edge, hit konfigurasi, dan kadar fallback sambil mengakui bahawa DNS, IP, dan corak trafik kekal boleh dilihat."
Jawapan langkah demi langkah
Langkah 1: Asingkan dua mesej ClientHello
Klien membina ClientHelloInner dengan SNI sebenar dan sambungan yang ingin disembunyikan, kemudian mencipta ClientHelloOuter sebagai mesej keserasian. Pelayan atau edge menggunakan kunci ECHConfig untuk menyahsulit mesej dalaman; jika ia tidak dapat berbuat demikian, ia mengendalikan kegagalan mengikut protokol.
Langkah 2: Fahami HPKE dan konfigurasi
ECHConfig membawa versi, kunci awam, cipher suite, dan metadata pelayan. Klien menggunakan HPKE untuk melindungi ClientHelloInner, manakala pelayan memegang kunci peribadi yang sepadan. Putaran memerlukan tempoh sah bertindih (overlapping), kawalan cache, dan pembatalan (revocation); jangan kod keras (hard-code) kunci dalam klien.
config = fetch_ech_config()
inner = build_client_hello(real_sni, extensions)
outer = build_outer_hello(public_name, ech_extension)
encrypted_inner = hpke_seal(config.public_key, inner)
send(outer, encrypted_inner)Langkah 3: Bincangkan penghantaran DNS dan ketulenan
ECHConfig boleh ditemui melalui rekod SVCB/HTTPS. Nilaikan kesegaran, penyimpanan cache, dan risiko gangguan; DNS tersulit hanya melindungi sebahagian daripada laluan, manakala DNSSEC dan dasar aplikasi menentukan kepercayaan. Muat semula (refresh) pada konfigurasi yang tidak sah atau telah tamat tempoh.
Langkah 4: Tentukan kegagalan dan fallback
Kegagalan penyahsulitan, konfigurasi tamat tempoh, GREASE, atau ketidakserasian sambungan boleh mencetuskan percubaan semula atau handshake biasa. Tentukan domain yang membenarkan fallback dan keperluan privasi yang memerlukan hard failure, serta rekodkan sebabnya. Fallback bukan kejayaan ECH.
Langkah 5: Kenal pasti pendedahan yang tinggal
ECH menyembunyikan nama sasaran dalam ClientHello, tetapi pertanyaan DNS, IP destinasi, pemasaan, saiz paket, sijil, dan tingkah laku aplikasi masih boleh menyokong analisis trafik. Nyatakan matlamat sebagai mengurangkan pendedahan metadata handshake tertentu, bukan kerahsiaan nama penuh.
Langkah 6: Rancang penggunaan dan putaran kunci
Gunakan kunci peribadi edge dengan keistimewaan paling sedikit (least privilege) dan jejak audit, serta terbitkan konfigurasi lama dan baharu yang bertindih. Cache berbilang wilayah memerlukan versi yang konsisten dan pembatalan (invalidation). Sekiranya kunci terjejas, batalkan konfigurasi lama, pendekkan TTL, dan pantau kadar fallback.
Langkah 7: Bina penerimaan hujung ke hujung
Uji klien dengan dan tanpa ECH, pelbagai laluan DNS, dan pelbagai nod edge. Rekodkan rundingan sambungan, versi konfigurasi, kegagalan penyahsulitan, kadar fallback, kependaman handshake, dan ralat sambungan. Pengesahan paket tidak boleh melog nama dalaman yang sensitif.
Jawapan model
"ECH ialah sambungan jabat tangan TLS, bukan terowong lapisan aplikasi. Klien meletakkan SNI sebenar dalam ClientHelloInner, menyulitkannya dengan HPKE menggunakan kunci awam ECHConfig, dan menghantar ClientHelloOuter yang serasi. ECHConfig boleh ditemui melalui SVCB/HTTPS, jadi pelaksanaan mesti menangani ketulenan DNS, penyimpanan cache, dan putaran.
Saya akan mentakrifkan dasar kegagalan secara eksplisit: hard-fail untuk titik akhir yang sensitif privasi dan pantau fallback biasa pada titik akhir keserasian. Telemetri merangkumi rundingan, hit konfigurasi, kegagalan penyahsulitan, fallback, dan kependaman handshake tanpa melog nama dalaman. DNS, IP, sijil, dan corak trafik masih memerlukan analisis privasi yang berasingan. Penerimaan merangkumi klien, laluan DNS, dan putaran kunci."
Kesilapan biasa
- Mendakwa ECH menyembunyikan semua trafik → DNS, IP, dan pemasaan kekal boleh dilihat → nyatakan matlamat privasi yang bersempadan.
- Mengekod keras (hard-coding) kunci ECHConfig → Putaran dan pembatalan menjadi sukar → gunakan konfigurasi yang boleh disegarkan.
- Hanya memeriksa kejayaan HTTPS → Fallback biasa dikira sebagai ECH → rekod sambungan dan sebab fallback.
- Mengabaikan gangguan DNS dan cache lapuk → Klien menggunakan konfigurasi yang tidak elok → nilaikan ketulenan, TTL, dan muat semula.
- Menganggap SNI luar sebagai sasaran sebenar → Nama keserasian disalahertikan → asingkan nama awam dan SNI dalaman.
- Memutar kunci tanpa pertindihan → Klien berbilang wilayah gagal secara berselang-seli → gunakan pelan pertindihan dan pembatalan.
- Melog nama dalaman → Telemetri membocorkan semula privasi → hanya log cincangan (hash), versi, dan keadaan.
- Mengabaikan klien yang tidak disokong → Pengguna sebenar tidak dapat menyambung → kekalkan peraturan fallback atau hard-fail yang eksplisit.
Soalan susulan
Soalan susulan 1: Bagaimanakah hubungan antara ECH dan DoH/DoT?
ECH melindungi TLS ClientHello; DoH/DoT melindungi pengangkutan DNS. Kedua-duanya menangani peringkat yang berbeza dan boleh digabungkan, tetapi tiada satu pun yang menggantikan yang lain.
Soalan susulan 2: Mengapakah ClientHelloOuter diperlukan?
Ia menyediakan bentuk keserasian supaya middlebox yang tidak memahami ECH masih boleh memproses handshake sementara sasaran sebenar kekal dalam mesej dalaman yang disulitkan.
Soalan susulan 3: Adakah ECH mesti sentiasa melakukan fallback apabila gagal?
Tidak. Dasar bergantung pada keperluan privasi dan ketersediaan. Titik akhir yang sensitif privasi boleh menggunakan hard-fail; titik akhir keserasian boleh menggunakan fallback tetapi mesti menjadikannya boleh diperhatikan dan boleh dikira.
Soalan susulan 4: Bagaimanakah anda mengesahkan bahawa middlebox tidak merosakkan ECH?
Rekodkan rundingan secara berasingan pada klien, edge, dan pelayan, kemudian bandingkan kejayaan, fallback, dan ralat handshake merentasi laluan proksi.
Soalan susulan 5: Apakah yang berlaku selepas kunci terjejas?
Batalkan atau hentikan penerbitan ECHConfig lama, pendekkan TTL cache, gunakan kunci baharu, dan pantau kegagalan penyahsulitan serta fallback. ClientHello yang terdedah sebelum ini tidak boleh dijadikan peribadi secara retroaktif.
Soalan susulan 6: Adakah ECH menyembunyikan nama domain dalam sijil?
Ia terutamanya menyembunyikan nama sasaran dalam handshake. Sijil, DNS, IP, dan maklumat aplikasi mungkin masih boleh mengaitkan domain, jadi penyembunyian domain sepenuhnya tidak boleh dijanjikan.