Mitmproxy 11: Dukungan HTTP/3 Penuh

 (mitmproxy.org)
3 poin oleh GN⁺ 2024-10-06 | 1 komentar | Bagikan ke WhatsApp
  • Seiring meningkatnya porsi trafik QUIC dan HTTP/3, mitmproxy 11 mengaktifkan HTTP/3 secara default untuk memperluas cakupan analisis trafik web modern
  • HTTP/3 dapat digunakan tidak hanya pada proxy transparan dan proxy balik, tetapi juga pada WireGuard dan local mode, sehingga bisa diterapkan di berbagai lingkungan penangkapan trafik
  • Chrome tidak mempercayai Certificate Authority yang ditambahkan pengguna pada QUIC, sehingga harus memilih salah satu dari sertifikat tepercaya publik, switch baris perintah, atau fallback ke HTTP/2
  • Implementasi DNS kini beralih ke basis Hickory DNS, menangani kueri selain A/AAAA, HTTPS records, DNS-over-TCP, kontrol file hosts, dan penghapusan kunci ECH
  • Fitur privasi seperti ECH membuat alur pembuatan sertifikat pada proxy man-in-the-middle menjadi lebih sulit, tetapi mitmproxy tetap mempertahankan kemungkinan berfungsi dengan menyesuaikan respons DNS

Cakupan dukungan HTTP/3

  • mitmproxy 11 mendukung HTTP/3 dalam mode proxy transparan dan proxy balik
  • Pada proxy balik, satu instance mitmproxy menerima paket TCP dan UDP sekaligus, lalu memproses versi HTTP yang diteruskan
  • HTTP/3 juga dapat digunakan di WireGuard dan local mode
    • Contoh perintah: 
      mitmproxy --mode wireguard
mitmproxy --mode local
  • Pengujian dilakukan dengan Firefox, Chrome, berbagai build cURL, dan klien lain untuk mengurangi masalah kompatibilitas
  • Pekerjaan dukungan HTTP/3 dimulai pada 2022 oleh Manuel Meitinger dan Maximilian Hils, lalu diaktifkan secara default di mitmproxy 11

Batasan sertifikat QUIC di Chrome

  • Batasan utama yang saat ini diketahui adalah Chrome tidak mempercayai Certificate Authority yang ditambahkan pengguna pada QUIC
  • Untuk menangani trafik HTTP/3 di Chrome, diperlukan salah satu dari berikut
    • Menyediakan sertifikat yang dipercaya secara publik seperti Let’s Encrypt
    • Menjalankan Chrome dengan switch baris perintah terkait
    • Menerima perilaku fallback ke HTTP/2
  • Firefox tidak menunjukkan perilaku seperti ini
  • Tips pemecahan masalah HTTP/3 dapat dilihat di #7025

Implementasi ulang berbasis Hickory DNS

  • Dengan munculnya fitur privasi seperti DNS HTTPS records dan Encrypted Client Hello(ECH), pemrosesan DNS di mitmproxy menjadi semakin penting
  • Implementasi DNS sebelumnya memiliki keterbatasan karena menggunakan getaddrinfo
    • Hanya mendukung kueri A/AAAA untuk alamat IPv4 dan IPv6
    • Tidak dapat merespons kueri seperti HTTPS records yang memberi tahu dukungan HTTP/3
  • mitmproxy 11 mengimplementasikan ulang dukungan DNS di atas Hickory DNS, pustaka DNS berbasis Rust
  • Melalui Hickory, mitmproxy memperoleh nameserver bawaan sistem operasi di Windows, Linux, dan macOS, lalu meneruskan kueri non-A/AAAA ke nameserver tersebut
  • Opsi baru dns_name_servers memungkinkan penentuan nameserver tujuan 
    mitmdump --mode dns --set dns_name_servers=8.8.8.8

Kontrol file hosts dan DNS-over-TCP

  • Bersamaan dengan peralihan ke Hickory, ditambahkan opsi untuk mengabaikan file hosts sistem
  • Opsi baru dns_use_hosts_file memungkinkan pengaturan apakah file hosts seperti /etc/hosts di Linux akan digunakan atau tidak
  • Resolusi DNS internal mitmproxy juga direncanakan dipindahkan ke Hickory, dan setelah itu fitur ini akan berguna saat melakukan pengalihan transparan domain tertentu pada mesin yang sama
    • Saat ini, karena file hosts selalu dipertimbangkan, mitmproxy dapat terhubung secara rekursif ke dirinya sendiri dalam konfigurasi pengalihan pada mesin yang sama
  • Contoh perilaku: 
    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 pada dasarnya menggunakan UDP, tetapi TCP mungkin diperlukan saat menangani record yang tidak muat dalam satu paket UDP
  • Karena mitmproxy 11 mendukung tipe kueri arbitrer, pentingnya ukuran pesan dan penanganan TCP meningkat, dan DNS-over-TCP juga berfungsi

Penghapusan kunci ECH dan pembuatan sertifikat

  • mitmproxy menggunakan Server Name Indication(SNI) pada TLS ClientHello untuk menyusun sertifikat yang valid saat tidak ada sertifikat khusus pengguna
  • Jika tidak ada SNI, mungkin tidak bisa dibuat sertifikat yang akan dipercaya klien
  • Encrypted Client Hello(ECH) adalah mekanisme di mana klien memperoleh kunci ECH melalui DNS HTTPS records, lalu mengenkripsi pesan handshake ClientHello awal dengan kunci tersebut
  • Jika kueri DNS dan handshake sama-sama terenkripsi, perantara pasif tidak dapat mengetahui domain tujuan dan hanya bisa melihat alamat IP tujuan
    • Pada shared hosting dan Content Delivery Networks, sulit memastikan domain tujuan hanya dari alamat IP
  • Peningkatan privasi ini bertabrakan dengan cara mitmproxy membuat sertifikat
  • mitmproxy 11 menghapus kunci ECH dari HTTPS records untuk memperoleh informasi domain yang diperlukan dalam pembuatan sertifikat
    • Klien tidak dapat memperoleh kunci untuk mengenkripsi pesan handshake awal
    • mitmproxy dapat mengetahui domain tujuan dan menyusun sertifikat yang cocok
  • ECH dapat membuat penggunaan mitmproxy menjadi lebih sulit, tetapi ini juga bisa dilihat sebagai perubahan yang meningkatkan privasi web secara keseluruhan

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-06
Komentar Hacker News

  • Senang melihat Mitmproxy ternyata masih dikembangkan. Alat ini secara tidak langsung membentuk karier saya
    Pada 2011, saat belajar pengembangan API dengan mencegat request aplikasi mobile, saya menemukan bahwa API Airbnb terekspos kerentanan mass assignment Rails (https://github.com/rails/rails/issues/5228). Setelah mencoba mengubah beberapa atribut yang tidak berbahaya, saya menghubungi perusahaan itu; hal tersebut berujung pada wawancara, dan sisanya benar-benar menjadi sejarah

    • Jumlah developer inti di issue itu yang menentang perubahan benar-benar tidak masuk akal
    • Sampai sekarang ini masih sangat berguna bagi saya, tetapi ternyata cukup banyak orang yang semestinya tahu justru tidak begitu mengenal Mitmproxy
      Kadang lebih mudah memasang mitmproxy ke implementasi yang sudah ada daripada membaca dokumentasinya

  • Menarik bahwa Chrome tidak memercayai certificate authority yang ditambahkan pengguna di QUIC
    Di issue terkait, tim Chrome mengatakan: “Kami secara eksplisit tidak mengizinkan sertifikat yang tidak dipercaya secara publik untuk mencegah deployment software/hardware penyadapan QUIC. Jika tidak, dalam jangka panjang hal itu akan merusak kemampuan protokol QUIC untuk berevolusi. Untuk penggunaan yang bergantung pada sertifikat yang bukan sertifikat public trust, gunakan TLS+TCP alih-alih QUIC”
    Saya tidak mengikuti evolusi protokolnya, tetapi saya kurang paham bagaimana pemblokiran sertifikat kustom terkait dengan kemampuan berevolusi. Penasaran apakah ada yang tahu alasannya

    • Dugaan saya, karena Google mengendalikan klien sekaligus endpoint server besar (Google Search, Youtube, dll.), mereka ingin bebas melakukan eksperimen perubahan QUIC
      Mereka bisa memasukkan versi QUIC yang sedikit dimodifikasi ke Chrome, mendukungnya di tempat seperti Youtube, lalu memakai metriknya untuk mengusulkan perubahan standar “sebenarnya” atau terus menjalankan versi khusus hanya di layanan mereka sendiri
      Jika sertifikat kustom diizinkan, perusahaan yang memeriksa traffic karyawan dengan cara man-in-the-middle memakai sesuatu seperti ZScaler ZIA berisiko rusak ketika protokol berubah. Jika data stream sepenuhnya terenkripsi dan tidak transparan bagi perangkat perantara, Google pada dasarnya bisa melakukan hampir apa pun yang mereka mau
      Konsep terkait: https://en.wikipedia.org/wiki/Protocol_ossification
    • Perangkat perantara(https://en.m.wikipedia.org/wiki/Middlebox) adalah penyebab stagnasi protokol yang sudah dikenal
      Protokol yang dapat diperluas biasanya hanya perlu meng-upgrade klien dan server, tetapi jika ada perangkat perantara, secara potensial N perangkat juga harus ikut diperbarui. Pengguna dan penyedia layanan punya motivasi untuk mengadopsi fitur baru, tetapi pemilik perangkat perantara belum tentu. Akibatnya, protokol menjadi sulit berevolusi
    • Ini mungkin merujuk pada kasus terkenal ketika lembaga keuangan menentang TLS 1.3. Motivasinya adalah mereka tidak ingin memperbarui software man-in-the-middle yang diperlukan untuk kepatuhan regulasi: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA/
    • Salah satu alasan dibuatnya HTTP 2 dan 3 juga karena mengubah HTTP 1.1 terlalu sulit
      Ada banyak middleware yang sangat bergantung pada detail implementasi, sehingga sedikit perubahan saja mudah merusak pengalaman pengguna tanpa disengaja. Sepertinya mereka ingin menghindari situasi serupa di versi baru
    • QUIC ada untuk meningkatkan tingkat pengiriman iklan, jadi memberi kebebasan kepada pengguna bertentangan dengan tujuan itu

  • Saya penasaran apakah HTTP/2 atau HTTP/3 tetap memberi manfaat jika hanya didukung di reverse proxy dan tidak di web server sebenarnya
    Sebagian besar framework arus utama di JS/Python/Ruby tidak mendukung standar HTTP baru. Kalau begitu, bukankah web server akan menjadi bottleneck pada koneksi reverse proxy?

    • Ada. HTTP/2 atau HTTP/3 meningkatkan keandalan koneksi antara klien dan reverse proxy
      Koneksi antara reverse proxy dan web server sebenarnya biasanya jauh lebih cepat dan stabil, sehingga manfaat menaikkan segmen itu ke HTTP/2 atau HTTP/3 jauh lebih kecil
    • Transport antara reverse proxy dan backend juga tidak selalu HTTP. Misalnya Python kadang memakai uWSGI, PHP memakai FastCGI
      Bahkan ketika memakai HTTP, reverse proxy bisa membuat koneksi ke backend jauh lebih cepat daripada ke klien jarak jauh sebenarnya. Jadi memakai stream HTTP/2 pada segmen yang lambat tetap menguntungkan
    • Mungkin tidak terlalu relevan, tetapi mitmproxy bukan reverse proxy untuk lingkungan produksi
      Ini adalah alat yang dijalankan di mesin lokal untuk pengujian terkait protokol level rendah atau keamanan web
    • Ada satu hal yang terlewat. Browser web membatasi jumlah koneksi per domain menjadi 6
      Pada HTTP/2 ke atas, beberapa request simultan ditangani melalui satu koneksi
    • Ada. Selain manfaat performa lain, HTTP/3 menggabungkan handshake TCP dan TLS sehingga mengurangi satu round trip saat koneksi dibuat

  • Masih ada masalah fingerprinting. Sampai bisa meniru handshake TLS browser umum, di sekitar 80% web Anda akan melihat halaman seperti “Just a quick check...” atau “Sorry, it looks like you're a bot”
    https://github.com/mitmproxy/mitmproxy/issues/4575

    • Kalau begitu, sepertinya Firefox bukan lagi browser umum

  • Terima kasih sudah menyebut Hickory. Selalu menarik melihat apa yang orang bangun dengannya, dan itu pekerjaan yang dibuat dengan baik

    • Terima kasih atas pekerjaan pada Hickory. Berkat interoperabilitas Python↔Rust dari PyO3, sangat menarik bahwa library DNS kelas produksi seperti Hickory dan stack networking userspace yang solid seperti smoltcp bisa dipakai dari Python
      Hal-hal seperti ini semula akan sulit didapat hanya dengan Python

  • Saya penasaran apakah Mitmproxy bisa dipakai seperti Privoxy/Proxomitron/Yarip
    Misalnya, saat browsing dengan Ungoogled Chromium, bisakah saya menjadikan Mitmproxy sebagai proxy lalu menghapus tag script dari situs tertentu? Bagaimana dampaknya terhadap performa?

    • Secara teori bisa. Dalam praktiknya, karena mitmproxy ditulis dengan Python, akan ada latensi karena bahasanya tidak terlalu cepat
      Saat melihat halaman web, penundaan kecil yang menumpuk ratusan kali bisa terasa
      Meski begitu, bagi orang yang tertarik dengan penggunaan seperti ini, ini bisa menjadi opsi. Secara teknis tidak ada yang menghalangi
      Ada risiko kecil mengganggu pemeriksaan subresource integrity ketika menulis ulang file JavaScript, tetapi jika benar-benar bermasalah, sepertinya hash-nya juga bisa ditulis ulang untuk mengatasinya

  • Apakah mitmproxy bisa menjadi alternatif Fiddler?

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