ECH diaktifkan, tetapi SNI tetap terlihat: bagaimana cara memeriksa pada 2026

ECH — enkripsi nama situs dalam TLS handshake — pada Maret 2026 mendapatkan status standar (RFC 9849, Standards Track). Firefox dan Chrome mengaktifkannya secara default, Cloudflare memberikan kunci kepada hampir semua kliennya. Namun, bagi sebagian besar pengguna, ECH tidak berfungsi secara diam-diam: browser kembali ke handshake biasa, dan penyedia masih melihat ke mana Anda pergi.

Di bawah ini — cara memeriksa sendiri dalam satu menit apakah SNI Anda dienkripsi, mengapa seringkali tidak dienkripsi, dan dalam skenario mana ECH secara prinsip tidak berguna (spoiler: untuk anti-detect dan parsing — hampir selalu).

Apa yang sebenarnya disembunyikan ECH — dan apa yang tidak disembunyikan

Dalam TLS 1.3 biasa, semuanya dienkripsi, kecuali pesan pertama — ClientHello. Di dalamnya terdapat field SNI dengan domain yang Anda sambungkan dalam teks terbuka. Sebagian besar sistem penyaringan bekerja berdasarkan SNI: IP satu untuk ribuan situs di belakang CDN, dan domain terlihat.

ECH membagi ClientHello menjadi dua:

ClientHelloOuter — dikirim secara terbuka, tetapi dengan domain pembungkus yang dipalsukan. Di Cloudflare ini cloudflare-ech.com.
ClientHelloInner — domain asli, ALPN, dan daftar cipher, dienkripsi dengan kunci publik server.

Kunci untuk enkripsi ini diambil browser bukan dari koneksi, tetapi dari DNS — dari catatan HTTPS (tipe 65), parameter ech=. Dari sini muncul konsekuensi utama yang sering dilupakan: ECH tidak mungkin tanpa DNS terenkripsi. Jika permintaan DNS dikirim dalam UDP/53 terbuka, pengamat hanya melihat nama domain sebelum handshake, dan resolver penyaring dapat menghapus parameter ech= dari respons — dan ECH tidak akan diaktifkan.

Apa yang tidak disembunyikan ECH sama sekali:

Alamat IP tujuan — selalu terlihat;
volume dan waktu lalu lintas;
jejak TLS klien (JA3/JA4) — kumpulan cipher dan ekstensi tetap ada di bagian terbuka;
Anda untuk situs itu sendiri — server setelah dekripsi melihat semua yang dilihat sebelumnya.

Poin terakhir adalah alasan mengapa ECH tidak berhubungan dengan penghindaran sistem anti-bot. Cloudflare, DataDome, dan Akamai bekerja di sisi server: mereka tidak peduli apakah SNI dienkripsi dalam perjalanan. Jika tujuannya adalah untuk tidak terdeteksi saat otomatisasi, lapisan yang bekerja adalah penggantian jejak TLS itu sendiri, yang telah kita bahas dalam materi tentang penghindaran jejak JA4 melalui curl-cffi.

Pemeriksaan №1: apakah ECH berfungsi sekarang (10 detik)

Buka di browser:

https://crypto.cloudflare.com/cdn-cgi/trace

Cari baris sni=. Ada dua kemungkinan:

sni=encrypted — ECH berfungsi, nama situs disembunyikan dalam perjalanan;
sni=plaintext — ECH tidak diterapkan, domain terlihat dalam teks terbuka.

Alamat yang sama melalui curl di terminal akan selalu mengembalikan sni=plaintext — curl biasa tidak dapat melakukan ECH, dan ini adalah panduan yang nyaman: inilah tampilan "dimatikan".

Pemeriksaan №2: apakah domain memiliki kunci ECH (dig, tanpa browser)

ECH hanya akan diaktifkan jika domain memiliki catatan HTTPS dengan parameter ech= di DNS. Lihat catatan mentah:

dig +short TYPE65 example.com @1.1.1.1

Dalam respons, cari byte FE0D — ini adalah kode ekstensi ECH, diikuti oleh ECHConfig. Contoh praktis: pada saat persiapan materi, crypto.cloudflare.com dan domain kami proxycove.com memiliki catatan sepanjang 133–136 byte yang berisi baik FE0D maupun nama palsu cloudflare-ech.com dalam bentuk hex. Namun, catatan di cloudflare.com pendek, 61 byte: hanya ALPN dan petunjuk IP, tanpa ECH. Artinya, bahkan di dalam infrastruktur Cloudflare, ECH tidak diberikan kepada semua domain secara acak — jangan heran jika situs tertentu tidak memilikinya.

Jika dig mengeluh ignoring invalid type HTTPS — Anda memiliki versi lama dari utilitas, gunakan bentuk numerik TYPE65, seperti dalam perintah di atas.

Mengapa ECH tidak diaktifkan untuk Anda: lima alasan secara berurutan

DNS terenkripsi dimatikan. Tanpa DoH, browser tidak akan mendapatkan ECHConfig dalam bentuk yang tepercaya. Di Firefox: Pengaturan → Privasi → DNS melalui HTTPS dalam mode "Tinggi" atau "Perlindungan Maksimal". Di Chrome: Pengaturan → Keamanan → Gunakan DNS Aman.
Domain tidak memiliki catatan HTTPS dengan ech= — diperiksa dengan perintah dari blok di atas. Di sini tidak ada yang tergantung pada Anda, ini adalah keputusan pemilik situs dan CDN-nya.
Resolver menghapus parameter. Server DNS korporat dan penyedia biasanya dapat memberikan catatan HTTPS tanpa ech=. Periksa dengan meminta catatan langsung dari resolver publik (@1.1.1.1) dan membandingkan dengan respons sistem.
Flag browser direset. Di Firefox, periksa network.dns.echconfig.enabled dan network.dns.http3_echconfig.enabled di about:config — keduanya harus true.
Di tengah ada gerbang inspeksi. Ini akan dibahas di bagian berikutnya.

Bagaimana ECH dilanggar: dua skema berbeda

Firewall korporat: penurunan yang tenang

Pemasok perangkat jaringan telah merilis resep siap pakai melawan ECH — mereka tidak siap kehilangan visibilitas lalu lintas. Cisco, misalnya, sejak basis aplikasi VDB 416 (Oktober 2025) mengidentifikasi "ECH Servers" sebagai aplikasi terpisah dan menawarkan dua pendekatan: menangkap koneksi dengan membuat ulang sertifikat dan menghapus ekstensi encrypted_client_hello dari ClientHello, atau bertindak lebih sederhana — di tingkat DNS: memblokir catatan HTTPS untuk domain ECH, memotong DoH/DoT/DoQ, memblokir domain kanari use-application-dns.net dan hanya mengizinkan DNS ke server korporat.

Kecerdikan skema pertama adalah bahwa ia tidak terlihat seperti pemblokiran. Server, tidak melihat ekstensi ECH, merespons seperti biasa, klien menganggap ECH "aman dimatikan" dan terhubung kembali dengan SNI terbuka. Situs terbuka, tidak ada kesalahan — dan nama domain tercatat di log gerbang.

Tingkat negara: koneksi hanya mati

Contoh Rusia menunjukkan ketepatan yang signifikan. Sejak 5 November 2024, penyaringan hanya berfungsi jika dua tanda secara bersamaan cocok: SNI dengan nilai cloudflare-ech.com ditambah keberadaan ekstensi ECH. Secara terpisah, tidak satu pun dari keduanya memicu pemblokiran — ECH ke domain pembungkus lainnya (misalnya, pengujian defo.ie atau tls-ech.dev) berjalan. Ini diimplementasikan bukan dengan memutuskan koneksi, tetapi dengan diam-diam membuang paket: halaman menggantung dan terputus karena timeout. TCP-based HTTP/2 dan QUIC/HTTP-3 juga terpengaruh. Roskomnadzor kemudian secara langsung menyatakan bahwa penggunaan TLS ECH melanggar undang-undang Rusia, dan merekomendasikan pemilik situs untuk meninggalkan CDN Cloudflare — ribuan sumber daya yang sepenuhnya legal, yang termasuk dalam pembungkus umum, terkena filter sekaligus.

Dalam situasi seperti itu, Firefox akan mencoba lagi setelah sekitar satu menit tanpa ECH — yang berarti pada akhirnya memberikan SNI terbuka, yang tidak direkomendasikan oleh spesifikasi karena alasan keamanan. Jika Anda melihat "situs memuat tepat satu menit, lalu terbuka" — ini hampir pasti itu.

Kapan ECH tidak cukup dan apa yang harus digunakan sebagai gantinya

Mari kita uraikan berdasarkan tugas dengan jujur.

Privasi dari penyedia di internet rumah. ECH + DoH — peningkatan yang baik dan gratis. Bekerja di tempat yang tidak dipotong.
Penghindaran penyaringan. ECH tidak dirancang untuk ini, dan praktik telah mengonfirmasi: begitu ia mulai mengganggu filter, ia dapat diidentifikasi dan dibungkam sepenuhnya. Tidak dapat mengandalkannya sebagai alat akses.
Parsing, multi-akuntansi, otomatisasi. ECH tidak memberikan apa pun: situs target melihat IP Anda, JA4 Anda, dan riwayat permintaan Anda. Hanya sumber IP dan kualitas jejak yang penting.

Dalam semua kasus di mana ECH tidak berhasil, lapisan yang lebih kasar tetapi lebih andal berfungsi: memindahkan TLS handshake ke luar jaringan yang dapat diamati. Ketika lalu lintas melewati proxy, pengamat di saluran Anda hanya melihat koneksi dengan node proxy — tidak ada SNI dari situs target di dalamnya sama sekali, terlepas dari apakah domain mendukung ECH atau tidak. Untuk akses sehari-hari dan bekerja dengan layanan yang sensitif terhadap reputasi IP, proxy residensial akan cocok; untuk aplikasi seluler dan platform yang sangat pilih-pilih tentang jenis koneksi — seluler.

Dan jangan lupa tentang DNS: proxy di browser tidak menjamin bahwa nama diresolusi melalui dirinya sendiri. Kebocoran DNS mengungkapkan tepat apa yang Anda coba sembunyikan — bagaimana cara memeriksanya, telah kita bahas dalam instruksi terpisah tentang memeriksa proxy untuk kebocoran DNS. Jika pertanyaannya adalah analisis mendalam lalu lintas di saluran, Anda harus melihat bukan pada ECH, tetapi pada transportasi itu sendiri.

Daftar periksa singkat

Buka crypto.cloudflare.com/cdn-cgi/trace dan lihat baris sni=.
Jika plaintext — aktifkan DoH di browser dan periksa lagi.
Jika tidak berhasil — periksa keberadaan kunci di domain: dig +short TYPE65 domain @1.1.1.1, cari FE0D.
Jika kunci ada, tetapi ECH tidak diterapkan — bandingkan respons resolver publik dan sistem: kemungkinan besar, parameter dihapus dalam perjalanan.
Koneksi menggantung selama satu menit dan terbuka — ECH dibungkam di tingkat jaringan; ECH tidak akan membantu di sini, diperlukan transportasi lain.

Kesimpulan

ECH adalah celah terakhir yang ditutup dengan rapi dalam privasi TLS, bukan alat akses dan apalagi bukan alat untuk otomatisasi. Ia bergantung pada DNS terenkripsi, dimatikan di tengah tanpa satu kesalahan pun di layar dan dibungkam sepenuhnya di tempat di mana ia mulai mengganggu. Memeriksanya layak — dua perintah di atas memakan waktu satu menit. Tetapi membangun penghindaran pemblokiran atau perlindungan dari sistem anti-bot di atasnya adalah hal yang tidak masuk akal: tugas-tugas ini diselesaikan di tingkat siapa IP dan jejak TLS yang dilihat server di ujung lain.