Petunjuk dan konteks
Anda mengoperasikan layanan multi-domain di balik CDN. Tim keamanan menyadari bahwa TLS masih mengekspos SNI berupa cleartext di ClientHello dan ingin mengevaluasi Encrypted Client Hello (ECH). Jelaskan bagaimana klien mendapatkan konfigurasi ECH, apa fungsi dari ClientHello luar dan dalam, di mana batas antara CDN dan origin berada, bagaimana klien lama melakukan fallback, dan metrik apa saja yang mendiagnosis masalah deployment.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin ECH dijelaskan sebagai ekstensi TLS, bukan VPN, DNS terenkripsi, atau anonimitas lalu lintas yang lengkap. Klien mengenkripsi ClientHello dalam dengan kunci publik yang dipublikasikan oleh server dan mengirimkan ClientHello luar ke server yang menghadap klien; nama luar digunakan untuk perutean publik. Jawaban yang kuat mencakup pengiriman konfigurasi melalui HTTPS/SVCB atau yang setara, dukungan CDN dan klien, serta fakta bahwa alamat IP, ukuran lalu lintas, pengaturan waktu (timing), dan saluran samping lainnya tetap terlihat.
Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu
Pengamat dan target privasi
Perjelas apakah ancaman tersebut berupa pengamat pasif, proksi perusahaan, atau man-in-the-middle aktif, dan apakah gateway masih harus menegakkan kebijakan domain. Setiap pengamat melihat kombinasi yang berbeda dari IP, DNS, nama luar, dan timing.
Topologi dan batas kunci
Konfirmasikan apakah ECH berakhir di edge CDN atau titik masuk yang dikelola sendiri dan apakah origin masih memerlukan TLS independen. Tentukan kepemilikan untuk rotasi, distribusi, dan pencabutan kunci privat ECH; kunci publik CDN bukanlah sertifikat origin.
Kebijakan kompatibilitas dan fallback
Konfirmasikan browser, sistem operasi, DoH/DoT, HTTP/3, dan middlebox perusahaan yang menjadi target. Melakukan fallback ke SNI cleartext memulihkan kompatibilitas tetapi juga memulihkan visibilitas pengamat, sehingga kebijakan dan metrik harus menentukan kapan hal tersebut dapat diterima.
Kerangka jawaban 30 detik
"ECH mengenkripsi ClientHello dalam dengan kunci publik ECH yang dipublikasikan server, menempatkan SNI sebenarnya dan ekstensi sensitif di dalamnya. ClientHello luar membawa nama publik sehingga server yang menghadap klien dapat merutekan koneksi. Klien biasanya memperoleh konfigurasi melalui rekaman HTTPS/SVCB atau kebijakan browser, dan edge mendekripsi pesan dalam sebelum melanjutkan TLS 1.3. Jika terjadi kegagalan, kebijakan dapat mencoba ulang atau membatalkan; fallback SNI cleartext memiliki privasi yang lebih lemah. ECH tetap tidak menyembunyikan IP, DNS, timing, atau volume lalu lintas, sehingga harus dievaluasi bersama DNS, CDN, pemantauan, dan rotasi kunci."
Jawaban mendalam langkah demi langkah
Langkah 1: Publikasikan konfigurasi ECH
Layanan memublikasikan ECHConfig yang berisi kunci publik, versi, dan metadata enkapsulasi. Klien memperolehnya dari rekaman HTTPS/SVCB tepercaya atau konfigurasi browser dan memvalidasi sumbernya. Konfigurasi membutuhkan pembuatan versi (versioning) dan kedaluwarsa; kunci usang tidak boleh tersimpan dalam cache tanpa batas waktu.
Langkah 2: Bangun handshake luar dan dalam
Klien menempatkan SNI sebenarnya, ALPN, dan ekstensi sensitif dalam ClientHello dalam yang dienkripsi dengan kunci publik ECH. ClientHello luar membawa nama publik dan payload terenkripsi. Nama tersebut mengarah ke server berkemampuan ECH yang menghadap klien, alih-alih mengungkapkan domain layanan akhir.
Langkah 3: Proses pesan di edge
Edge menerima ClientHello luar dan mencoba kunci privat ECH. Jika berhasil, edge memilih sertifikat dan perutean dari parameter dalam; jika gagal, edge mengirimkan konfigurasi percobaan ulang atau menghentikannya sesuai dengan aturan TLS. TLS dari edge ke origin tetap menjadi batas keamanan independen; ECH tidak menggantikan autentikasi origin.
Langkah 4: Tangani fallback dan attack surface
Konfigurasi yang kedaluwarsa, versi yang tidak kompatibel, perusakan DNS, atau middlebox yang memblokir dapat menghambat ECH. Server dapat memublikasikan konfigurasi percobaan ulang tepercaya dan membiarkan klien mencoba lagi. Jika fallback SNI cleartext diizinkan, batasi cakupannya dan catat dalam log. Jangan pernah memperlakukan konfigurasi percobaan ulang arbitrer sebagai bukti keberhasilan, karena penurunan versi (downgrade) dan salah rute dapat terjadi.
Langkah 5: Nyatakan apa yang disembunyikan dan apa yang tidak
ECH terutama menyembunyikan nama situs dan ekstensi terkait di ClientHello. Pengamat mungkin masih melihat kueri DNS, nama luar, IP tujuan, timing handshake, jumlah koneksi, ukuran paket, dan pola lalu lintas selanjutnya. Nama luar yang unik atau deployment berskala kecil dapat memperkecil rangkaian anonimitas (anonymity set).
Langkah 6: Kelola kunci dan operasional
Terapkan prosedur rotasi, persetujuan ganda, rollback, dan pencabutan darurat untuk kunci privat ECH. Pantau waktu publikasi, penerimaan klien, rasio percobaan ulang, kegagalan dekripsi, peringatan TLS, dan perbedaan versi di seluruh node edge. Gunakan pengidentifikasi diagnostik yang tidak berisi SNI dalam; log tidak boleh merekonstruksi data sensitif yang seharusnya dilindungi oleh ECH.
Langkah 7: Luncurkan dan verifikasi secara bertahap
Lakukan canary ECH pada domain terkontrol dan klien yang didukung. Bandingkan tingkat keberhasilan, fallback, pembatalan, latensi handshake, negosiasi HTTP/2 atau HTTP/3, dan error origin. Uji konfigurasi yang kedaluwarsa, kunci privat yang salah, middlebox, dan rotasi multi-node, lalu verifikasi bahwa klien lama tetap berfungsi di bawah kebijakan yang dideklarasikan.
Contoh jawaban berkualitas tinggi
ECH adalah ekstensi TLS 1.3 yang mengenkripsi ClientHello dalam dengan kunci publik ECHConfig. SNI sebenarnya dan ALPN tetap berada di pesan dalam; ClientHello luar membawa nama publik dan payload terenkripsi. Edge CDN berkemampuan ECH mendekripsi pesan dalam serta memilih sertifikat dan rute. TLS edge-ke-origin tetap terpisah, dan ECH tidak menggantikan autentikasi origin.
Pertama-tama saya akan mendefinisikan model ancaman, pengiriman DNS/SVCB, kepemilikan kunci CDN, dan kebijakan fallback. Konfigurasi yang kedaluwarsa, ketidakcocokan versi, atau interferensi middlebox dapat memicu percobaan ulang tepercaya; fallback SNI cleartext hanya diizinkan melalui kebijakan eksplisit dan selalu diukur. ECH menyembunyikan bidang handshake, bukan IP, DNS, timing, atau volume lalu lintas. Selama peluncuran, saya akan memantau penerimaan, percobaan ulang, kegagalan dekripsi, latensi, dan error origin, menggunakan konfigurasi berversi dan rotasi kunci yang dapat dibatalkan (reversible).
Kesalahan umum
- Kesalahan: Mengasumsikan ECH membuat setiap kunjungan menjadi anonim. → Mengapa ini gagal: IP, DNS, timing, dan volume masih dapat mengorelasikan suatu koneksi. → Perbaikan: Jelaskan anonymity set dan saluran samping yang tersisa, termasuk deployment DNS dan CDN.
- Kesalahan: Memperlakukan kunci privat ECH sebagai kunci sertifikat origin. → Mengapa ini gagal: Dekripsi edge dan autentikasi origin adalah batasan yang terpisah. → Perbaikan: Pisahkan siklus hidup kunci, izin, dan rotasi.
- Kesalahan: Melakukan fallback tanpa syarat setelah ECH gagal. → Mengapa ini gagal: Penyerang dapat memicu kegagalan dan menurunkan tingkat privasi. → Perbaikan: Tentukan kebijakan percobaan ulang, pembatalan, dan fallback disertai peringatan.
- Kesalahan: Mencatat seluruh ClientHello dalam ke log untuk debugging. → Mengapa ini gagal: Log mengekspos kembali nama situs yang seharusnya disembunyikan oleh ECH. → Perbaikan: Catat versi konfigurasi, node, dan kelas error tanpa menyertakan bidang sensitif.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Bagaimana hubungan ECH dengan ESNI?
ESNI terutama melindungi SNI. ECH mengenkripsi ClientHello dalam yang lebih luas dan mendefinisikan koordinasi luar/dalam serta pengiriman konfigurasi. Gunakan standar ECH dan dokumentasi deployment saat ini; terminologi ESNI lama bukanlah rencana implementasi yang lengkap.
Pertanyaan lanjutan 2: Bagaimana perusahaan dapat mengaudit lalu lintas ketika middlebox tidak dapat melihat domain sebenarnya?
Pertama, tentukan apakah organisasi mengontrol endpoint dan gateway egress. Perangkat terkelola dapat memberikan sinyal kebijakan ke agen atau proksi tepercaya. Pada jaringan publik, menyembunyikan SNI bukanlah kegagalan TLS; privasi dan visibilitas organisasi harus direkonsiliasi melalui kebijakan yang eksplisit.
Pertanyaan lanjutan 3: Mengapa nama luar memengaruhi privasi?
Jika satu nama luar hanya melayani satu situs nyata, IP, DNS, dan nama tersebut masih dapat mempersempit tujuan. Titik masuk bersama dan anonymity set yang lebih besar meningkatkan privasi tetapi menambah kompleksitas perutean, sertifikat, dan operasional.
Pertanyaan lanjutan 4: Bagaimana Anda membedakan kegagalan ECH dari kegagalan TLS biasa?
Korelasikan apakah klien mengirimkan ECH, versi konfigurasi, percobaan ulang edge, penghitung kegagalan dekripsi, peringatan TLS, node, dan jendela waktu. Lakukan reproduksi dengan ECH diaktifkan, dinonaktifkan, dan menggunakan konfigurasi lama pada klien yang sama sehingga masalah sertifikat, ALPN, atau kesehatan origin tidak salah dilabeli sebagai kegagalan ECH.