Encrypted ClientHello Memisahkan Routing Publik dari Identitas TLS Privat

TLS 1.3 mengenkripsi sebagian besar pesan handshake, tetapi koneksi biasa tetap memperlihatkan ClientHello awal. Pesan ini dapat memuat Server Name Indication, sehingga pengamat di jalur jaringan dapat mengaitkan koneksi dengan hostname yang diminta sebelum trafik aplikasi terlindungi.

Encrypted ClientHello, yang distandardisasi dalam RFC 9849, mengubah batas tersebut. Client membuat ClientHelloInner privat berisi parameter khusus layanan, lalu membungkusnya di dalam ClientHelloOuter publik. Pesan outer tetap dapat dipakai infrastruktur yang menghadap client, sementara field sensitif di dalamnya dilindungi dengan Hybrid Public Key Encryption.

Mekanisme ini tidak membuat jaringan tujuan menjadi tidak terlihat. ECH memisahkan identitas yang dibutuhkan layanan TLS backend dari informasi yang harus tetap terlihat agar koneksi mencapai front end yang mendukung ECH.

Dua pesan ClientHello melayani batas trust yang berbeda

Pesan inner menjadi TLS ClientHello efektif ketika ECH diterima. Pesan ini berisi nama server dan parameter untuk menegosiasikan koneksi terlindungi. Pesan outer adalah envelope yang dapat membawa nilai yang lebih sedikit mengidentifikasi, serta extension encrypted_client_hello yang berisi representasi inner terenkripsi.

Pemisahan ini memungkinkan beberapa layanan backend berbagi infrastruktur yang menghadap client dengan tampilan eksternal serupa. Pengamat masih dapat melihat alamat infrastruktur dan handshake outer, tetapi tidak memperoleh nama server privat dalam plaintext hanya karena TLS memerlukan pesan awal dari client.

Ruang privasi bergantung pada bentuk deployment. Server yang ditempatkan bersama dengan konfigurasi TLS dan perilaku eksternal yang konsisten dapat membentuk anonymity set. Ukuran packet, pola extension, timing, alamat, atau penanganan koneksi yang khas dapat mempersempit set tersebut meskipun nama inner tetap terenkripsi.

ECH melindungi informasi handshake tertentu; ECH tidak menghapus semua sinyal analisis trafik.

HPKE mengikat pesan inner ke envelope outer

ECH menggunakan HPKE untuk mengenkripsi ClientHello inner yang telah di-encode dengan public key dari konfigurasi ECH. Konfigurasi itu mengidentifikasi material key dan algoritma HPKE yang didukung, serta public name untuk layanan yang menghadap client.

Pesan outer bukan padding tanpa autentikasi di sekitar hostname terlindungi. ECH memasukkan representasi ClientHelloOuter sebagai associated data pada operasi HPKE. Dengan begitu, input outer yang relevan diautentikasi bersama isi inner terenkripsi.

Pengikatan ini penting karena sebagian parameter TLS tetap berada di pesan outer atau diturunkan darinya demi efisiensi transport. Jika penyerang dapat mengubah nilai tersebut secara terpisah sambil mempertahankan inner yang valid, dua sudut pandang koneksi dapat berbeda secara berbahaya. Konstruksi RFC 9849 membatasi kemungkinan itu.

Desain ECH lebih luas daripada sekadar mengenkripsi SNI. Melindungi satu extension saja masih menyisakan parameter handshake lain yang dapat membocorkan identitas atau memengaruhi negosiasi.

DNS membawa konfigurasi key sebelum TLS dimulai

Client tidak dapat mengenkripsi ClientHelloInner tanpa public key ECH. RFC 9848 mendefinisikan bootstrap melalui parameter ech pada resource record DNS HTTPS atau SVCB. Parameter ini membawa ECHConfigList dengan satu atau beberapa konfigurasi.

Client membutuhkan konfigurasi tersebut sebelum dapat membuat ECH offer yang sebenarnya. Rotasi key, caching DNS, rollout endpoint, dan konfigurasi front end karena itu berkaitan langsung dengan privasi TLS.

Konfigurasi yang dipublikasikan berisi material publik. Private key yang sesuai harus tersedia pada server yang diharapkan mendekripsi offer. Konfigurasi yang dipublikasikan sebelum server tujuan siap memakai private key pasangannya dapat menyebabkan kegagalan koneksi.

ECH juga tidak otomatis merahasiakan record bootstrap DNS-nya. Perlindungan transport DNS dan autentikasi data DNS adalah persoalan arsitektur yang terpisah.

Penolakan adalah jalur retry, bukan izin downgrade

Material key ECH dapat berotasi dan client dapat menyimpan konfigurasi lama. Server yang menghadap client bisa menerima offer yang tidak dapat didekripsi walaupun layanan telah memakai key baru.

RFC 9849 menyediakan mekanisme retry yang terautentikasi. Saat ECH ditolak, koneksi tersebut tidak dipakai untuk data aplikasi. Client dapat mengautentikasi endpoint publik, memperoleh retry configuration sesuai aturan protokol, lalu membuat koneksi baru dengan material terbaru.

Kegagalan dekripsi tidak boleh dianggap sebagai izin untuk meneruskan trafik dengan nama privat yang terbuka dalam SNI plaintext. Jika demikian, gangguan di jaringan dapat menghapus perlindungan privasi.

Ketika DNS berhasil menunjukkan alternatif dengan konfigurasi ECH, client yang mendukung ECH tidak boleh beralih ke koneksi langsung dengan mengorbankan privasi ECH. Deployment yang menuntut identitas terlindungi dapat memilih kegagalan koneksi daripada downgrade transparan.

Public name memang sengaja terlihat

Konfigurasi ECH memuat public_name. Saat ECH ditolak, client mengautentikasi koneksi untuk public name tersebut, bukan identitas backend privat. Public name adalah bagian dari batas layanan eksternal dan memang tidak disembunyikan ECH.

ECH mengubah tingkat ketelitian pengamatan, bukan menghapusnya. Jaringan masih dapat mengenali provider dari alamat tujuan, perilaku DNS, atau public name. Yang dilindungi adalah layanan backend mana di dalam anonymity set yang hendak dituju client.

Nama front end yang digunakan bersama dan perilaku eksternal yang konsisten menciptakan set lebih besar. Setelah nama privat berada di dalam ECH, middlebox pasif tidak dapat mengandalkan nilai SNI itu tanpa ikut dalam arsitektur trust yang relevan.

Peran front end dan backend dapat dipisahkan

RFC 9849 mendukung model ketika server yang menghadap client dan backend merupakan sistem terpisah. Komponen front end memproses pesan outer dan memperoleh ClientHello inner; backend menjalankan handshake TLS dengan pesan inner sebagai input efektif.

Pembagian ini menciptakan batas baru untuk key dan penanganan pesan. Private key ECH memungkinkan dekripsi metadata handshake yang terlindungi, sehingga akses ke key tersebut sensitif bagi privasi meskipun berbeda dari private key sertifikat backend.

Front end yang dapat mendekripsi ECH tentu melihat handshake inner. ECH melindungi dari pengamat di luar peran itu, bukan dari infrastruktur yang memang berwenang melakukan dekripsi ECH. Private key backend tidak harus didistribusikan hanya karena front end memproses ECH.

GREASE membantu deployment protokol

Client tanpa konfigurasi ECH yang dapat digunakan dapat mengirim extension ECH GREASE dengan dummy offer yang secara sintaksis valid. Tujuannya menjaga jalur jaringan tetap toleran dan mengurangi ossification berdasarkan ada atau tidaknya extension tersebut.

GREASE tidak membuat identitas layanan inner terenkripsi. Byte yang tampak seperti ECH juga tidak membuktikan bahwa ClientHello privat berhasil dilindungi atau diterima. Keamanan ECH bergantung pada konfigurasi yang sesuai, pemrosesan HPKE yang berhasil, penerimaan server, dan verifikasi client.

Camouflage protokol dan kerahasiaan hasil negosiasi adalah properti yang berbeda.

Privasi bergantung pada seluruh koneksi

Mengenkripsi SNI menutup sinyal plaintext penting, tetapi alamat tujuan tetap terlihat oleh routing IP biasa. Layanan pada alamat unik masih mudah dikenali walaupun namanya tidak ada dalam handshake outer.

Perbedaan perilaku ALPN, pola terminasi koneksi, ukuran respons, retry, atau karakteristik eksternal lain dapat mengurangi indistinguishability praktis. ECH juga tidak menyembunyikan data aplikasi dari endpoint TLS.

ECH paling kuat ketika arsitektur menyediakan infrastruktur front end bersama, perilaku outer konsisten, distribusi key benar, dan bootstrap tahan downgrade. Mekanisme ini menempatkan pemilihan layanan privat di balik batas kriptografis, sambil menyisakan struktur publik yang cukup untuk mencapai front end yang berwenang.