Şifreli İstemci Merhaba ve DoH: Çevre Güvenlik Duvarlarının Artık Göremediği Şeyler

Yirmi yıldır, ağ güvenlik duvarları ve proxy'ler, şifrelenmiş trafiğin nereye gittiğini bilmek için şifrelenmemiş bir alana güveniyordu: Sunucu Adı Göstergesi (SNI), bir istemcinin TLS anlaşmasının ilk mesajında ​​duyurduğu ana bilgisayar adı. HTTPS üzerinden DNS (DoH, RFC8484), bağlantıdan önce gelen DNS aramasını zaten gizlemişti. Artık RFC9849 olarak yayınlanan Şifreli İstemci Merhaba, SNI'nın kendisini gizler. Birlikte, çoğu çıkış filtrelemesinin üzerine inşa edildiği iki sinyali kaldırırlar.

ECH nasıl çalışır: bir iç ve bir dış ClientHello

ECH ile istemci iki ClientHello mesajı oluşturur. İçteki gerçek hedefi ve hassas parametreleri taşır ve sunucunun önceden yayınladığı genel anahtara HPKE ile şifrelenir. Açıkça gönderilen dıştaki, paylaşılan bir genel adı taşır, genellikle sağlayıcının ön ucunun adıdır, böylece bir gözlemci yalnızca müşterinin o sağlayıcıyla (RFC9849; Cloudflare'in açıklayıcısı) konuştuğunu öğrenir.

TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

Anahtarın geldiği yer: HTTPS DNS kaydı

İstemci, el sıkışmadan önce sunucunun ECH ortak anahtarına ihtiyaç duyar. Bunu, ech parametresi bir ECHConfigList taşıyan HTTPS kaynak kaydındaki (tip 65, RFC9460) DNS'den alır. Gerçek bir tanesini sorguladık. MacOS ile birlikte gelen dig, kaydı ismine göre bilmediğinden numaraya göre isteyin:

$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com

Bu DNS sorgusunun kendisi DoH üzerinden seyahat ederse, bir ağ gözlemcisi ne aramayı ne de ECH ile el sıkışmadaki ana bilgisayar adını görür. Bu makalenin konusu olan kombinasyon budur.

ECH'nin kullanılıp kullanılmayacağı müşteriye bağlıdır

ECH bir ağın etkinleştirdiği bir şey değildir; her müşteri karar verir. Tarayıcılar, genellikle kullanımda olan şifreli DNS'ye bağlı olarak Chrome Platformu Durumu desteği sağladı. Pek çok yazılım bunu hiç kullanmıyor. Cloudflare'in izleme uç noktası ne aldığını bildirir ve macOS'ta yerleşik curl ana bilgisayar adını hala açık bir şekilde göndermeye devam eder:

$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext

Yani günümüzün gerçekçi tablosu bir karışımdan oluşuyor: tarayıcılar ana bilgisayar adını giderek daha fazla gizlerken, diğer birçok program bunu gizlemiyor ve izlemeyi atlatmak için yazılan yazılımlar kasıtlı olarak ECH ve DoH'yi kullanmayı seçebiliyor.

Çevre güvenlik duvarı neyi kaybeder ve neyi korur?

Dürüst özet şu ki, uçtaki ana bilgisayar adı tabanlı filtreleme, ECH trafiği için çalışmayı durdururken, IP tabanlı kontroller çalışmaz. Bir ağ, pratikte tarayıcıların şifrelenmiş DNS üzerinden ECH anahtarları almasını engelleyen bilinen DoH çözümleyicilere yapılan bağlantıları yine de reddedebilir ve yine de adres aralıklarını engelleyebilir. Artık yapamayacağı şey, aynı sağlayıcının arkasındaki iki siteyi birbirinden ayırmak veya ECH'nin algılamak üzere tasarladığı şekillerde TLS'yi bozmadan birine izin verip diğerine engel olmaktır.

Görünürlük uç noktaya taşınır

Ana bilgisayar adının hiçbir zaman gizlenmediği tek yer, bağlantıyı kuran makinedir: program bunu adıyla istemiştir. ECH'nin çıkış kontrolünü uç noktaya doğru kaydırmasının nedeni budur. Ana bilgisayar tabanlı bir güvenlik duvarının el sıkışmayı okumasına hiç gerek yoktur; herhangi bir şifrelenmiş bayt ayrılmadan önce hangi işlemin hangi adrese bağlantı açtığını ve programın ne zaman bir adı, hangi adı çözümlediğini görür. Ayrıca, ECH'den önce bile bir ağ cihazının asla göremediği bir şeyi de görüyor: makinedeki hangi uygulamanın konuştuğu.

• Ana makine adına göre değil, uygulamaya göre karar verin: bir tarayıcı, bir senkronizasyon istemcisi ve bilinmeyen bir ikili program farklı kurallar alır.
• Kendi DoH'sini başlatan bir programı, sistemin yapılandırmadığı bir çözümleyiciye, bakmaya değer bir sinyal olarak değerlendirin.
• IP tabanlı engelleme listelerini uç noktada tutun; hala çalışıyorlar ve hiçbir maliyeti yok.

FireAI ve HisnLabs burada nereye oturuyor

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI, HisnLabs’in kendi ürünüdür: doğrudan Mac’inizde çalışan, yapay zekâ destekli bir güvenlik duvarı. Uygulamalarınızın kurduğu her bağlantıyı sade bir dille gösterir ve Mac’inizden neyin çıkacağına sizin karar vermenizi sağlar — yapay zekâsı yerel olarak çalışır, yani trafiğiniz asla bize ya da başka birine gönderilmez. HisnLabs güvenlik araştırma ekibi bu kararların isabetli kalmasını sağlayan ekiptir: hangi alan adlarının sıradan telemetri, hangilerinin gerçek bir hizmet olduğunu kataloglar, bir bağlantının ardındaki ülkeyi ve ağı izler ve cihaz üzerindeki modeli (Autopilot özelliği) gerçek trafik örüntüleriyle eğitir — üstelik bunların hiçbiri Mac’inizden dışarı çıkmadan.

Arkasındaki teknik kararları okuyabilir ya da FireAI’yi 17 gün boyunca deneyebilirsiniz: HisnLabs’ten FireAI.