ECH — sitenin adının TLS el sıkışmasında şifrelenmesi — Mart 2026'da standart statüsü kazandı (RFC 9849, Standards Track). Firefox ve Chrome bunu varsayılan olarak dahil ediyor, Cloudflare neredeyse tüm müşterilerine anahtar dağıtıyor. Ancak çoğu kullanıcı için ECH sessizce çalışmıyor: tarayıcı normal bir el sıkışmasına geçiyor ve sağlayıcı hala nereye gittiğinizi görüyor.
Aşağıda, SNI'nin sizin için şifrelenip şifrelenmediğini bir dakikada nasıl kontrol edeceğinizi, neden çoğu zaman şifrelenmediğini ve hangi senaryolarda ECH'nin temelde işe yaramadığını (spoiler: anti-detect ve parsing için — neredeyse her zaman) bulacaksınız.
ECH neyi gizler — ve neyi gizlemez
Normal TLS 1.3'te her şey şifrelenmiştir, ilk mesaj olan ClientHello dışında. İçinde, bağlandığınız alan adı ile birlikte açık metin olarak SNI alanı bulunmaktadır. Çoğu filtreleme sistemi SNI üzerinden çalışır: IP, CDN için binlerce siteye aittir ve alan adı görünür.
ECH, ClientHello'yu ikiye böler:
- ClientHelloOuter — açık olarak gider, ancak sahte bir alan adı ile sarılmıştır. Cloudflare için bu
cloudflare-ech.com. - ClientHelloInner — gerçek alan adı, ALPN ve şifre listesi, sunucunun kamu anahtarı ile şifrelenmiştir.
Bu şifreleme için anahtar, tarayıcı tarafından bağlantıdan değil, DNS'ten alınır — HTTPS kaydı (tip 65), ech= parametresi ile. Buradan unutulmaması gereken önemli bir sonuç çıkar: Şifreli DNS olmadan ECH mümkün değildir. Eğer DNS isteği açık UDP/53 üzerinden gidiyorsa, gözlemci el sıkışmasından önce alan adını görür ve filtreleme çözümleyicisi ech= parametresini yanıttan çıkarabilir — bu durumda ECH etkinleşmez.
ECH'nin hiç gizlemediği şeyler:
- Hedef IP adresi — her zaman görünür;
- trafik hacmi ve zamanlamaları;
- müşteri TLS parmak izi (JA3/JA4) — şifreler ve uzantılar açık kısımda kalır;
- sizi site için — sunucu, şifre çözme işleminden sonra daha önce gördüğü her şeyi görür.
Son madde, ECH'nin anti-bot sistemlerini aşmakla ilgisi olmadığına dair bir neden. Cloudflare, DataDome ve Akamai sunucu tarafında çalışır: SNI'nin yol boyunca şifrelenip şifrelenmediği onlar için önemli değildir. Eğer amaç otomasyonda dikkat çekmemekse, tamamen farklı bir katman çalışır: TLS parmak izinin değiştirilmesi, daha önce curl-cffi ile JA4 parmak izini aşma konusunu ele aldığımızda.
Kontrol #1: ECH şu anda çalışıyor mu (10 saniye)
Tarayıcıda açın:
https://crypto.cloudflare.com/cdn-cgi/trace
sni= satırını bulun. İki olasılık vardır:
sni=encrypted— ECH çalışıyor, sitenin adı yol boyunca gizli;sni=plaintext— ECH uygulanmadı, alan adı açık metin olarak gitti.
Aynı adres, terminalde curl ile her zaman sni=plaintext döndürecektir — normal bir curl ECH'yi desteklemez ve bu, "kapalı" görünümüdür.
Kontrol #2: Alan adının ECH anahtarı var mı (dig, tarayıcı olmadan)
ECH, yalnızca alan adının DNS'inde ech= parametresi ile bir HTTPS kaydı varsa etkinleşir. Ham kaydı kontrol edin:
dig +short TYPE65 example.com @1.1.1.1
Cevapta FE0D baytlarını arayın — bu ECH uzantısının kodudur, ardından ECHConfig gelir. Pratik bir örnek: materyalin hazırlanması sırasında crypto.cloudflare.com ve alan adımız proxycove.com için 133–136 bayt uzunluğunda bir kayıt hem FE0D hem de sahte isim cloudflare-ech.com hex biçiminde içerir. Ancak cloudflare.com için kayıt kısa, 61 bayt: yalnızca ALPN ve IP ipuçları, ECH olmadan. Yani Cloudflare altyapısının içinde bile ECH, tüm alan adlarına dağıtılmıyor — belirli bir sitede yoksa şaşırmayın.
Eğer dig ignoring invalid type HTTPS hatası veriyorsa — eski bir sürüm kullanıyorsunuz, yukarıdaki komutta olduğu gibi sayısal form TYPE65 kullanın.
ECH'nin neden etkinleşmediği: beş neden sırasıyla
- Şifreli DNS kapalı. DoH olmadan tarayıcı, ECHConfig'i güvenilir bir şekilde alamaz. Firefox'ta: Ayarlar → Gizlilik → HTTPS üzerinden DNS "Yüksek" veya "Maksimum koruma" modunda. Chrome'da: Ayarlar → Güvenlik → Güvenli DNS kullan.
- Alan adının sadece
ech=ile bir HTTPS kaydı yoktur — yukarıdaki blokta verilen komutla kontrol edilir. Burada sizin kontrolünüzde olmayan bir durumdur, bu site sahibinin ve CDN'nin kararına bağlıdır. - Çözümleyici parametreyi kesiyor. Kurumsal ve sağlayıcı DNS sunucuları genellikle
ech=olmadan HTTPS kayıtları döndürebilir. Bunu, doğrudan bir kamu çözümleyicisinden (@1.1.1.1) kayıt isteyerek ve sistem yanıtı ile karşılaştırarak kontrol edin. - Tarayıcı bayrakları sıfırlanmış. Firefox'ta
network.dns.echconfig.enabledvenetwork.dns.http3_echconfig.enabledabout:configiçinde — her ikisi detrueolmalıdır. - Orta noktada inceleme yapan bir geçit var. Bu, bir sonraki bölümde ele alınacaktır.
ECH'yi nasıl kırıyorlar: iki farklı şemalar
Kurumsal güvenlik duvarı: sessiz bir düşüş
Ağ ekipmanı satıcıları, ECH'ye karşı hazır tarifler yayınladılar — trafik görünürlüğünü kaybetmeye hazır değiller. Örneğin, Cisco, Ekim 2025'teki VDB 416 uygulama veritabanından itibaren "ECH Sunucuları"nı ayrı bir uygulama olarak tanımlıyor ve iki yaklaşım öneriyor: sertifika yeniden oluşturularak bağlantıyı yakalamak ve ClientHello'dan encrypted_client_hello uzantısını kesmek veya daha basit bir şekilde — DNS seviyesinde: ECH alanları için HTTPS kayıtlarını engellemek, DoH/DoT/DoQ'yu kesmek, use-application-dns.net canary alanını engellemek ve DNS'i yalnızca kurumsal sunuculara izin vermek.
İlk şemanın kurnazlığı, engelleme gibi görünmemesidir. Sunucu ECH uzantısını görmediğinde, normal şekilde yanıt verir, istemci ECH'yi "güvenli bir şekilde kapalı" olarak kabul eder ve açık SNI ile yeniden bağlanır. Site açılır, hata yok — ancak alan adı geçidin günlüğüne düşer.
Ülke düzeyi: bağlantı sadece ölür
Rus örneği, kesinliği ile dikkat çekicidir. 5 Kasım 2024'ten itibaren filtreleme yalnızca iki belirti eşleştiğinde çalışır: cloudflare-ech.com değerine sahip SNI artı ECH uzantısının varlığı. Tek başına ne biri ne de diğeri engellemeye neden olur — ECH, diğer sarma alanlarına (örneğin, test alanları defo.ie veya tls-ech.dev) geçer. Bu, bağlantının sıfırlanmasıyla değil, paketlerin sessizce atılmasıyla gerçekleştirilmiştir: sayfa takılır ve zaman aşımına uğrar. TCP tabanlı HTTP/2 ve QUIC/HTTP-3 de etkilenir. Roskomnadzor, o zaman TLS ECH kullanımının Rus yasalarını ihlal ettiğini açıkça belirtti ve site sahiplerine Cloudflare CDN'den ayrılmalarını önerdi — bir seferde binlerce tamamen yasal kaynağın filtreye takılması sağlandı.
Firefox, böyle bir durumda yaklaşık bir dakika sonra ECH olmadan yeniden denemektedir — yani sonuçta açık SNI verir, bu da güvenlik nedenleriyle spesifikasyonda önerilmez. Eğer "site tam bir dakika yükleniyor, sonra açılıyor" şeklinde gözlemliyorsanız — bu muhtemelen odur.
ECH'nin yetersiz olduğu durumlar ve onun yerine ne koymak gerekir
Görevleri dürüstçe ayıralım.
- Ev internetinde sağlayıcıdan gizlilik. ECH + DoH — iyi ve ücretsiz bir iyileştirme. Kesilmediği yerlerde çalışır.
- Filtrelemeyi aşmak. ECH bunun için tasarlanmamıştır ve pratik bunu doğrulamıştır: ne zaman filtrelerle sorun yaşamaya başlasa, tanımlanıp tamamen susturulmayı öğrenmiştir. Ona bir erişim aracı olarak güvenmek mümkün değildir.
- Parsing, çoklu hesap açma, otomasyon. ECH hiçbir şey sağlamaz: hedef site IP'nizi, JA4'ünüzü ve istek geçmişinizi görür. Önemli olan yalnızca IP kaynağı ve parmak izinin kalitesidir.
ECH'nin yetersiz kaldığı tüm durumlarda, daha kaba ama güvenilir bir katman çalışır: TLS el sıkışmasını gözlemlenen ağın dışına taşımak. Trafik bir proxy üzerinden geçerken, gözlemci sizin kanalınızdaki yalnızca proxy düğümü ile bağlantıyı görür — hedef sitenin SNI'si hiç yoktur, alan adı ECH'yi desteklese bile. Günlük erişim ve IP itibarı hassas olan hizmetlerle çalışmak için rezidans proxy'leri uygundur; mobil uygulamalar ve bağlantı türüne özellikle dikkat eden platformlar için — mobil proxy'ler.
Ve DNS'i unutmayın: tarayıcıdaki proxy, isimlerin onun üzerinden çözüldüğünü garanti etmez. DNS sızıntısı, gizlemeye çalıştığınız şeyi tam olarak ortaya çıkarır — bunu nasıl kontrol edeceğinizi, DNS sızıntısını kontrol etme konusundaki ayrı bir kılavuzda ele aldık. Eğer sorun tam olarak kanal üzerindeki trafik analizi ise, ECH'ye değil, taşıma katmanına bakmalısınız.
Kısa kontrol listesi
crypto.cloudflare.com/cdn-cgi/traceaçın vesni=satırını kontrol edin.plaintextise — tarayıcıda DoH'u etkinleştirin ve tekrar kontrol edin.- Yardımcı olmadı — alan adının anahtarını kontrol edin:
dig +short TYPE65 alanadı @1.1.1.1,FE0D'yi arayın. - Anahtar var, ancak ECH uygulanmıyorsa — kamu ve sistem çözümleyicilerinin yanıtlarını karşılaştırın: muhtemelen parametre yol boyunca kesiliyor.
- Bağlantı bir dakika takılıyor ve açılıyor — ECH ağ düzeyinde susturuluyor; ECH burada yardımcı olmaz, başka bir taşıma gerekir.
Sonuç
ECH, TLS'deki gizlilik için dikkatlice kapatılmış son delik olup, bir erişim aracı ve özellikle otomasyon aracı değildir. Şifreli DNS'e bağlıdır, ortada hiçbir hata olmadan kapatılır ve engellemeye başladığında tamamen susturulur. Onu kontrol etmekte fayda var — yukarıdaki iki komut bir dakikanızı alır. Ancak, onu engellemeleri aşmak veya anti-bot sistemlerinden korunmak için kullanmak anlamsızdır: bu görevler, sunucunun diğer uçta gördüğü IP ve TLS parmak izinin kim olduğunu belirleme düzeyinde çözülmektedir.