Mitmproxy 11: पूर्ण HTTP/3 सपोर्ट

 (mitmproxy.org)
3 पॉइंट द्वारा GN⁺ 2024-10-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • QUIC और HTTP/3 ट्रैफ़िक का हिस्सा बढ़ने के साथ mitmproxy 11 में HTTP/3 डिफ़ॉल्ट रूप से enabled है, जिससे आधुनिक वेब ट्रैफ़िक के विश्लेषण का दायरा बढ़ता है
  • transparent proxy और reverse proxy के साथ-साथ WireGuard और local mode में भी HTTP/3 काम करता है, इसलिए इसे अलग-अलग capture environments में इस्तेमाल किया जा सकता है
  • Chrome, QUIC में यूज़र द्वारा जोड़ी गई Certificate Authority पर भरोसा नहीं करता, इसलिए public trusted certificate, command-line switch, या HTTP/2 fallback में से एक चुनना पड़ता है
  • DNS implementation अब Hickory DNS पर आधारित है और A/AAAA के अलावा queries, HTTPS records, DNS-over-TCP, hosts file control, और ECH key removal को संभालती है
  • ECH जैसी privacy features man-in-the-middle proxy के certificate generation flow को कठिन बनाती हैं, लेकिन mitmproxy DNS responses को adjust करके काम करने की क्षमता बनाए रखता है

HTTP/3 सपोर्ट का दायरा

  • mitmproxy 11, HTTP/3 को transparent proxy और reverse proxy mode में सपोर्ट करता है
  • reverse proxy में एक mitmproxy instance TCP और UDP packets दोनों receive करता है और आगे भेजे जाने वाले HTTP version को संभालता है
  • WireGuard और local mode में भी HTTP/3 इस्तेमाल किया जा सकता है
    • उदाहरण कमांड: 
      mitmproxy --mode wireguard
mitmproxy --mode local
  • Firefox, Chrome, कई cURL builds और अन्य clients के साथ test करके compatibility issues कम किए गए हैं
  • HTTP/3 support पर काम 2022 में Manuel Meitinger और Maximilian Hils ने शुरू किया था, और mitmproxy 11 में यह डिफ़ॉल्ट रूप से enabled है

Chrome में QUIC certificate constraints

  • इस समय ज्ञात मुख्य limitation यह है कि Chrome, QUIC में यूज़र द्वारा जोड़ी गई Certificate Authority पर भरोसा नहीं करता
  • Chrome में HTTP/3 ट्रैफ़िक संभालने के लिए इनमें से एक ज़रूरी है
    • Let’s Encrypt जैसे publicly trusted certificate उपलब्ध कराना
    • Chrome को संबंधित command-line switches के साथ चलाना
    • HTTP/2 में fallback होने वाले behavior को स्वीकार करना
  • Firefox ऐसा behavior नहीं दिखाता
  • HTTP/3 troubleshooting tips #7025 में देखे जा सकते हैं

Hickory DNS आधारित पुनर्निर्माण

  • DNS HTTPS records और Encrypted Client Hello(ECH) जैसी privacy features के आने से mitmproxy में DNS handling का महत्व बढ़ गया है
  • पुरानी DNS implementation getaddrinfo का उपयोग करती थी, इसलिए उसकी सीमाएँ थीं
    • यह केवल IPv4 और IPv6 addresses के लिए A/AAAA queries सपोर्ट करती थी
    • यह HTTP/3 support की सूचना देने वाले HTTPS records जैसी queries का जवाब नहीं दे सकती थी
  • mitmproxy 11, DNS support को Rust-आधारित DNS library Hickory DNS के ऊपर फिर से implement करता है
  • Hickory के जरिए Windows, Linux, और macOS पर operating system के default nameservers प्राप्त किए जाते हैं, और A/AAAA के अलावा queries को उन nameservers पर forward किया जाता है
  • नया dns_name_servers option forward किए जाने वाले nameservers को निर्धारित कर सकता है 
    mitmdump --mode dns --set dns_name_servers=8.8.8.8

hosts file control और DNS-over-TCP

  • Hickory पर switch के साथ system hosts file को ignore करने का option जोड़ा गया है
  • नया dns_use_hosts_file option इस्तेमाल करके Linux के /etc/hosts जैसी hosts files को लागू करना है या नहीं, इसे नियंत्रित किया जा सकता है
  • mitmproxy की internal DNS resolution को भी Hickory पर ले जाने की योजना है, और उसके बाद एक ही machine पर किसी specific domain को transparent redirect करते समय यह feature उपयोगी होगा
    • अभी hosts file को हमेशा consider किया जाता है, इसलिए same-machine redirect setup में mitmproxy recursive रूप से खुद से connect हो सकता है
  • उदाहरण behavior: 
    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 डिफ़ॉल्ट रूप से UDP का उपयोग करता है, लेकिन ऐसे records को संभालने के लिए TCP की ज़रूरत पड़ सकती है जो एक single UDP packet में फिट नहीं होते
  • mitmproxy 11, arbitrary query types को सपोर्ट करते हुए message size और TCP handling के महत्व को बढ़ाता है, और DNS-over-TCP भी काम करता है

ECH key removal और certificate generation

  • mitmproxy, custom certificate न होने पर TLS ClientHello के Server Name Indication(SNI) का उपयोग करके वैध certificate बनाता है
  • अगर SNI न हो, तो ऐसा certificate बनाना संभव नहीं हो सकता जिस पर client भरोसा करे
  • Encrypted Client Hello(ECH) एक तरीका है जिसमें client, DNS HTTPS records से ECH key लेने के बाद शुरुआती ClientHello handshake message को उसी key से encrypt करता है
  • अगर DNS query और handshake दोनों encrypted हों, तो passive man-in-the-middle target domain नहीं जान सकता और केवल target IP address देख सकता है
    • shared hosting और Content Delivery Networks में सिर्फ IP address से target domain तय करना मुश्किल होता है
  • यह privacy improvement, mitmproxy के certificate generation तरीके से टकराती है
  • mitmproxy 11, HTTPS records से ECH key को हटाकर certificate generation के लिए ज़रूरी domain information हासिल करता है
    • client को शुरुआती handshake message को encrypt करने के लिए key नहीं मिलती
    • mitmproxy target domain को पहचान सकता है और उससे मेल खाता certificate बना सकता है
  • ECH, mitmproxy का उपयोग अधिक कठिन बना सकता है, लेकिन इसे पूरे वेब की privacy बढ़ाने वाले बदलाव के रूप में भी देखा जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-06
Hacker News की राय

  • अच्छा लगा कि Mitmproxy अभी भी विकसित हो रहा है। इस टूल ने अप्रत्यक्ष रूप से मेरा करियर बना दिया
    2011 में मोबाइल ऐप requests intercept करते हुए API development सीख रहा था, तभी पाया कि Airbnb API Rails mass assignment vulnerability (https://github.com/rails/rails/issues/5228) के लिए exposed था। कुछ harmless attributes बदलकर देखने के बाद कंपनी से संपर्क किया, और उससे interview मिला; उसके बाद की कहानी तो इतिहास है

    • उस issue में core developers में से कितने लोग बदलाव के खिलाफ थे, यह सचमुच अजीब हद तक ज्यादा था
    • आज भी मेरे लिए बहुत उपयोगी है, लेकिन हैरानी की बात है कि जानकार लोगों में भी कई Mitmproxy को ठीक से नहीं जानते
      कभी-कभी docs पढ़ने से ज्यादा आसान होता है कि मौजूदा implementation के साथ mitmproxy जोड़कर देखा जाए

  • यह हिस्सा दिलचस्प है कि Chrome QUIC में user-added certificate authorities पर भरोसा नहीं करता
    linked issue में Chrome team कहती है, “QUIC interception software/hardware की deployment रोकने के लिए हम publicly untrusted certificates को स्पष्ट रूप से allow नहीं करते। वरना long term में QUIC protocol के evolve होने की संभावना को नुकसान पहुंचेगा। जिन use cases में publicly trusted certificates के अलावा certificates पर निर्भरता है, वे QUIC की जगह TLS+TCP इस्तेमाल कर सकते हैं”
    मैं protocol evolution को follow नहीं करता, लेकिन custom certificates को रोकना evolvability से कैसे जुड़ता है, यह समझ नहीं आ रहा। किसी को वजह पता है?

    • मेरा अनुमान है कि Google client और बड़े server endpoints (Google Search, Youtube आदि) दोनों को control करता है, इसलिए वह QUIC बदलावों पर experiments करने की आजादी चाहता है
      Chrome में थोड़ा modified QUIC version डालकर Youtube जैसी जगहों पर support कर सकता है, फिर metrics के आधार पर “real” standard change propose कर सकता है या अपनी services में ही special version चलाता रह सकता है
      custom certificates allow करने पर ZScaler ZIA जैसी चीजों से employee traffic को middleman तरीके से inspect करने वाली companies के protocol changes पर टूटने का जोखिम होगा। अगर data stream पूरी तरह encrypted होकर middle equipment के लिए opaque है, तो Google लगभग जो चाहे कर सकता है
      संबंधित concept: https://en.wikipedia.org/wiki/Protocol_ossification
    • Middleboxes(https://en.m.wikipedia.org/wiki/Middlebox) protocol ossification का जाना-माना कारण हैं
      extensible protocols में आम तौर पर सिर्फ client और server को upgrade करना होता है, लेकिन middleboxes हों तो संभावित रूप से N devices को भी साथ में update करना पड़ता है। users और service providers के पास नई features adopt करने की motivation होती है, लेकिन middlebox owners के पास शायद न हो। नतीजा यह कि protocol evolve करना कठिन हो जाता है
    • यह उस famous case की ओर भी इशारा हो सकता है जहां financial institutions ने TLS 1.3 का विरोध किया था। motivation यह थी कि वे compliance के लिए जरूरी middleman software update नहीं करना चाहते थे: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA/
    • HTTP 2 और 3 बनाने की एक वजह यह भी थी कि HTTP 1.1 में बदलाव करना बहुत मुश्किल था
      बहुत सा middleware implementation details पर मजबूती से निर्भर था, इसलिए कुछ छोटा बदलने पर अनजाने में user experience टूटना आसान था। नए version में शायद ऐसी स्थिति से बचने की कोशिश है
    • QUIC ad delivery rate बढ़ाने के लिए मौजूद है, इसलिए users को freedom देना उस goal से टकराता है

  • सोच रहा हूं कि HTTP/2 या HTTP/3 अगर सिर्फ reverse proxy में supported हों और actual web server में न हों, तब भी फायदा है क्या
    JS/Python/Ruby के ज्यादातर mainstream frameworks नए HTTP standards support नहीं करते। तो क्या web server reverse proxy connection का bottleneck नहीं बन जाएगा?

    • फायदा है। HTTP/2 या HTTP/3 client और reverse proxy के बीच connection की reliability बढ़ाते हैं
      reverse proxy और actual web server के बीच connection आम तौर पर काफी तेज और stable होता है, इसलिए उस हिस्से को HTTP/2 या HTTP/3 पर ले जाने से मिलने वाला फायदा बहुत कम होता है
    • reverse proxy और backend के बीच transport हमेशा HTTP ही हो, ऐसा भी नहीं है। उदाहरण के लिए Python uWSGI और PHP FastCGI इस्तेमाल कर सकता है
      HTTP इस्तेमाल होने पर भी, reverse proxy actual remote client की तुलना में backend से कहीं तेजी से connection बना सकता है। इसलिए slow segment में HTTP/2 streams इस्तेमाल करना अब भी फायदेमंद है
    • शायद इसका ज्यादा मतलब नहीं, लेकिन mitmproxy production environment के लिए reverse proxy नहीं है
      यह local machine पर चलाकर low-level protocol या web security से जुड़े tests करने का tool है
    • एक बात छूट गई है। web browsers प्रति domain connections की संख्या 6 तक limit करते हैं
      HTTP/2 और उससे ऊपर में कई concurrent requests को एक ही connection पर handle किया जाता है
    • फायदा है। दूसरे performance benefits भी हैं, लेकिन HTTP/3 TCP और TLS handshakes को combine करके connection के समय एक round trip कम कर देता है

  • अभी भी fingerprinting की समस्या बची है। जब तक यह typical browser के TLS handshake की नकल नहीं कर पाता, web के लगभग 80% हिस्से पर “Just a quick check...” या “Sorry, it looks like you're a bot” जैसे pages दिखेंगे
    https://github.com/mitmproxy/mitmproxy/issues/4575

    • तो लगता है Firefox अब typical browser नहीं रहा

  • Hickory का जिक्र करने के लिए धन्यवाद। लोग उससे क्या बना रहे हैं, यह देखना हमेशा मजेदार होता है, और काम अच्छी तरह किया गया है

    • Hickory पर किए काम के लिए धन्यवाद। PyO3 की Python↔Rust interoperability की वजह से Hickory जैसी production-grade DNS library और smoltcp जैसे solid user-space networking stack को Python से इस्तेमाल कर पाना वाकई दिलचस्प है
      ये चीजें शायद सिर्फ Python से पाना मुश्किल होता

  • सोच रहा हूं कि Mitmproxy को Privoxy/Proxomitron/Yarip की तरह इस्तेमाल किया जा सकता है क्या
    उदाहरण के लिए Ungoogled Chromium में browsing करते समय Mitmproxy को proxy बनाकर, किसी खास site के script tags हटाए जा सकते हैं? performance पर क्या असर होगा?

    • theory में संभव है। practice में mitmproxy Python में लिखा है, इसलिए language बहुत तेज न होने के कारण latency आएगी
      web page देखते समय छोटी latency सैकड़ों बार जुड़कर महसूस हो सकती है
      फिर भी इस तरह के use case में रुचि रखने वालों के लिए यह एक option हो सकता है। technically कोई रोक नहीं है
      JavaScript files rewrite करते समय subresource integrity checks से छेड़छाड़ होने का छोटा risk है, लेकिन अगर सच में issue आया तो hashes भी rewrite करके शायद हल किया जा सकता है

  • क्या mitmproxy Fiddler का alternative हो सकता है?

    • लगभग हां। mitmproxy में मुझे जो बात पसंद है, वह यह कि requests और responses को intercept या modify करने वाले Python plugins इस्तेमाल करना आसान है
      https://docs.mitmproxy.org/stable/addons-overview/

  • हम्म: https://github.com/mitmproxy/mitmproxy/issues/4170