सामान्य साक्षात्कार: आप एक Oblivious HTTP रिले और गेटवे को कैसे डिज़ाइन करेंगे?

प्रश्न और कार्यक्षेत्र

एक टेलीमेट्री क्लाइंट चाहता है कि टार्गेट सेवा अनुरोधों को क्लाइंट की पहचान से न जोड़ सके, जबकि अग्रेषण नोड (forwarding node) अनुरोध की सामग्री को न पढ़ सके। कुंजी खोज, HPKE एनकैप्सुलेशन, त्रुटि प्रबंधन, रीप्ले सुरक्षा, संसाधन मैपिंग, दर सीमा (rate limits) और मॉनिटरिंग को शामिल करते हुए OHTTP क्लाइंट, रिले, गेटवे और टार्गेट को डिज़ाइन करें।

RFC 9458 एन्क्रिप्टेड HTTP संदेशों को अग्रेषित करने का मानकीकरण करता है: रिले क्लाइंट कनेक्शन को देखता है, जबकि गेटवे डिक्रिप्ट करता है और टार्गेट को कॉल करता है, इसलिए दोनों में से कोई भी स्वतंत्र रूप से पहचान और सामग्री दोनों को नहीं जान सकता। OHTTP एक अनाम नेटवर्क नहीं है; संदेश की लंबाई, समय (timing), रिले/गेटवे की मिलीभगत (collusion), क्लाइंट मेटाडेटा और एप्लिकेशन पहचानकर्ताओं के लिए अभी भी अलग से समाधान की आवश्यकता होती है।

साक्षात्कारकर्ता क्या जांच रहा है

यह परिभाषित करना कि Client, Relay, Gateway और Target क्या देख सकते हैं और विश्वास (trust) की सीमा कहाँ समाप्त होती है।
गेटवे की सार्वजनिक कुंजी, HPKE अनुरोध/प्रतिक्रिया एनकैप्सुलेशन और मीडिया प्रकारों (media types) की व्याख्या करना।
रीप्ले सुरक्षा, अनुरोध-आकार सीमाएँ, टाइमआउट और त्रुटि मैपिंग डिज़ाइन करना।
एक-से-एक रिले/गेटवे संसाधन मैपिंग, ट्रैफ़िक विश्लेषण और मिलीभगत के जोखिम को संभालना।
कुंजी रोटेशन, कैशिंग, पुनः प्रयास (retries) और क्लाइंट क्लॉक स्क्यू को संभालना।
स्वीकृति, डिकैप्सुलेशन विफलता, रीप्ले अस्वीकृति, विलंबता (latency) और लंबाई-वितरण मेट्रिक्स के साथ सत्यापन करना।

पहले स्पष्ट करने योग्य प्रश्न

क्या यह एकतरफा टेलीमेट्री है, सार्वजनिक रीड है, या उच्च-मूल्य वाली राइट्स (writes) हैं? संवेदनशील राइट्स के लिए अधिक मजबूत प्रमाणीकरण और रीप्ले नियंत्रण की आवश्यकता होती है।
क्या रिले और गेटवे अलग-अलग पक्षों द्वारा संचालित किए जाते हैं, या एक ही संगठन दोनों का स्वामी हो सकता है?
क्या टार्गेट उपयोगकर्ता प्राधिकरण, किरायेदार (tenant), या क्षेत्र के आधार पर विभिन्न परिणाम देता है?
अनुरोध आकार, बैचिंग विंडो, विलंबता और हानि-सहनशीलता (loss-tolerance) की सीमाएं क्या हैं?
क्या क्लाइंट कुंजी समाप्त होने के बाद कॉन्फ़िगरेशन को पुनः खोज सकते हैं, और किन लॉग फ़ील्ड्स को संपादित (redact) किया जाना चाहिए?

30-सेकंड का उत्तर

मैं चार सीमाएँ बनाऊँगा: क्लाइंट रिले से जुड़ता है, रिले केवल एक एनकैप्सुलेटेड संदेश अग्रेषित करता है, और गेटवे टार्गेट को कॉल करने से पहले इसे डिक्रिप्ट करता है। क्लाइंट एक गेटवे कुंजी कॉन्फ़िगरेशन की खोज करता है और बाइनरी HTTP को एनकैप्सुलेट करने के लिए HPKE का उपयोग करता है; प्रतिक्रिया विपरीत दिशा में एनकैप्सुलेट की जाती है। गेटवे रीप्ले को अस्वीकार करने के लिए एक समय विंडो, अद्वितीय अनुरोध पहचानकर्ता, या एप्लिकेशन आइडेम्पोटेंसी का उपयोग करता है, जबकि रिले कनेक्शन और संदेश संसाधनों को सीमित करता है। ओवरलैप के साथ कुंजियों को घुमाएं (rotate) और डिकैप्सुलेशन विफलताओं, रीप्ले अस्वीकृति, विलंबता और लंबाई वितरण की निगरानी करें; OHTTP को मिलीभगत या ट्रैफ़िक विश्लेषण के विरुद्ध सुरक्षा के रूप में प्रस्तुत न करें।

चरण-दर-चरण गहन विश्लेषण

1. चार जिम्मेदारियों को परिभाषित करें

Client टार्गेट संसाधन और गेटवे सार्वजनिक कुंजी को जानता है। Relay क्लाइंट नेटवर्क कनेक्शन को जानता है लेकिन उसे एनकैप्सुलेटेड सामग्री को नहीं पढ़ना चाहिए। Gateway डिक्रिप्ट करता है और Target को सामान्य HTTP भेजता है, जो गेटवे को अपने स्रोत के रूप में देखता है। परिनियोजन (deployment), लॉग और एक्सेस अनुमतियों को अलग रखें ताकि कोई भी एक पक्ष पहचान और सामग्री को आसानी से सहसंबंधित न कर सके।

2. कुंजी कॉन्फ़िगरेशन खोजें और मान्य करें

क्लाइंट एक गेटवे कुंजी कॉन्फ़िगरेशन प्राप्त करता है जिसमें एक कुंजी पहचानकर्ता, HPKE एल्गोरिदम और एक सार्वजनिक कुंजी होती है। इसे एक प्रमाणित स्रोत, संस्करण और समाप्ति की आवश्यकता होती है; असमर्थित एल्गोरिदम और पुरानी कुंजियों को अस्वीकार करें। रोटेशन के दौरान पुरानी और नई कुंजियों को तब तक एक साथ प्रकाशित करें जब तक कि क्लाइंट कैश और अनुरोध विंडो समाप्त न हो जाएं।

3. अनुरोध और प्रतिक्रिया को एनकैप्सुलेट करें

क्लाइंट एक बाइनरी HTTP अनुरोध को एनकोड करता है और इसे HPKE के साथ message/ohttp-req पेलोड के रूप में एनकैप्सुलेट करता है। गेटवे डिकैप्सुलेट करता है और विधि (method), टार्गेट संसाधन, आकार और सामग्री प्रकार को मान्य करता है। यह प्रतिक्रिया को message/ohttp-res के रूप में एनकैप्सुलेट करता है। रिले को आंतरिक HTTP को पार्स नहीं करना चाहिए या प्लेनटेक्स्ट स्थिति के आधार पर रूट नहीं करना चाहिए।

text

Client -- TLS --> Relay -- opaque OHTTP --> Gateway -- HTTP --> Target
Client <-- opaque response -- Relay <-- OHTTP response -- Gateway

4. प्रमाणीकरण, रीप्ले और आइडेम्पोटेंसी को संभालें

OHTTP नेटवर्क पहचान छुपाता है; यह किसी व्यावसायिक उपयोगकर्ता को प्रमाणित नहीं करता है। राइट्स के लिए, एक एप्लिकेशन हस्ताक्षर, वन-टाइम नॉन्स (nonce), समय विंडो, या आइडेम्पोटेंसी कुंजी का उपयोग करें। गेटवे न्यूनतम रीप्ले-डिटेक्शन स्थिति रखता है और दोहराए गए एनकैप्सुलेटेड संदेशों को अस्वीकार करता है। टेलीमेट्री बैच आइडेम्पोटेंट इवेंट आईडी ले जा सकते हैं ताकि पुनः प्रयास करने पर दोहराव न हो।

5. त्रुटियों और संसाधन मैपिंग को संभालें

यदि डिकैप्सुलेशन विफल हो जाता है, तो गेटवे निजी कुंजी विवरण को उजागर किए बिना एक संरचित कुंजी या एनकैप्सुलेशन त्रुटि लौटाता है। टार्गेट व्यावसायिक त्रुटियां OHTTP प्रतिक्रिया के अंदर वापस आती हैं। रिले-टू-गेटवे संसाधन मैपिंग निश्चित और सत्यापन योग्य होनी चाहिए ताकि कोई संदेश गलत टार्गेट तक न पहुंचे। प्रत्येक परत पर टाइमआउट, आकार और ओवरलोड के लिए अलग सीमाएं लागू करें।

6. गोपनीयता रिसाव और ट्रैफ़िक विश्लेषण का मूल्यांकन करें

एन्क्रिप्शन रिले को क्लाइंट आईपी, समय और संदेश की लंबाई देखने से नहीं रोकता है, और न ही गेटवे को अनुरोध आवृत्ति और डिक्रिप्टेड एप्लिकेशन फ़ील्ड देखने से रोकता है। पैडिंग, बैचिंग, दर सीमाएं और अलग किए गए लॉग विलंबता और लागत की कीमत पर सहसंबंध को कम कर सकते हैं। यह दावा न करें कि OHTTP रिले/गेटवे की मिलीभगत को विफल करता है।

7. कैनरी, मॉनिटर और फ़ॉलबैक

एक छोटे क्लाइंट समूह और समर्पित रिले/गेटवे संसाधनों के साथ शुरुआत करें। कॉन्फ़िगरेशन हिट्स, डिकैप्सुलेशन सफलता, रीप्ले अस्वीकृति, टार्गेट 5xx, p95 विलंबता, संदेश-आकार बकेट और फ़ॉलबैक दर को ट्रैक करें। किसी घटना के दौरान टार्गेट या क्लाइंट संस्करण द्वारा OHTTP को सीमित रूप से अक्षम करें; सामान्य HTTPS फ़ॉलबैक के लिए गोपनीयता समीक्षा की आवश्यकता होती है। कॉन्फ़िगरेशन आईडी, त्रुटि वर्ग और अनुरोध हैश रखें, आंतरिक पहचान फ़ील्ड नहीं।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं क्लाइंट, रिले, गेटवे और टार्गेट को चार जिम्मेदारी डोमेन में अलग करूँगा। क्लाइंट गेटवे HPKE कुंजी कॉन्फ़िगरेशन प्राप्त और मान्य करता है, बाइनरी HTTP को एनकैप्सुलेट करता है, और इसे रिले को भेजता है। रिले अपारदर्शी बाइट्स (opaque bytes) को अग्रेषित करता है। गेटवे डिकैप्सुलेट करता है, आकार और संसाधन मैपिंग की जाँच करता है, और अपनी पहचान के साथ टार्गेट को कॉल करता है; प्रतिक्रिया वापसी के रास्ते में एनकैप्सुलेट की जाती है।

OHTTP व्यावसायिक प्रमाणीकरण प्रदान नहीं करता है या रिले/गेटवे मिलीभगत को परास्त नहीं करता है। इसलिए राइट्स के लिए एप्लिकेशन हस्ताक्षर, नॉन्स, या आइडेम्पोटेंसी कुंजियों की आवश्यकता होती है, जिसमें गेटवे टाइम-विंडो रीप्ले चेक शामिल है। ओवरलैप विंडो के साथ कुंजियों को घुमाएं और रिले कनेक्शन और संदेश संसाधनों को सीमित करें। डिकैप्सुलेशन विफलताओं, रीप्ले अस्वीकृति, विलंबता, आकार वितरण और व्यावसायिक त्रुटियों पर कैनरी तैनात करें; एक स्पष्ट गोपनीयता समीक्षा के बाद ही सामान्य HTTPS फ़ॉलबैक की अनुमति दें।

सामान्य गलतियाँ

रिले को डिक्रिप्टिंग प्रॉक्सी के रूप में मानना → गोपनीयता सीमा समाप्त हो जाती है → इसे केवल बाहरी कनेक्शन और अपारदर्शी संदेश को संभालने दें।
यह मान लेना कि OHTTP उपयोगकर्ताओं को प्रमाणित करता है → टार्गेट वैध व्यावसायिक प्रिंसिपल की पहचान नहीं कर सकता → एप्लिकेशन हस्ताक्षर या प्राधिकरण टोकन जोड़ें।
संदेश की लंबाई और समय की उपेक्षा करना → ट्रैफ़िक विश्लेषण अभी भी अनुरोधों को सहसंबंधित कर सकता है → विलंबता लागत को मापते हुए पैडिंग और बैचिंग का उपयोग करें।
आइडेम्पोटेंसी के बिना राइट्स का पुनः प्रयास करना → टेलीमेट्री की दोहरी गिनती होती है या दुष्प्रभाव दोहराए जाते हैं → नॉन्स, इवेंट आईडी और रीप्ले विंडो का उपयोग करें।
लिंक करने योग्य रिले और गेटवे लॉग साझा करना → एक पक्ष पहचान और सामग्री दोनों को पुनर्प्राप्त कर सकता है → ऑपरेटरों, फ़ील्ड्स और एक्सेस अनुमतियों को अलग करें।

अनुवर्ती प्रश्न और उत्तर

क्या OHTTP रिले और गेटवे की मिलीभगत को रोक सकता है?

नहीं। यह प्रोटोकॉल सीमित विश्वास और परिचालन अलगाव पर निर्भर करता है। मिलीभगत करने वाले पक्ष कनेक्शन पहचान को डिक्रिप्टेड सामग्री के साथ सहसंबंधित कर सकते हैं, इसलिए संगठनों, लॉग और एक्सेस नियंत्रणों को स्वतंत्र रहना चाहिए।

गेटवे रीप्ले को कैसे रोकता है?

राइट्स के लिए एक समय विंडो, नॉन्स, आइडेम्पोटेंट इवेंट आईडी, या एप्लिकेशन हस्ताक्षर का उपयोग करें; न्यूनतम पहचान स्थिति रखें और दोहराए गए एनकैप्सुलेटेड संदेशों को अस्वीकार करें। अकेले प्रत्येक कनेक्शन पर TLS क्रॉस-कनेक्शन रीप्ले को नहीं रोकता है।

संसाधन मैपिंग की आवश्यकता क्यों है?

एक रिले को एनकैप्सुलेटेड अनुरोध को इच्छित गेटवे/टार्गेट संसाधन पर अग्रेषित करना चाहिए। निश्चित मैपिंग कुंजी, नीति, दर-सीमा और ऑडिट सीमाओं को सत्यापन योग्य बनाती है और एक असंगत गेटवे को डिलीवरी से रोकती है।

आप गेटवे की सार्वजनिक कुंजी को कैसे घुमाते (rotate) हैं?

कैश, बैचिंग और पुनः प्रयास विंडो के माध्यम से पुरानी कुंजी को बनाए रखते हुए एक संस्करणित, समाप्त होने वाला नया कॉन्फ़िगरेशन प्रकाशित करें। कुंजी आईडी द्वारा हिट्स और डिकैप्सुलेशन विफलताओं का निरीक्षण करें, फिर पुरानी निजी कुंजी को सेवामुक्त करें।

क्या OHTTP उच्च-मूल्य वाली राइट्स के लिए उपयुक्त है?

केवल सावधानी के साथ। यह नेटवर्क पहचान छुपाता है लेकिन प्रमाणीकरण, प्राधिकरण, आइडेम्पोटेंसी या ऑडिट का स्थान नहीं लेता है। इसके विलंबता और गोपनीयता के संतुलन को स्वीकार करने से पहले एप्लिकेशन प्रिंसिपल और रीप्ले सीमा को साबित करें।

मॉनिटरिंग में क्या रिकॉर्ड किया जाना चाहिए?

कॉन्फ़िगरेशन आईडी, रिले/गेटवे संसाधन, त्रुटि वर्ग, अनुरोध-आकार बकेट, रीप्ले अस्वीकृति और एंड-टू-एंड विलंबता रिकॉर्ड करें। आंतरिक डोमेन, उपयोगकर्ता पहचानकर्ता, या रॉ एनकैप्सुलेटेड सामग्री को डिफ़ॉल्ट रूप से लॉग न करें।