Mitmproxy 11: Tam HTTP/3 desteği

 (mitmproxy.org)
3 puan yazan GN⁺ 2024-10-06 | 1 yorum | WhatsApp'ta paylaş
  • QUIC ve HTTP/3 trafiğinin payı büyürken, mitmproxy 11 HTTP/3’ü varsayılan olarak etkinleştirerek modern web trafiği analizinin kapsamını genişletiyor
  • HTTP/3, yalnızca şeffaf proxy ve reverse proxy’de değil, WireGuard ve local mode içinde de çalışıyor; bu da farklı yakalama ortamlarında kullanılabilmesini sağlıyor
  • Chrome, QUIC üzerinde kullanıcının eklediği Certificate Authority’lere güvenmediği için, herkese açık güvenilir bir sertifika, komut satırı anahtarı ya da HTTP/2’ye geri dönüş seçeneklerinden biri gerekiyor
  • DNS uygulaması Hickory DNS tabanına taşınıyor; A/AAAA dışı sorgular, HTTPS records, DNS-over-TCP, hosts dosyası kontrolü ve ECH anahtarlarının kaldırılması ele alınıyor
  • ECH gibi gizlilik özellikleri, ortadaki adam proxy’sinin sertifika üretim akışını zorlaştırsa da mitmproxy, DNS yanıtlarını ayarlayarak çalışabilirliğini koruyor

HTTP/3 destek kapsamı

  • mitmproxy 11, HTTP/3’ü şeffaf proxy ve reverse proxy modlarında destekliyor
  • Reverse proxy’de tek bir mitmproxy örneği hem TCP hem UDP paketlerini alıyor ve iletilen HTTP sürümünü işliyor
  • WireGuard ve local mode içinde de HTTP/3 kullanılabiliyor
    • Örnek komut: 
      mitmproxy --mode wireguard
mitmproxy --mode local
  • Uyumluluk sorunlarını azaltmak için Firefox, Chrome, çeşitli cURL derlemeleri ve diğer istemcilerle test edildi
  • HTTP/3 desteği çalışması 2022’de Manuel Meitinger ve Maximilian Hils tarafından başlatıldı ve mitmproxy 11’de varsayılan olarak etkinleştirildi

Chrome’un QUIC sertifika kısıtı

  • Şu anda bilinen başlıca kısıt, Chrome’un QUIC üzerinde kullanıcının eklediği Certificate Authority’lere güvenmemesi
  • Chrome’da HTTP/3 trafiğini işlemek için aşağıdakilerden biri gerekiyor
    • Let’s Encrypt gibi herkese açık şekilde güvenilen bir sertifika sağlamak
    • Chrome’u ilgili komut satırı anahtarları ile çalıştırmak
    • HTTP/2’ye geri dönüş davranışını kabul etmek
  • Firefox böyle bir davranış göstermiyor
  • HTTP/3 sorun giderme ipuçlarına #7025 üzerinden ulaşılabilir

Hickory DNS tabanlı yeniden uygulama

  • DNS HTTPS records ve Encrypted Client Hello(ECH) gibi gizlilik özellikleri ortaya çıktıkça, mitmproxy’nin DNS işleme katmanının önemi arttı
  • Mevcut DNS uygulaması getaddrinfo kullandığı için sınırlamalara sahipti
    • Yalnızca IPv4 ve IPv6 adresleri için A/AAAA sorgularını destekliyordu
    • HTTP/3 desteğini bildiren HTTPS records gibi sorgulara yanıt veremiyordu
  • mitmproxy 11, DNS desteğini Rust tabanlı DNS kütüphanesi Hickory DNS üzerinde yeniden uyguluyor
  • Hickory sayesinde Windows, Linux ve macOS’ta işletim sisteminin varsayılan ad sunucuları alınabiliyor ve A/AAAA dışındaki sorgular bu ad sunucularına iletiliyor
  • Yeni dns_name_servers seçeneği ile iletilecek ad sunucuları belirtilebiliyor 
    mitmdump --mode dns --set dns_name_servers=8.8.8.8

hosts dosyası kontrolü ve DNS-over-TCP

  • Hickory geçişiyle birlikte sistem hosts dosyasını yok sayma seçeneği eklendi
  • Yeni dns_use_hosts_file seçeneği ile Linux’ta /etc/hosts gibi hosts dosyalarının dikkate alınıp alınmayacağı kontrol edilebiliyor
  • mitmproxy’nin dahili DNS çözümlemesinin de Hickory’ye taşınması planlanıyor; sonrasında bu özellik, aynı makinede belirli alan adlarını şeffaf biçimde yeniden yönlendirirken faydalı olacak
    • Şu anda hosts dosyası her zaman dikkate alındığı için, aynı makinedeki yeniden yönlendirme kurulumlarında mitmproxy kendi kendine özyineli bağlantı kurabilir
  • Örnek davranış: 
    echo "192.0.2.1 mitmproxy.org" >> /etc/hosts
mitmdump --mode dns
dig @127.0.0.1 +short mitmproxy.org
192.0.2.1
mitmdump --mode dns --set dns_use_hosts_file=false
dig @127.0.0.1 +short mitmproxy.org
3.161.82.13
  • DNS varsayılan olarak UDP kullanır, ancak tek bir UDP paketine sığmayan kayıtları işlerken TCP gerekebilir
  • mitmproxy 11, rastgele sorgu tiplerini destekledikçe mesaj boyutu ve TCP işlemenin önemi arttı; DNS-over-TCP de çalışıyor

ECH anahtarlarının kaldırılması ve sertifika üretimi

  • mitmproxy, özel bir sertifika olmadığında geçerli bir sertifika oluşturmak için TLS ClientHello içindeki Server Name Indication(SNI) bilgisini kullanıyor
  • SNI yoksa istemcinin güveneceği bir sertifika üretilemeyebilir
  • Encrypted Client Hello(ECH), istemcinin DNS HTTPS records üzerinden ECH anahtarlarını aldıktan sonra ilk ClientHello el sıkışma mesajını bu anahtarlarla şifrelemesi yöntemidir
  • DNS sorgusu ve el sıkışma birlikte şifrelenirse, pasif olmayan bir ortadaki adam hedef alan adını bilemez ve yalnızca hedef IP adresini görebilir
    • Paylaşımlı barındırma ve Content Delivery Network ortamlarında yalnızca IP adresinden hedef alan adını kesin olarak belirlemek zordur
  • Bu gizlilik iyileştirmesi, mitmproxy’nin sertifika üretim yöntemiyle çakışıyor
  • mitmproxy 11, sertifika üretimi için gerekli alan adı bilgisini elde etmek amacıyla HTTPS records içinden ECH anahtarlarını kaldırıyor
    • İstemci, ilk el sıkışma mesajını şifrelemek için gereken anahtarları elde edemiyor
    • mitmproxy, hedef alan adını tespit edip buna uygun bir sertifika oluşturabiliyor
  • ECH, mitmproxy kullanımını daha zor hale getirebilir; ancak web genelinde gizliliği artıran bir değişim olarak görülebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-06
Hacker News görüşleri

  • Mitmproxy'nin hâlâ geliştiriliyor olduğunu görmek sevindirici. Bu araç dolaylı olarak kariyerimi şekillendirdi
    2011'de mobil uygulama isteklerini yakalayıp API geliştirmeyi öğrenirken, Airbnb API'sinin Rails toplu atama açığına (https://github.com/rails/rails/issues/5228) maruz kaldığını fark ettim. Zararsız birkaç niteliği değiştirdikten sonra şirkete ulaştım; bu bir mülakata dönüştü ve sonrası kelimenin tam anlamıyla tarih oldu

    • O konuda çekirdek geliştiricilerin değişikliğe karşı çıkma düzeyi gerçekten akıl almazdı
    • Hâlâ benim için çok faydalı ama konuyu bilen insanların bile şaşırtıcı şekilde Mitmproxy'yi tanımadığı oluyor
      Bazen mevcut bir uygulamaya mitmproxy bağlamak, dokümantasyonu okumaktan daha kolay oluyor

  • Chrome'un QUIC için kullanıcı tarafından eklenen sertifika otoritelerine güvenmemesi ilginç
    Bağlantılı issue'da Chrome ekibi, “QUIC'i yakalayan yazılım/donanımın dağıtımını önlemek için herkese açık olarak güvenilmeyen sertifikaları açıkça izinli saymıyoruz. Aksi halde bu, uzun vadede QUIC protokolünün evrim geçirebilme yeteneğine zarar verir. Herkese açık güven zincirine sahip olmayan sertifikalara dayanan kullanım senaryoları QUIC yerine TLS+TCP kullanabilir” diyor
    Protokol evrimini çok yakından takip etmiyorum ama özel sertifikaları engellemenin evrim geçirilebilirlik ile nasıl bağlantılı olduğunu pek anlamadım. Bunun nedenini bilen var mı merak ediyorum

    • Tahminimce Google, hem istemciyi hem de büyük sunucu uç noktalarını (Google Search, Youtube vb.) kontrol ettiği için QUIC değişikliklerini denemekte özgür olmak istiyor
      Chrome'a hafif değiştirilmiş bir QUIC sürümü koyup bunu Youtube gibi yerlerde destekleyebilir, sonra da elde ettiği metriklerle “gerçek” standart değişikliklerini önerebilir ya da yalnızca kendi servislerinde özel sürümü çalıştırmaya devam edebilir
      Özel sertifikalara izin verilirse, ZScaler ZIA gibi çözümlerle çalışan trafiğini ortadaki adam yöntemiyle inceleyen şirketler protokol değiştiğinde bozulma riski taşır. Veri akışı tamamen şifreli olup ara cihazlara kapalıysa Google neredeyse istediğini yapabilir
      İlgili kavram: https://en.wikipedia.org/wiki/Protocol_ossification
    • Ara cihazlar (https://en.m.wikipedia.org/wiki/Middlebox) protokol katılaşmasının bilinen bir nedenidir
      Genişletilebilir protokollerde normalde yalnızca istemci ve sunucunun güncellenmesi yeterlidir; ama ara cihazlar varsa potansiyel olarak N tane cihazın da birlikte güncellenmesi gerekir. Kullanıcılar ve servis sağlayıcılar yeni özellikleri benimsemek için motive olabilir ama ara cihaz sahipleri olmayabilir. Sonuç olarak protokolün evrim geçirmesi zorlaşır
    • Belki de finans kurumlarının TLS 1.3'e karşı çıktığı meşhur olaya atıf yapılıyor. Motivasyon, uyumluluk için gereken ortadaki adam yazılımını güncellemek istememeleriydi: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA/
    • HTTP 1.1'i değiştirmenin çok zor olması, HTTP 2 ve 3'ün yapılma nedenlerinden biriydi
      Uygulama ayrıntılarına sıkı sıkıya bağlı çok sayıda middleware vardı; bu yüzden küçük bir şeyi bile değiştirmek istemeden kullanıcı deneyimini bozabiliyordu. Görünüşe göre yeni sürümlerde benzer bir durumdan kaçınmak istiyorlar
    • QUIC, reklam teslim oranını artırmak için var; bu yüzden kullanıcıya özgürlük vermek bu hedefle çelişiyor

  • HTTP/2 ya da HTTP/3 yalnızca ters proxy üzerinde desteklenip gerçek web sunucusunda desteklenmese bile fayda sağlar mı diye merak ediyorum
    JS/Python/Ruby dünyasındaki ana akım framework'lerin çoğu yeni HTTP standartlarını desteklemiyor. O zaman web sunucusu, ters proxy bağlantısında darboğaz olmaz mı?

    • Evet. HTTP/2 ya da HTTP/3, istemci ile ters proxy arasındaki bağlantının güvenilirliğini artırır
      Ters proxy ile gerçek web sunucusu arasındaki bağlantı genelde çok daha hızlı ve kararlıdır; bu yüzden o kısmı HTTP/2 ya da HTTP/3'e yükseltmenin getirisi çok daha küçüktür
    • Ters proxy ile backend arasındaki aktarım her zaman HTTP de değildir. Örneğin Python uWSGI, PHP ise FastCGI kullanabilir
      HTTP kullanıldığında bile ters proxy, backend'e gerçek uzak istemciden çok daha hızlı bağlanabilir. Bu yüzden yavaş kısımda HTTP/2 akışlarını kullanmak yine de avantajlıdır
    • Muhtemelen çok da önemli değil ama mitmproxy üretim ortamı için bir ters proxy değildir
      Yerel makinede çalıştırılan, düşük seviye protokoller veya web güvenliğiyle ilgili testler yapmak için kullanılan bir araçtır
    • Eksik kalan bir nokta var. Web tarayıcıları alan adı başına bağlantı sayısını 6 ile sınırlar
      HTTP/2 ve sonrasında birden çok eşzamanlı istek tek bir bağlantı üzerinden işlenir
    • Evet. Başka performans faydaları da var ama HTTP/3, TCP ve TLS el sıkışmalarını birleştirerek bağlantı kurulurken bir RTT kazandırır

  • Hâlâ parmak izi sorunu var. Genel bir tarayıcının TLS el sıkışmasını taklit edebilene kadar, web'in yaklaşık %80'inde “Just a quick check...” ya da “Sorry, it looks like you're a bot” gibi sayfalar göreceksiniz
    https://github.com/mitmproxy/mitmproxy/issues/4575

    • O zaman Firefox artık genel bir tarayıcı sayılmıyor demek ki

  • Hickory'den bahsettikleri için teşekkürler. İnsanların onunla neler yaptığını görmek her zaman eğlenceli ve iyi iş çıkarmışlar

    • Hickory üzerindeki emek için teşekkürler. PyO3'ün Python↔Rust birlikte çalışabilirliği sayesinde Hickory gibi üretim düzeyinde DNS kütüphanelerini ve smoltcp gibi sağlam kullanıcı alanı ağ yığınlarını Python'dan kullanabilmek gerçekten çok ilginç
      Bunları yalnızca Python ile elde etmek normalde zor olurdu

  • Mitmproxy'nin Privoxy/Proxomitron/Yarip gibi kullanılıp kullanılamayacağını merak ediyorum
    Örneğin Ungoogled Chromium ile gezinirken Mitmproxy'yi proxy olarak kullanıp belirli sitelerdeki script etiketlerini kaldırabilir miyim? Performansa etkisi ne olur?

    • Teorik olarak mümkün. Pratikte mitmproxy Python ile yazıldığı için, dil çok hızlı olmadığından biraz gecikme ekler
      Bir web sayfasını görüntülerken küçük gecikmeler yüzlerce kez birikirse hissedilebilir hâle gelebilir
      Yine de bu kullanım senaryosuyla ilgilenenler için bir seçenek olabilir. Teknik olarak engelleyen bir şey yok
      JavaScript dosyalarını yeniden yazarken alt kaynak bütünlüğü denetimlerini bozma riski küçük de olsa var; ama gerçekten sorun olursa hash'i de yeniden yazarak çözülebilir gibi görünüyor

  • mitmproxy, Fiddler'a alternatif olabilir mi?

  • Hm: https://github.com/mitmproxy/mitmproxy/issues/4170