Temu duga umum: Bagaimanakah anda akan menggunakan TLS Encrypted ClientHello dengan selamat?

Soalan dan skop

Sebuah perusahaan ingin mengurangkan keterlihatan nama tapak sasaran kepada perantara rangkaian, tetapi bimbang tentang klien legasi, proksi pemeriksa TLS dan konfigurasi lapuk. Reka bentuk pelancaran ECH, pemantauan dan pelan fallback yang merangkumi ClientHelloInner, ClientHelloOuter, ECHConfig, penerbitan DNS, topologi shared atau split, giliran kunci dan keselamatan penurunan taraf (downgrade).

RFC 9849 mentakrifkan ECH sebagai penyulitan ClientHello di bawah kunci awam pelayan; RFC 9848 mentakrifkan penerbitan konfigurasi melalui rekod SVCB dan HTTPS. ECH melindungi metadata jabat tangan yang terpilih. Ia tidak menyembunyikan alamat IP, corak trafik, atau titik akhir itu sendiri.

Perkara yang diuji oleh penemu duga

• Terangkan sampul outer awam, jabat tangan inner sebenar, dan pihak yang menyahsulit serta memajukannya.
• Huraikan sumber ECHConfig, pengecam konfigurasi, giliran kunci dan ketekalan cache DNS.
• Bandingkan mod shared dan split dengan sempadan kepercayaan dan sijil yang jelas.
• Elakkan mendakwa bahawa ECH menjadikan semua trafik tanpa nama; bincangkan IP, DNS, analisis trafik dan titik akhir.
• Mengendalikan klien legasi, middlebox, pemeriksaan, retry_configs dan laluan penurunan taraf yang tidak selamat.
• Sahkan pelancaran dengan metrik penerimaan, percubaan semula (retries), ralat jabat tangan dan padanan dasar (policy-hit).

Soalan untuk dijelaskan terlebih dahulu

1. Adakah matlamatnya untuk menyembunyikan SNI daripada pemerhati awam, atau juga untuk memenuhi pemeriksaan perusahaan, dasar serantau atau pengekalan pematuhan?
2. Siapakah yang mengawal penyelesai DNS klien dan dasar pelayar? Apakah bahagian klien legasi, rangkaian mudah alih dan proksi perusahaan?
3. Adakah satu perkhidmatan menamatkan TLS, atau adakah penyedia pinggir (edge) menyahsulit dan memajukan kepada bahagian belakang (backend)?
4. Apakah TTL DNS dan tetingkap pertindihan kunci yang boleh diterima, dan bolehkah ECH dilumpuhkan buat sementara waktu semasa insiden?
5. Metrik manakah yang mesti mengecualikan domain sebenar atau identiti pengguna, dan berapa lamakah log disimpan?

Jawapan 30 saat

Saya akan mentakrifkan model ancaman terlebih dahulu: ECH menyembunyikan nama tapak sebenar dalam ClientHello, bukan alamat IP atau corak trafik. Pelayan menerbitkan ECHConfig; klien membina inner yang disulitkan dan outer awam; pinggir menyahsulit dan menyerahkan inner kepada bahagian belakang. Saya akan melancarkannya secara canary, mengukur penerimaan, percubaan semula dan ralat jabat tangan, serta menggilirkan kunci dengan tetingkap pertindihan. Klien legasi boleh menggunakan TLS biasa, tetapi kegagalan ECH tidak boleh mendedahkan SNI sebenar secara membuta tuli. Dasar perusahaan harus beralih kepada DNS terkawal atau sempadan proksi eksplisit, dengan fallback selamat yang telah diuji.

Analisis mendalam langkah demi langkah

1. Takrifkan sempadan perlindungan

ECH membolehkan pemerhati melihat nama awam atau perkhidmatan pinggir dan bukannya SNI sebenar. Alamat IP, pemasaan, saiz paket, pertanyaan DNS apabila DNS tidak disulitkan, dan dasar sijil titik akhir masih boleh membocorkan maklumat. Nyatakan matlamat sebagai mengurangkan metadata jabat tangan, bukan menganonimkan sambungan.

2. Terangkan aliran inner dan outer

Klien memilih kunci dan parameter daripada ECHConfig, meletakkan ClientHello sebenar dalam ClientHelloInner, dan membina ClientHelloOuter dengan sambungan encrypted_client_hello. Bahagian outer menggunakan nama awam. Pinggir mengesahkan dan menyahsulitnya, kemudian menghantar inner kepada bahagian belakang. Pelayan mengesahkan data berkaitan outer supaya penyerang tidak boleh mengubah suai medan outer.

DNS HTTPS/SVCB -> ECHConfig(public name, key, config_id)
client -> encrypt(ClientHelloInner) -> ClientHelloOuter
edge -> decrypt and validate -> backend handles ClientHelloInner

3. Pilih topologi shared atau split

Dalam mod shared, satu perkhidmatan berhadapan dengan klien dan menamatkan TLS bahagian belakang. Dalam mod split, pinggir menyahsulit ECH dan memajukan inner ke bahagian belakang yang bebas. Mod split memerlukan kepercayaan pinggir-ke-bahagian belakang yang jelas, sijil, perlindungan sambungan dan pemilikan kegagalan; pinggir bukan secara automatik menjadi pemerhati teks biasa yang tidak berbahaya.

4. Terbitkan konfigurasi dan gilirkan kunci

Terbitkan ECHConfig dalam rekod HTTPS/SVCB dengan TTL terkawal, dan sediakan konfigurasi lama serta baharu semasa giliran. Setiap konfigurasi membawa kunci awam, versi dan pengecam. Pantau caching DNS, pemilihan konfigurasi dan kegagalan penyahsulitan. Hentikan penggunaan kunci peribadi lama hanya selepas tetingkap cache, sambungan dan percubaan semula telah berlalu.

5. Kendalikan kegagalan dan klien legasi

Klien tanpa ECH boleh menggunakan TLS biasa; klien berkeupayaan ECH boleh menyegarkan tetapan selepas menerima retry_configs. RFC 9849 melarang klien daripada hanya menghantar ClientHello sebenar yang tidak disulitkan selepas penolakan ECH, kerana penyerang aktif boleh mendorong pendedahan SNI. Pelayan harus menyediakan setiap titik akhir yang mungkin dengan sijil yang sah untuk nama awam.

6. Kendalikan middlebox dan dasar perusahaan

Proksi penamat TLS yang tidak memahami ECH mungkin menyambung menggunakan nama outer awam, menyebabkan pemeriksaan berasaskan SNI tidak lagi sepadan. Alihkan dasar kepada penyelesai DNS terkawal, proksi eksplisit, atau sempadan pelayar terurus, dan versikan dasar tersebut. Jangan menganggap bahawa mengubah suai DNS adalah tidak berbahaya; lakukan latihan untuk DNSSEC, rangkaian serantau dan pelumpuhan kecemasan.

7. Canary dan pemerhatian

Dayakan satu tapak, wilayah dan kohort klien terkawal terlebih dahulu. Bandingkan penerimaan ECH, ech_required, kadar percubaan semula, kegagalan TLS, hit cache DNS dan kependaman hujung-ke-hujung. Log pengecam konfigurasi, lokasi pinggir dan kelas ralat tanpa menggunakan SNI inner sebenar secara lalai. Jika jabat tangan, penguatkuasaan dasar atau keserasian mengalami regresi, lumpuhkan secara terhad mengikut tapak atau klien dan bukannya menurunkan taraf secara global.

Contoh jawapan berkualiti tinggi

Saya akan meletakkan ECH sebagai peningkatan privasi SNI, bukan sebagai kerahasiaan tanpa nama bagi IP atau corak trafik. Selepas DNS menerbitkan ECHConfig, klien menyulitkan ClientHelloInner sebenar dan menghantar ClientHelloOuter dengan nama awam. Pinggir mengesahkan dan menyahsulitnya, kemudian menyerahkan inner kepada bahagian belakang TLS di bawah model kepercayaan shared atau split yang didokumentasikan dengan jelas.

Saya akan melakukan canary terlebih dahulu, menggilirkan kunci dengan konfigurasi bertindih dan tetingkap TTL, serta memantau pemilihan konfigurasi, penerimaan, retry_configs, ech_required, ralat jabat tangan dan kependaman. Klien legasi boleh menggunakan TLS biasa, tetapi klien berkeupayaan ECH tidak boleh mendedahkan SNI sebenar selepas kegagalan yang dicetuskan. Kawalan perusahaan yang bergantung pada SNI dialihkan ke DNS atau proksi eksplisit. Log hanya menyimpan pengecam yang disunting dan kelas ralat, serta senario rollback dan DNSSEC dilatih.

Kesilapan biasa

• Mendakwa ECH menyembunyikan IP dan semua ciri trafik → model ancaman dinyatakan secara keterlaluan → nyatakan bahawa ia melindungi metadata ClientHello yang dipilih.
• Menerbitkan kunci tanpa reka bentuk cache DNS dan giliran → klien mengekalkan tetapan lapuk → tentukan TTL, pertindihan dan syarat persaraan kunci.
• Menghantar SNI sebenar dalam teks jelas selepas kegagalan ECH → penyerang aktif boleh mendorong pendedahan maklumat → patuhi peraturan penolakan, percubaan semula dan penamatan yang selamat.
• Menganggap penyahsulitan pinggir sebagai pengendalian teks biasa bebas kepercayaan → sempadan mod split tiada → nyatakan tugas pinggir, bahagian belakang, sijil dan perlindungan pautan.
• Hanya mengukur jabat tangan yang berjaya → regresi legasi dan perusahaan akan terlepas pandang → segmenkan mengikut klien, rangkaian, wilayah dan kelas ralat.

Soalan susulan dan jawapan

Adakah ECH menghalang kebocoran DNS?

Tidak. ECHConfig biasanya diperoleh melalui rekod HTTPS/SVCB; laluan DNS yang tidak disulitkan masih boleh mendedahkan pertanyaan tersebut. Nilaikan ECH, DNS yang disulitkan, sijil dan dasar rangkaian secara berasingan.

Apakah yang boleh dilihat oleh pinggir dalam mod split?

Ia mesti menyahsulit ECH dan memajukan inner, jadi ia melihat maklumat yang diperlukan untuk pemprosesan jabat tangan. Keterlihatan aplikasi bergantung pada tempat TLS seterusnya ditamatkan. Dokumentasikan kepercayaan minimum, perlindungan pautan dan sempadan log.

Mengapa tidak mencuba semula ClientHello biasa selepas kegagalan?

Penyerang aktif boleh menyebabkan kegagalan ECH dan mendorong pendedahan SNI sebenar. Pelaksanaan yang selamat menggunakan retry_configs, pengesahan nama awam, atau penamatan sambungan dalam peraturan fallback klien.

Bagaimanakah anda menggilirkan kunci ECH?

Terbitkan konfigurasi baharu sambil mengekalkan konfigurasi lama sepanjang TTL DNS, jangka hayat sambungan dan tetingkap percubaan semula. Perhatikan hit dan kegagalan penyahsulitan mengikut pengecam konfigurasi, kemudian persarakan kunci peribadi lama selepas tempoh pertindihan.

Bagaimana jika perusahaan mesti memeriksa SNI?

Jelaskan dasar dan sempadan undang-undang, kemudian gunakan penyelesai DNS terkawal, proksi eksplisit atau dasar pengurusan titik akhir secara terpilih. Jangan anggap penulisan semula DNS tidak mempunyai kos DNSSEC, keserasian atau ketersediaan.

Penerimaan menurun sementara kejayaan TLS kekal mendatar. Apakah yang anda periksa?

Bandingkan penyelesai DNS, versi klien, lokasi pinggir dan pengecam konfigurasi. Periksa caching rekod HTTPS, versi kunci, sijil nama awam dan retry_configs; bezakan peralihan konfigurasi daripada kerosakan jabat tangan.