TLS 1.3 mengenkripsi sebagian besar pesan handshake setelah ServerHello, tetapi ClientHello awal dikirim sebelum key handshake tersebut tersedia. Akibatnya, field pada flight pertama masih terlihat oleh pengamat jaringan. Server Name Indication (SNI) sangat sensitif karena dapat menunjukkan layanan yang dituju meski sertifikat berikutnya dan traffic aplikasi sudah terenkripsi.
RFC 9849 mendefinisikan Encrypted Client Hello (ECH) untuk mempersempit paparan itu. ECH tidak mengenkripsi seluruh paket pertama. Mekanisme ini membentuk dua pesan ClientHello dengan peran berbeda: ClientHelloInner privat yang memuat parameter koneksi untuk backend dan ClientHelloOuter publik yang membawa representasi terenkripsi dari pesan inner.
Pesan inner membawa intent handshake privat
Client dengan ECHConfig yang kompatibel lebih dulu membentuk ClientHelloInner seperti ClientHello TLS 1.3 biasa. Nilai sensitif, termasuk nama server sebenarnya, ditempatkan di sana. Client kemudian mengodekan pesan tersebut dan mengenkripsinya dengan Hybrid Public Key Encryption (HPKE) memakai public key serta algoritma yang dinyatakan konfigurasi ECH terpilih.
Ciphertext hasilnya ditempatkan pada extension encrypted_client_hello di ClientHelloOuter. Pesan outer tetap terlihat karena client-facing server harus menerima dan memprosesnya sebelum dapat memulihkan pesan inner.
Pemisahan ini membentuk batas privasi yang spesifik:
pengamat jaringan
|
v
ClientHelloOuter
SNI publik
extension outer terlihat
encrypted_client_hello = HPKE(ClientHelloInner)
|
v
SNI asli + parameter privatECH melindungi informasi yang ditempatkan di pesan inner; mekanisme ini tidak membuat setiap karakteristik pembentukan koneksi menjadi tersembunyi.
ECHConfig memasok parameter enkripsi
ECH bergantung pada konfigurasi yang diterima client sebelum handshake terlindungi. ECHConfig memuat public key HPKE, identifier konfigurasi, pilihan kriptografi yang didukung, dan public_name untuk handshake yang terlihat dari luar.
RFC 9849 mendefinisikan format konfigurasi dan menyerahkan publikasi melalui DNS kepada mekanisme record SVCB dan HTTPS untuk iklan ECH. Client juga dapat memperoleh konfigurasi melalui mekanisme distribusi tepercaya lain.
Memiliki konfigurasi tidak sama dengan memiliki private key. Client hanya memerlukan material publik untuk mengenkripsi. Client-facing server memerlukan private key pasangannya untuk mendekripsi pesan inner.
Kesegaran konfigurasi penting secara operasional. Jika client memakai key yang tidak lagi diterima server, dekripsi dapat gagal walaupun layanan saat ini mendukung ECH. Protokol menyediakan jalur terkontrol untuk memasok konfigurasi retry.
Pesan outer adalah envelope, bukan paket pengalih
ClientHelloOuter merupakan ClientHello yang valid secara sintaks dan berperan pada jalur rejection. Pesan ini dapat membawa SNI publik yang berasal dari public_name dalam konfigurasi ECH, bersama nilai yang sesuai untuk endpoint yang terlihat dari luar.
Payload terenkripsi tidak berdiri terpisah dari konteks outer. RFC 9849 mengautentikasi ClientHelloOuter sebagai associated data pada operasi HPKE. Secara konseptual, enkripsi mengikat pesan privat dengan field handshake outer yang relevan, bukan memperlakukan ciphertext sebagai blob yang bebas dipindahkan.
Sejumlah extension dapat diduplikasi antara pesan inner dan outer. ECH juga mendefinisikan ech_outer_extensions, sehingga nilai extension outer tertentu dapat direferensikan saat merekonstruksi pesan inner. Aturan rekonstruksi menolak referensi yang hilang, berulang, berubah urutan, atau tidak valid. Pemeriksaan tersebut mencegah kompresi extension menjadi transformasi tanpa batas.
Acceptance menentukan ClientHello yang mengendalikan TLS
Setelah client-facing server berhasil mendekripsi payload ECH yang valid, server merekonstruksi ClientHelloInner lalu memproses atau meneruskan pesan inner itu untuk handshake TLS. Backend bertindak seolah pesan inner tersebut adalah ClientHello. Preferensi dan kontribusi transcript dari pesan inner, bukan envelope publik, mengendalikan handshake ECH yang diterima.
Client juga memerlukan bukti terautentikasi bahwa server menerima ECH. RFC 9849 mendefinisikan acceptance confirmation yang diturunkan dari state handshake. Pada ServerHello normal, konfirmasi menempati delapan byte terakhir ServerHello.random. HelloRetryRequest memakai nilai konfirmasi khusus dalam extension ECH.
Sinyal ini memiliki fungsi keamanan. Client tidak dapat menganggap ECH diterima hanya karena telah mengirim payload terenkripsi atau karena server melanjutkan handshake.
Rejection bukan izin diam-diam untuk mengirim data aplikasi
Server yang tidak dapat mendekripsi ECH dapat melanjutkan proses memakai ClientHelloOuter; kondisi ini disebut ECH rejection. Perilaku tersebut mendukung GREASE dan pemulihan konfigurasi tanpa membuat extension ECH yang tidak dikenali menjadi fatal pada sisi server.
Client menerapkan semantik yang lebih ketat. Ketika upaya ECH nyata ditolak, koneksi outer tidak digunakan untuk data aplikasi. Jika server memasok konfigurasi retry yang valid melalui mekanisme yang ditentukan, client dapat membuat koneksi baru memakai konfigurasi terkini.
Pemisahan ini penting untuk ketahanan downgrade. Penyerang jaringan tidak boleh dapat menghapus atau merusak ECH lalu membuat client diam-diam melanjutkan koneksi ke target privat melalui handshake biasa yang terekspos. Penanganan kegagalan dan retry merupakan bagian dari properti privasi, bukan sekadar perilaku kompatibilitas.
Field outer dan bentuk traffic tetap memaparkan informasi
ECH melindungi ClientHello inner yang telah dikodekan, tetapi pesan outer tetap dapat diamati. Nilai sensitif yang disalin ke ClientHelloOuter akan kehilangan perlindungan untuk nilai tersebut. RFC 9849 karena itu memperingatkan client agar tidak menaruh informasi privat spesifik server di extension outer.
Panjang juga dapat mengungkap struktur. Panjang payload terenkripsi mencerminkan pesan inner yang dikodekan jika padding tidak mengurangi sinyal tersebut. ECH mendefinisikan padding untuk EncodedClientHelloInner, tetapi perilaku lain yang terlihat masih dapat membedakan layanan.
Sasaran privasinya dibingkai sebagai anonymity set: server yang berada bersama perlu memiliki konfigurasi dan perilaku TLS yang terlihat dari luar secara cukup konsisten agar koneksinya sulit dibedakan. Urutan extension, batas record, perilaku response, timing, routing IP, dan side channel lain tidak hilang hanya karena SNI dienkripsi.
ECH bukan pertahanan umum terhadap analisis traffic. Mekanisme ini melindungi kumpulan metadata handshake yang ditentukan, sementara karakteristik transport dan deployment memerlukan kontrol terpisah.
Deployment terpisah membentuk trust boundary kedua
ECH mendukung client-facing server di depan backend server. Front end memegang kemampuan dekripsi ECH, memulihkan ClientHelloInner, lalu meneruskan handshake hasilnya ke backend yang sesuai.
Arsitektur tersebut mengurangi metadata yang terekspos pada jalur client ke edge, tetapi tidak membuat pesan inner yang sudah dipulihkan menjadi rahasia dari client-facing server. Operator perlu memperlakukan private key ECH, pemrosesan front end, dan jalur antara front end dengan backend sebagai komponen yang sensitif terhadap keamanan.
Pemakaian satu private key ECH pada fleet yang sangat luas juga memperbesar dampak kompromi key tersebut. RFC 9849 mengizinkan operator membagi key dan merotasi konfigurasi; batas yang sesuai bergantung pada deployment, bukan pada satu topologi universal.
ECH mempersempit satu bagian TLS yang terekspos
Klaim keamanan yang tepat sengaja dibatasi. ECH mengenkripsi ClientHelloInner, termasuk SNI dan extension sensitif lain yang ditempatkan di sana, serta mengikat konten terenkripsi tersebut dengan handshake outer publik. Acceptance confirmation dan aturan retry mencegah rejection biasa berubah menjadi jalur downgrade yang tidak terlihat.
ECH tidak menyembunyikan alamat IP tujuan, tidak membuat seluruh field outer menjadi privat, tidak menutup semua sinyal ukuran atau timing, dan tidak menggantikan autentikasi sertifikat TLS normal. Nilainya terletak pada penghapusan metadata handshake sensitif dari pandangan pasif sambil mempertahankan perilaku protokol yang eksplisit ketika konfigurasi sudah usang, tidak didukung, atau ditolak.