Perintah dan cakupan
TLS 1.3 mengenkripsi sebagian besar konten handshake, tetapi ClientHello tradisional dapat mengekspos SNI dan memungkinkan pengamat menyimpulkan layanan target. Jelaskan peran protokol ECH, pengiriman konfigurasi kunci, dan perilaku kegagalan, serta bedakan antara menyembunyikan SNI dan menyembunyikan semua karakteristik lalu lintas.
Ini cocok untuk peran jaringan, keamanan, platform, dan protokol umum. Keterampilan intinya adalah handshake TLS dan batasan privasi, sehingga termasuk dalam general.
Apa yang dinilai oleh pewawancara
Pertama, apakah Anda memahami ClientHello luar (outer) dan dalam (inner)? ClientHelloOuter menyediakan bentuk kompatibilitas sementara target sebenarnya ditempatkan di ClientHelloInner yang dienkripsi dengan kunci publik server yang telah dikonfigurasi.
Kedua, dapatkah Anda menjelaskan pengiriman konfigurasi? ECHConfig berisi kunci publik dan metadata algoritma; ini dapat ditemukan melalui rekaman DNS SVCB/HTTPS, tetapi keaslian (authenticity) dan kesegaran (freshness) tetap penting.
Ketiga, tahukah Anda bahwa ECH bukanlah anonimitas end-to-end? DNS, IP, waktu, sertifikat, dan jalur tanpa ECH masih dapat mengungkapkan informasi.
Keempat, dapatkah Anda menjelaskan fallback kegagalan? Klien dapat mencoba lagi atau mengirim ClientHello normal ketika ECH tidak tersedia. Kebijakan tidak boleh menganggap upaya privasi yang gagal sebagai keberhasilan.
Kelima, dapatkah Anda merancang verifikasi? Periksa ekstensi handshake, metrik edge, tingkat hit konfigurasi, dan tingkat fallback alih-alih hanya memeriksa keberhasilan HTTPS.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah klien, proxy edge, dan pustaka TLS mendukung RFC 9849?
- Bagaimana ECHConfig dikirimkan, dan bagaimana DNSSEC atau DNS terenkripsi ditangani?
- Apakah layanan memiliki frontend bersama dan beberapa nama backend?
- Apakah fallback plaintext-SNI diizinkan, atau apakah kegagalan privasi harus menjadi hard failure?
- Apakah kita melindungi domain, nama tenant, atau metadata lalu lintas yang lebih luas?
- Bisakah telemetri mencatat keberhasilan ECH tanpa mencatat nama inner?
Kerangka jawaban 30 detik
"ECH menempatkan target sebenarnya di ClientHelloInner dan mengenkripsinya dengan HPKE menggunakan kunci publik yang dipublikasikan di ECHConfig; ClientHelloOuter menjaga kompatibilitas handshake. ECHConfig dapat dikirimkan melalui DNS SVCB/HTTPS, dengan pemeriksaan keaslian dan kesegaran. Saat terjadi kegagalan, kebijakan memilih fallback atau hard failure, dan keberhasilan TLS bukanlah keberhasilan privasi. Verifikasi menggabungkan ekstensi handshake, metrik edge, hit konfigurasi, dan tingkat fallback sambil tetap mengakui bahwa DNS, IP, dan pola lalu lintas tetap terlihat."
Jawaban langkah demi langkah
Langkah 1: Pisahkan kedua pesan ClientHello
Klien membangun ClientHelloInner dengan SNI sebenarnya dan ekstensi yang ingin disembunyikan, kemudian membuat ClientHelloOuter sebagai pesan kompatibilitas. Server atau edge menggunakan kunci ECHConfig untuk mendekripsi pesan inner; jika tidak bisa, ia menangani kegagalan sesuai dengan protokol.
Langkah 2: Pahami HPKE dan konfigurasi
ECHConfig membawa versi, kunci publik, cipher suite, dan metadata server. Klien menggunakan HPKE untuk melindungi ClientHelloInner, sementara server memegang kunci privat yang cocok. Rotasi memerlukan masa berlaku yang tumpang tindih (overlapping), kontrol cache, dan pencabutan; jangan melakukan hard-code kunci pada 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: Diskusikan pengiriman DNS dan keaslian
ECHConfig dapat ditemukan melalui rekaman SVCB/HTTPS. Evaluasi kesegaran, caching, dan risiko manipulasi; DNS terenkripsi hanya melindungi sebagian jalur, sedangkan DNSSEC dan kebijakan aplikasi menentukan kepercayaan. Lakukan refresh pada konfigurasi yang tidak valid atau kedaluwarsa.
Langkah 4: Tentukan kegagalan dan fallback
Kegagalan dekripsi, konfigurasi kedaluwarsa, GREASE, atau ketidakcocokan ekstensi dapat memicu percobaan ulang atau handshake biasa. Tentukan domain mana yang mengizinkan fallback dan persyaratan privasi mana yang memerlukan hard failure, lalu catat alasannya. Fallback bukanlah keberhasilan ECH.
Langkah 5: Identifikasi eksposur yang tersisa
ECH menyembunyikan nama target di ClientHello, tetapi kueri DNS, IP tujuan, waktu, ukuran paket, sertifikat, dan perilaku aplikasi masih dapat mendukung analisis lalu lintas. Nyatakan tujuannya sebagai pengurangan eksposur metadata handshake tertentu, bukan anonimitas.
Langkah 6: Rencanakan penerapan dan rotasi kunci
Terapkan kunci privat edge dengan hak akses paling rendah (least privilege) dan jejak audit, serta publikasikan konfigurasi lama dan baru yang tumpang tindih. Cache multi-wilayah membutuhkan versi yang konsisten dan pembatalan (invalidation). Jika kunci disusupi, cabut konfigurasi lama, persingkat TTL, dan pantau tingkat fallback.
Langkah 7: Bangun penerimaan end-to-end
Uji klien dengan dan tanpa ECH, beberapa jalur DNS, dan beberapa node edge. Catat negosiasi ekstensi, versi konfigurasi, kegagalan dekripsi, tingkat fallback, latensi handshake, dan kesalahan koneksi. Validasi paket tidak boleh mencatat nama inner yang sensitif.
Contoh jawaban
"ECH adalah ekstensi handshake TLS, bukan terowongan lapisan aplikasi. Klien menempatkan SNI sebenarnya di ClientHelloInner, mengenkripsinya dengan HPKE menggunakan kunci publik ECHConfig, dan mengirimkan ClientHelloOuter yang kompatibel. ECHConfig dapat ditemukan melalui SVCB/HTTPS, sehingga penerapan harus menangani keaslian DNS, caching, dan rotasi.
Saya akan menentukan kebijakan kegagalan secara eksplisit: hard-fail pada endpoint yang sensitif terhadap privasi dan amati fallback biasa pada endpoint kompatibilitas. Telemetri mencakup negosiasi, hit konfigurasi, kegagalan dekripsi, fallback, dan latensi handshake tanpa mencatat nama inner. DNS, IP, sertifikat, dan pola lalu lintas masih memerlukan analisis privasi terpisah. Penerimaan mencakup klien, jalur DNS, dan rotasi kunci."
Kesalahan umum
- Mengklaim ECH menyembunyikan semua lalu lintas → DNS, IP, dan waktu tetap terlihat → nyatakan tujuan privasi yang terbatas.
- Melakukan hard-coding kunci ECHConfig → Rotasi dan pencabutan menjadi sulit → gunakan konfigurasi yang dapat di-refresh.
- Hanya memeriksa keberhasilan HTTPS → Fallback biasa dihitung sebagai ECH → catat ekstensi dan alasan fallback.
- Mengabaikan manipulasi DNS dan cache basi → Klien menggunakan konfigurasi yang buruk → evaluasi keaslian, TTL, dan refresh.
- Memperlakukan SNI luar sebagai target sebenarnya → Nama kompatibilitas disalahpahami → pisahkan nama publik dan SNI inner.
- Memutar kunci tanpa tumpang tindih → Klien multi-wilayah gagal secara intermiten → gunakan rencana tumpang tindih dan pembatalan.
- Mencatat nama inner → Telemetri membocorkan kembali privasi → hanya catat hash, versi, dan status.
- Mengabaikan klien yang tidak didukung → Pengguna nyata tidak dapat terhubung → pertahankan aturan fallback atau hard-fail yang eksplisit.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Bagaimana hubungan antara ECH dan DoH/DoT?
ECH melindungi TLS ClientHello; DoH/DoT melindungi transport DNS. Keduanya menangani tahapan yang berbeda dan dapat digabungkan, tetapi tidak ada yang menggantikan yang lain.
Pertanyaan lanjutan 2: Mengapa ClientHelloOuter diperlukan?
Ini menyediakan bentuk kompatibilitas sehingga middlebox yang tidak memahami ECH masih dapat memproses handshake sementara target sebenarnya tetap berada di dalam pesan inner yang dienkripsi.
Pertanyaan lanjutan 3: Haruskah ECH selalu melakukan fallback saat gagal?
Tidak. Kebijakan tergantung pada persyaratan privasi dan ketersediaan. Endpoint yang sensitif terhadap privasi dapat melakukan hard-fail; endpoint kompatibilitas dapat melakukan fallback tetapi harus membuat hal itu dapat diamati dan dihitung.
Pertanyaan lanjutan 4: Bagaimana Anda memverifikasi bahwa middlebox tidak merusak ECH?
Catat negosiasi secara terpisah di klien, edge, dan server, lalu bandingkan keberhasilan, fallback, dan kesalahan handshake di seluruh jalur proxy.
Pertanyaan lanjutan 5: Apa yang terjadi setelah kunci disusupi?
Cabut atau hentikan publikasi ECHConfig lama, persingkat TTL cache, terapkan kunci baru, dan pantau kegagalan dekripsi serta fallback. ClientHello yang terekspos sebelumnya tidak dapat dibuat privat secara retroaktif.
Pertanyaan lanjutan 6: Apakah ECH menyembunyikan nama domain dalam sertifikat?
Ini terutama menyembunyikan nama target dalam handshake. Sertifikat, DNS, IP, dan informasi aplikasi mungkin masih mengorelasikan domain, sehingga penyembunyian domain secara menyeluruh tidak dapat dijamin.