Wawancara umum: Bagaimana Anda menerapkan TLS Encrypted ClientHello dengan aman?

Pertanyaan dan ruang lingkup

Sebuah perusahaan ingin mengurangi nama situs target yang terlihat oleh perantara jaringan, tetapi khawatir tentang legacy client, proksi penginspeksi TLS, dan konfigurasi usang. Rancang peluncuran, pemantauan, dan rencana fallback ECH yang mencakup ClientHelloInner, ClientHelloOuter, ECHConfig, publikasi DNS, topologi shared atau split, rotasi kunci, dan keamanan terhadap penurunan versi (downgrade).

RFC 9849 mendefinisikan ECH sebagai enkripsi ClientHello di bawah kunci publik server; RFC 9848 mendefinisikan publikasi konfigurasi melalui rekaman SVCB dan HTTPS. ECH melindungi metadata handshake yang dipilih. Ini tidak menyembunyikan alamat IP, pola lalu lintas, atau titik akhir itu sendiri.

Apa yang sedang diuji oleh pewawancara

Menjelaskan amplop outer publik, handshake inner yang sebenarnya, dan siapa yang mendekripsi serta meneruskannya.
Menjelaskan sumber ECHConfig, pengidentifikasi konfigurasi, rotasi kunci, dan konsistensi cache DNS.
Membandingkan mode shared dan split dengan batas kepercayaan dan sertifikat yang eksplisit.
Menghindari klaim bahwa ECH membuat semua lalu lintas menjadi anonim; mendiskusikan IP, DNS, analisis lalu lintas, dan titik akhir.
Menangani legacy client, middlebox, inspeksi, retry_configs, dan jalur downgrade yang tidak aman.
Memvalidasi peluncuran dengan metrik penerimaan, percobaan ulang (retries), kesalahan handshake, dan policy-hit.

Pertanyaan untuk diklarifikasi terlebih dahulu

Apakah tujuannya untuk menyembunyikan SNI dari pengamat publik, atau juga untuk memenuhi inspeksi perusahaan, kebijakan regional, atau retensi kepatuhan?
Siapa yang mengontrol resolver DNS klien dan kebijakan browser? Berapa proporsi legacy client, jaringan seluler, dan proksi perusahaan?
Apakah satu layanan menghentikan (terminate) TLS, atau apakah penyedia edge mendekripsi dan meneruskan ke backend?
Berapa TTL DNS dan jendela tumpang tindih (overlap) kunci yang dapat diterima, dan dapatkah ECH dinonaktifkan sementara selama insiden?
Metrik mana yang harus mengecualikan domain asli atau identitas pengguna, dan berapa lama log disimpan?

Jawaban 30 detik

Saya akan mendefinisikan model ancaman terlebih dahulu: ECH menyembunyikan nama situs sebenarnya di ClientHello, bukan alamat IP atau pola lalu lintas. Server mempublikasikan ECHConfig; klien membangun inner terenkripsi dan outer publik; edge mendekripsi dan menyerahkan inner ke backend. Saya akan melakukan peluncuran bertahap (canary), mengukur penerimaan, percobaan ulang, dan kesalahan handshake, serta merotasi kunci dengan jendela tumpang tindih. Legacy client dapat menggunakan TLS biasa, tetapi kegagalan ECH tidak boleh secara membabi buta mengekspos SNI yang sebenarnya. Kebijakan perusahaan harus dipindahkan ke DNS terkontrol atau batas proksi eksplisit, dengan fallback aman yang teruji.

Analisis mendalam langkah demi langkah

1. Tentukan batas perlindungan

ECH memungkinkan pengamat melihat nama publik atau layanan edge alih-alih SNI sebenarnya. Alamat IP, waktu (timing), ukuran paket, kueri DNS saat DNS tidak dienkripsi, dan kebijakan sertifikat titik akhir masih dapat membocorkan informasi. Nyatakan tujuannya sebagai pengurangan metadata handshake, bukan menganonimkan koneksi.

2. Jelaskan alur inner dan outer

Klien memilih kunci dan parameter dari ECHConfig, menempatkan ClientHello sebenarnya di ClientHelloInner, dan menyusun ClientHelloOuter dengan ekstensi encrypted_client_hello. Outer menggunakan nama publik. Edge mengautentikasi dan mendekripsinya, lalu meneruskan inner ke backend. Server mengautentikasi data terkait outer sehingga penyerang tidak dapat mengubah bidang outer.

text

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 mode shared, satu layanan menghadap klien dan menghentikan TLS backend. Dalam mode split, edge mendekripsi ECH dan meneruskan inner ke backend independen. Mode split membutuhkan kepercayaan eksplisit dari edge-ke-backend, sertifikat, perlindungan koneksi, dan kepemilikan kegagalan; edge tidak secara otomatis menjadi pengamat teks polos yang tidak berbahaya.

4. Publikasikan konfigurasi dan rotasikan kunci

Publikasikan ECHConfig dalam rekaman HTTPS/SVCB dengan TTL terkontrol, dan sediakan konfigurasi lama dan baru selama rotasi. Setiap konfigurasi membawa kunci publik, versi, dan pengidentifikasi. Pantau caching DNS, pemilihan konfigurasi, dan kegagalan dekripsi. Pensiunkan kunci privat lama hanya setelah jendela cache, koneksi, dan percobaan ulang telah berlalu.

5. Tangani kegagalan dan legacy client

Klien tanpa ECH dapat menggunakan TLS biasa; klien berkemampuan ECH dapat menyegarkan pengaturan setelah menerima retry_configs. RFC 9849 melarang klien mengirimkan ClientHello sebenarnya yang tidak terenkripsi setelah penolakan ECH, karena penyerang aktif dapat memicu pengungkapan SNI. Server harus memprovisikan setiap kemungkinan titik akhir dengan sertifikat yang valid untuk nama publik.

6. Tangani middlebox dan kebijakan perusahaan

Proksi penghenti TLS yang tidak memahami ECH dapat terhubung menggunakan nama outer publik, sehingga inspeksi berbasis SNI dapat berhenti cocok. Pindahkan kebijakan ke resolver DNS terkontrol, proksi eksplisit, atau batas browser terkelola, dan beri versi pada kebijakan. Jangan berasumsi bahwa memodifikasi DNS tidak berbahaya; lakukan gladi bersih untuk DNSSEC, jaringan regional, dan penonaktifan darurat.

7. Canary dan observasi

Aktifkan satu situs, wilayah, dan kelompok klien terkontrol terlebih dahulu. Bandingkan penerimaan ECH, ech_required, tingkat percobaan ulang, kegagalan TLS, hit cache DNS, dan latensi ujung-ke-ujung. Catat pengidentifikasi konfigurasi, lokasi edge, dan kelas kesalahan tanpa mencatat SNI inner sebenarnya secara default. Jika handshake, penegakan kebijakan, atau kompatibilitas mengalami regresi, nonaktifkan secara sempit berdasarkan situs atau klien daripada melakukan downgrade secara global.

Contoh jawaban berkualitas tinggi

Saya akan memposisikan ECH sebagai peningkatan privasi SNI, bukan sebagai anonimitas IP atau pola lalu lintas. Setelah DNS mempublikasikan ECHConfig, klien mengenkripsi ClientHelloInner yang sebenarnya dan mengirim ClientHelloOuter dengan nama publik. Edge memvalidasi dan mendekripsinya, lalu menyerahkan inner ke backend TLS di bawah model kepercayaan shared atau split yang terdokumentasi dengan jelas.

Saya akan menerapkan canary terlebih dahulu, merotasi kunci dengan konfigurasi yang tumpang tindih dan jendela TTL, serta memantau pemilihan konfigurasi, penerimaan, retry_configs, ech_required, kesalahan handshake, dan latensi. Legacy client dapat menggunakan TLS biasa, tetapi klien berkemampuan ECH tidak boleh mengekspos SNI sebenarnya setelah kegagalan yang dipicu. Kontrol perusahaan yang bergantung pada SNI dipindahkan ke DNS atau proksi eksplisit. Log hanya menyimpan pengidentifikasi yang disunting dan kelas kesalahan, serta skenario rollback dan DNSSEC digladiresikkan.

Kesalahan umum

Mengklaim ECH menyembunyikan IP dan semua fitur lalu lintas → model ancaman dinyatakan berlebihan → nyatakan bahwa ini melindungi metadata ClientHello yang dipilih.
Mempublikasikan kunci tanpa desain cache DNS dan rotasi → klien menyimpan pengaturan usang → tentukan TTL, tumpang tindih, dan kondisi pensiun.
Mengirim SNI sebenarnya dalam teks biasa setelah kegagalan ECH → penyerang aktif dapat memicu pengungkapan → ikuti aturan penolakan, percobaan ulang, dan penghentian yang aman.
Memperlakukan dekripsi edge sebagai penanganan teks polos tanpa batas kepercayaan → batas mode split hilang → sebutkan tugas edge, backend, sertifikat, dan perlindungan tautan.
Hanya mengukur handshake yang berhasil → regresi legacy dan perusahaan menghilang → segmenkan berdasarkan klien, jaringan, wilayah, dan kelas kesalahan.

Pertanyaan lanjutan dan jawaban

Apakah ECH mencegah kebocoran DNS?

Tidak. ECHConfig biasanya diperoleh melalui rekaman HTTPS/SVCB; jalur DNS yang tidak terenkripsi masih dapat mengungkapkan kueri tersebut. Evaluasi ECH, DNS terenkripsi, sertifikat, dan kebijakan jaringan secara terpisah.

Apa yang dapat dilihat edge dalam mode split?

Edge harus mendekripsi ECH dan meneruskan inner, sehingga ia melihat informasi yang diperlukan untuk pemrosesan handshake. Visibilitas aplikasi bergantung pada di mana TLS berikutnya berakhir. Dokumentasikan kepercayaan minimum, perlindungan tautan, dan batas log.

Mengapa tidak mencoba lagi dengan ClientHello normal setelah kegagalan?

Penyerang aktif dapat menyebabkan kegagalan ECH dan memicu pengungkapan SNI sebenarnya. Implementasi yang aman menggunakan retry_configs, autentikasi nama publik, atau penghentian koneksi dalam aturan fallback klien.

Bagaimana Anda merotasi kunci ECH?

Publikasikan konfigurasi baru sambil mempertahankan konfigurasi lama sepanjang TTL DNS, masa pakai koneksi, dan jendela percobaan ulang. Amati hit dan kegagalan dekripsi berdasarkan pengidentifikasi konfigurasi, lalu pensiunkan kunci privat lama setelah periode tumpang tindih.

Bagaimana jika perusahaan harus menginspeksi SNI?

Perjelas kebijakan dan batasan hukum, lalu gunakan resolver DNS terkontrol, proksi eksplisit, atau kebijakan manajemen titik akhir secara selektif. Jangan berasumsi penulisan ulang DNS tidak memiliki dampak biaya pada DNSSEC, kompatibilitas, atau ketersediaan.

Penerimaan turun sementara keberhasilan TLS tetap stabil. Apa yang Anda periksa?

Bandingkan resolver DNS, versi klien, lokasi edge, dan pengidentifikasi konfigurasi. Periksa caching rekaman HTTPS, versi kunci, sertifikat nama publik, dan retry_configs; bedakan transisi konfigurasi dari kesalahan handshake.