FastCGI: reverse proxy के लिए 30 साल बाद भी अब भी बेहतर प्रोटोकॉल

 (agwa.name)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • लंबे समय तक चलने वाले backend को socket के जरिए request भेजने वाले proxy protocol के रूप में, इसे मौजूदा HTTP handler संरचना को लगभग बिना बदले लागू किया जा सकता है
  • HTTP/1.1 reverse proxy में message boundary की व्याख्या implementation के अनुसार आसानी से अलग हो सकती है, जिससे desync और request smuggling जैसी गंभीर सुरक्षा समस्याएँ बार-बार पैदा हो सकती हैं
  • FastCGI 1996 से स्पष्ट message framing देता आया है, और client headers तथा proxy द्वारा जोड़ी गई trusted information को संरचनात्मक रूप से अलग करता है
  • Go का net/http/fcgi REMOTE_ADDR को Request.RemoteAddr में भरता है और HTTPS की स्थिति को Request.TLS में भी दर्शाता है, इसलिए trusted information forwarding अलग middleware के बिना संभाला जा सकता है
  • WebSockets का समर्थन न होना, कमजोर tooling ecosystem, और कुछ workloads में कम throughput जैसी सीमाएँ हैं, लेकिन अगर WebSockets की जरूरत नहीं है और performance पर्याप्त है, तो यह अब भी एक व्यावहारिक विकल्प लगता है

FastCGI की स्थिति और लागू करने का तरीका

  • FastCGI सिर्फ file-per-process execution मॉडल के लिए ही नहीं, बल्कि long-running daemon को TCP या UNIX socket के जरिए request भेजने वाले proxy-backend protocol के रूप में भी इस्तेमाल किया जा सकता है
  • Go में net/http/fcgi package import करके http.Serve को fcgi.Serve से बदलने भर से इसे लागू किया जा सकता है
    • मौजूदा handlers पहले की तरह http.ResponseWriter और http.Request का ही उपयोग करते हैं
    • application की बाकी संरचना भी जस की तस रहती है
  • Apache, Caddy, nginx, HAProxy जैसे प्रमुख proxy FastCGI backend को support करते हैं और configuration भी अपेक्षाकृत सरल है

Backend protocol के रूप में HTTP इस्तेमाल करने पर parsing समस्याएँ

  • HTTP reverse proxying लगभग सुरक्षा की बारूदी सुरंगों वाला क्षेत्र है, और Discord media proxy की desync vulnerability जैसी समस्याएँ, जिनसे निजी attachments देखे जा सकते हैं, लगातार सामने आती रहती हैं
  • HTTP/1.1 ऊपर से देखने पर सरल text protocol लगता है, लेकिन एक ही message को व्यक्त करने के बहुत अधिक तरीके और कई exception cases होने के कारण implementation के बीच उसकी व्याख्या आसानी से अलग हो सकती है
  • सबसे बड़ी समस्या यह है कि HTTP messages में स्पष्ट framing नहीं होती
    • message का अंत message खुद कई तरीकों से बताता है
    • अलग implementations message के खत्म होने और अगले message के शुरू होने के बिंदु को अलग तरह से समझ सकती हैं
  • ऐसी असंगतियाँ HTTP desync attacks या request smuggling की बुनियाद बनती हैं, जहाँ reverse proxy और backend message boundaries को अलग तरह से समझते हैं और गंभीर सुरक्षा समस्याएँ पैदा होती हैं
  • parser differences को लगातार patch करते रहना मूल समाधान बनना मुश्किल है
    • James Kettle लगातार नए प्रकार खोजते रहे हैं
    • पिछले साल अतिरिक्त मामलों को खोजने के बाद उन्होंने "HTTP/1.1 must die" तक कहा

FastCGI और HTTP/2 में message boundary handling

  • HTTP/2 अगर proxy और backend के बीच लगातार एकसमान तरीके से इस्तेमाल किया जाए, तो message boundaries को स्पष्ट करके desync समस्या हल कर सकता है
  • FastCGI 1996 से ही इससे भी सरल protocol के साथ ऐसी स्पष्ट boundary separation देता आया है
  • nginx ने अपनी पहली release से FastCGI backend को support किया, लेकिन HTTP/2 backend support 2025 के उत्तरार्ध में ही जोड़ा गया
  • Apache में HTTP/2 backend support अब भी "experimental" स्थिति में है

Untrusted headers की समस्या और FastCGI की separation approach

  • समस्या सिर्फ desync तक सीमित नहीं है; HTTP में वास्तविक client IP, proxy द्वारा प्रोसेस किया गया authenticated username, या mTLS में client certificate जैसी जानकारी, जिसे proxy को भरोसे के साथ आगे भेजना होता है, उसे मजबूती से ले जाने का तरीका भी कमजोर है
  • व्यवहार में ऐसी जानकारी HTTP headers में डाल दी जाती है, लेकिन proxy द्वारा जोड़ा गया trusted data और client द्वारा भेजे गए untrusted headers के बीच कोई संरचनात्मक विभाजन नहीं होता
  • X-Real-IP जैसे headers अक्सर वास्तविक client IP भेजने के लिए उपयोग किए जाते हैं, लेकिन इसे सुरक्षित बनाने के लिए proxy को case variation सहित पहले से मौजूद सभी ऐसे headers पूरी तरह हटाकर फिर दोबारा जोड़ने होते हैं
  • यह तरीका बेहद खतरनाक इलाका है, और backend के हमलावर द्वारा डाले गए data पर भरोसा कर लेने के कई रास्ते बनते हैं
  • proxy को सिर्फ X-Real-IP ही नहीं, बल्कि इस उद्देश्य के लिए इस्तेमाल होने वाले हर header को हटाना पड़ता है
  • उदाहरण के लिए, Chi middleware client के वास्तविक IP का निर्धारण करते समय पहले True-Client-IP को देखता है, और उसके न होने पर ही X-Real-IP का उपयोग करता है
    • proxy अगर X-Real-IP को सही तरह संभाले तब भी, हमलावर True-Client-IP भेजकर समस्या पैदा कर सकता है
  • FastCGI client headers और proxy द्वारा जोड़ी गई जानकारी को domain separation के जरिए अलग करता है
    • दोनों ही key/value parameters की सूची के रूप में भेजे जाते हैं, लेकिन HTTP header names पर HTTP_ prefix लगाया जाता है
    • इसलिए client द्वारा भेजे गए headers का proxy के trusted data के रूप में व्याख्यायित होना संरचनात्मक रूप से संभव नहीं होता

Go में FastCGI trusted information handling

  • FastCGI वास्तविक client IP भेजने के लिए REMOTE_ADDR जैसे standard parameters परिभाषित करता है
  • Go का net/http/fcgi इस value को अपने आप http.Request के RemoteAddr में भर देता है, इसलिए अलग middleware के बिना यह काम करता है
  • proxy HTTPS उपयोग, negotiated TLS cipher suite, और client certificate जैसी जानकारी non-standard parameters के रूप में भी भेज सकता है
  • Go में अगर request ने HTTPS का उपयोग किया हो, तो Request का TLS field अपने आप nil के अलावा किसी value पर set हो जाता है
    • भले ही वह खाली हो, HTTPS enforced है या नहीं यह जाँचने में यह उपयोगी है
  • fcgi.ProcessEnv से proxy द्वारा भेजे गए trusted parameters के पूरे सेट तक पहुँचा जा सकता है

अपनाने में धीमापन और व्यावहारिक सीमाएँ

  • अगर FastCGI बेहतर है, तो फिर यह व्यापक रूप से क्यों नहीं अपनाया गया — इसका एक कारण शायद नाम का पुराना लगना और HTTP reverse proxy सुरक्षा समस्याओं के प्रति जागरूकता की कमी, दोनों का साथ होना है
  • Watchfire ने 2005 में ही desync attacks पर चर्चा की थी और यह चेतावनी भी दी थी कि इन्हें हल करना आसान नहीं होगा, लेकिन ऐसे attacks को 10 साल से अधिक समय तक गंभीर ध्यान नहीं मिला
  • FastCGI आज भी वास्तविक उपयोग के लिए उपयुक्त है, और SSLMate में इसका 10 साल से अधिक समय से production में उपयोग हो रहा है
  • फिर भी, यह पुरानी तकनीक है, इसलिए इसकी कुछ कमजोरियाँ हैं
    • WebSockets support के लिए इसे अपडेट नहीं किया गया
    • tooling ecosystem कमजोर है
    • उदाहरण के लिए, curl FTP, Gopher, SMTP तक support करता है, लेकिन FastCGI requests नहीं भेज सकता
  • कई reverse proxy के पीछे Go FastCGI server को benchmark करने पर, कुछ workloads में HTTP/1.1 या HTTP/2 से कम throughput मिला
    • इसे protocol की मूल सीमा मानने के बजाय, FastCGI code path के HTTP जितना optimize न होने का परिणाम माना गया है

अंतिम निष्कर्ष

  • अगर WebSockets की जरूरत नहीं है और मौजूदा performance पर्याप्त है, तो FastCGI अब भी एक उपयोगी विकल्प है
  • भले ही bottleneck आ जाए, HTTP reverse proxying की complexity और security nightmare झेलने के बजाय अतिरिक्त hardware जोड़ना बेहतर विकल्प माना गया है

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.