बैकएंड इंटरव्यू: आप QUIC Extended Key Update को सुरक्षित रूप से कैसे रोल आउट करेंगे?

प्रॉम्प्ट और स्कोप

आपकी सर्विस में कई लंबे समय तक चलने वाले QUIC कनेक्शन हैं और इसे TLS Extended Key Update के फॉरवर्ड-सीक्रेसी (forward-secrecy) लाभों की आवश्यकता है। कैपेबिलिटी नेगोशिएशन, की (key) ट्रांज़िशन, पुराने क्लाइंट और पैकेट लॉस हैंडलिंग, और एक सुरक्षित कैनरी तथा रोलबैक योजना की व्याख्या करें।

IETF QUIC वर्किंग ग्रुप ड्राफ्ट TLS Extended Key Update पर आधारित है ताकि लंबे समय तक चलने वाले कनेक्शन बिना पूर्ण हैंडशेक के कीज़ (keys) को रीफ्रेश कर सकें। दोनों साथियों (peers) को TLS flags एक्सटेंशन का समर्थन करना चाहिए और हैंडशेक के दौरान Extended_Key_Update सेट करना चाहिए; नेगोशिएशन के बाद, सेशन को विस्तारित प्रक्रिया का उपयोग करना चाहिए और इसे मानक QUIC Key Update के साथ मिश्रित नहीं करना चाहिए। चूंकि यह कार्य अभी प्रगति पर है (work in progress), इसलिए प्रोडक्शन में एक कार्यान्वयन संस्करण (implementation version) और इंटरऑपरेबिलिटी परिणामों को पिन किया जाना चाहिए।

इंटरव्यूअर क्या मूल्यांकन करता है

इंटरव्यूअर चाहता है कि हैंडशेक, Key Phase और पैकेट-नंबर स्टेट मशीन को RFC 9001 से स्पष्ट सीमा के साथ एक ही सिस्टम के रूप में समझाया जाए। द्विदिशी (bidirectional) स्थिति, लॉस और रीऑर्डरिंग, पुराने क्लाइंट्स, माइग्रेशन, की (key) रिटायरमेंट, रोलआउट मेट्रिक्स और रोलबैक सीमाओं को कवर करें। एक अच्छा उत्तर Internet-Draft को एक स्थिर RFC के रूप में प्रस्तुत नहीं करता है।

उत्तर देने से पहले स्पष्टीकरण प्रश्न

प्रत्येक छोर पर कौन से QUIC/TLS कार्यान्वयन और संस्करण चल रहे हैं, और क्या दोनों को अपग्रेड किया जा सकता है?
कनेक्शन कितने समय तक चलते हैं, और क्या अपडेट समय, बाइट्स या सुरक्षा घटनाओं पर ट्रिगर होने चाहिए?
क्या माइग्रेशन, 0-RTT, प्रॉक्सी या मिडिलबॉक्स स्कोप में हैं?
क्या किसी पुराने क्लाइंट को मानक Key Update पर रहना चाहिए या लंबे समय तक चलने वाले कनेक्शन से वंचित किया जाना चाहिए?
क्या रोलबैक हैंडशेक से पहले, नेगोशिएशन के बाद, या कनेक्शन द्वारा कीज़ बदलने के बाद होता है?

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

“मैं इसे कैपेबिलिटी नेगोशिएशन और प्रति-कनेक्शन स्टेट मशीन के रूप में देखूँगा। इसे केवल तभी सक्षम करें जब दोनों साथी TLS flags और Extended_Key_Update का विज्ञापन करें; अन्यथा RFC 9001 पाथ बनाए रखें। एक बार सक्षम होने के बाद, कोई सेशन दोनों अपडेट प्रक्रियाओं को मिश्रित नहीं कर सकता। प्रत्येक दिशा की (key) फेज, पैकेट नंबर और एक सीमित पुराने पैकेट विंडो को ट्रैक करती है। लॉस और रीऑर्डरिंग प्रोटोकॉल के डिक्रिप्शन और पुष्टिकरण लॉजिक का उपयोग करते हैं; पुरानी कीज़ एक सुरक्षा विंडो के बाद रिटायर हो जाती हैं। क्लाइंट संस्करण, क्षेत्र या कनेक्शन अनुपात के आधार पर कैनरी करें, डिक्रिप्शन विफलताओं, अपडेट लेटेंसी, रिट्रांसमिशन, क्लोज़ और CPU की निगरानी करें, और केवल नए हैंडशेक को रोल बैक करें जबकि नेगोशिएट किए गए कनेक्शन अपनी मौजूदा स्थिति को पूरा करते हैं।”

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

1. नेगोशिएशन गेट को परिभाषित करें

Extended Key Update कोई एकतरफा स्विच नहीं है। दोनों साथियों को TLS flags एक्सटेंशन का समर्थन करना चाहिए और हैंडशेक के दौरान Extended_Key_Update सेट करना चाहिए। सर्वर परिणाम को प्रति कनेक्शन स्टोर करता है, न कि वैश्विक मोड के रूप में। पारस्परिक क्षमता के बिना, मानक QUIC Key Update का उपयोग करें और कभी भी कोई अस्पष्टीकृत Key Phase न भेजें।

2. सेंड और रिसीव स्थिति को मॉडल करें

प्रत्येक दिशा के लिए वर्तमान की (key), अगली की, Key Phase, अधिकतम पुरानी पैकेट विंडो और अपडेट काउंटर को ट्रैक करें। सेंडर अपडेट के बाद फेज बदलता है; रिसीवर वर्तमान या अगली कीज़ आज़माता है और सफल डिक्रिप्शन और पैकेट-नंबर जांच के बाद ही आगे बढ़ता है। ट्रांज़िशन आइडेम्पोटेंट होने चाहिए: डुप्लिकेट ट्रिगर किसी फेज को छोड़ नहीं सकते हैं या अभी भी उपयोग में आने वाली की को मिटा नहीं सकते हैं।

3. लॉस, रीऑर्डरिंग और पुष्टिकरण को संभालें

एक अपडेट सिग्नल पुराने-की पैकेट से पहले या उसके बाद आ सकता है। सीमित पुरानी और अगली-की उम्मीदवारों को बनाए रखें और पैकेट-नंबर तथा पुष्टिकरण नियमों का पालन करें; कीज़ को कभी भी अनिश्चित काल तक न रखें। डिक्रिप्ट विफलताओं को फेज बेमेल, प्रमाणीकरण विफलता, या प्रोटोकॉल त्रुटि के रूप में वर्गीकृत करें। रीऑर्डरिंग को हमले के रूप में मानने से बचें, लेकिन कई की (key) उम्मीदवारों को CPU कार्य बढ़ाने की अनुमति देने से भी बचें।

text

handshake flags -> negotiated?
       no -> RFC 9001 key update
       yes -> extended update state
                   -> packet decrypt -> confirm -> retire old key

4. ट्रिगर्स और सुरक्षा विंडो चुनें

ट्रिगर्स कनेक्शन की अवधि, भेजे गए बाइट्स, की-उपयोग गणना, या सुरक्षा घटना का उपयोग कर सकते हैं, जिसे कंजेशन, CPU और एप्लिकेशन लेटेंसी के विरुद्ध संतुलित किया जाता है। स्विच करने से पहले नई की सामग्री तैयार करें, पर्याप्त पुष्टिकरण की प्रतीक्षा करें, और फिर पुरानी की को रिटायर करें। लॉग में केवल फेज, गणना और परिणाम होते हैं, कभी भी की सामग्री, TLS सीक्रेट्स या पुनर्प्राप्त करने योग्य क्रेडेंशियल्स नहीं होते।

5. पुराने क्लाइंट्स और माइग्रेशन का समर्थन करें

पुराने क्लाइंट मानक पाथ पर बने रहते हैं; सर्वर का समर्थन प्रत्येक गैर-नेगोशिएटेड कनेक्शन को अस्वीकार करने का औचित्य नहीं देता है। माइग्रेशन नेगोशिएशन को रीसेट नहीं करता है, लेकिन एक नया नेटवर्क पाथ रीऑर्डरिंग और लॉस को बढ़ा सकता है, इसलिए स्टेट मशीन का पुन: उपयोग करें और विंडो का फिर से निरीक्षण करें। किसी प्रॉक्सी या मिडिलबॉक्स को किसी अनधिकृत की स्थिति को समाप्त और फिर से बनाना नहीं चाहिए।

6. कैनरी, मेट्रिक्स और रोलबैक डिज़ाइन करें

क्लाइंट संस्करण, क्षेत्र या कनेक्शन अनुपात द्वारा कैनरी करें। नेगोशिएशन सफलता, डिक्रिप्ट विफलताएं, Key Phase असहमति, अपडेट लेटेंसी, रिट्रांसमिशन, क्लोज़ और CPU रिकॉर्ड करें। विसंगतियों पर, नए हैंडशेक पर क्षमता का विज्ञापन करना बंद करें जबकि नेगोशिएट किए गए कनेक्शन अपनी मूल स्थिति को पूरा करते हैं; किसी विस्तारित कनेक्शन को वापस मानक Key Update पर जाने के लिए बाध्य न करें। संस्करणों को पिन करें, इंटरऑपरेबिलिटी परीक्षण चलाएं, और रिलीज़ गेट्स के रूप में सैनिटाइज़ किए गए ट्रेस का उपयोग करें।

7. इंटरऑपरेबिलिटी और की (key) लाइफसाइकिल का परीक्षण करें

दोनों साथियों, एकतरफा समर्थन, बार-बार अपडेट, अपडेट के दौरान रीऑर्डरिंग, लॉस, माइग्रेशन, लंबी निष्क्रिय अवधि और क्लोज़ का परीक्षण करें। सत्यापित करें कि पुरानी कीज़ विंडो के बाद डिक्रिप्ट नहीं कर सकती हैं और मेमोरी, क्रैश डंप और डिबग इंटरफेस उन्हें उजागर नहीं करते हैं। ड्राफ्ट संस्करण, कार्यान्वयन कमिट, वेक्टर्स और विफलताओं को संग्रहीत करें ताकि बाद का ड्राफ्ट परिवर्तन प्रतिलिपि प्रस्तुत करने योग्य (reproducible) बना रहे।

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

मैं सबसे पहले कार्यान्वयन संस्करणों की पहचान करूँगा, फिर एक्सटेंशन को हैंडशेक क्षमता और एक द्विदिशी कनेक्शन स्टेट मशीन के रूप में मॉडल करूँगा। इसे केवल तभी सक्षम करें जब दोनों साथी TLS flags का समर्थन करते हैं और Extended_Key_Update सेट करते हैं; अन्यथा RFC 9001 पाथ बनाए रखें। एक नेगोशिएटेड सेशन एक ही अपडेट प्रक्रिया का उपयोग करता है, जिसमें प्रति दिशा वर्तमान और अगली कीज़, Key Phase, पैकेट नंबर और एक सीमित पुराने पैकेट विंडो होती है। लॉस और रीऑर्डरिंग सीमित उम्मीदवारों को आज़माते हैं और प्रमाणित पुष्टिकरण के बाद ही आगे बढ़ते हैं, फिर पुरानी की को रिटायर करते हैं। ट्रिगर्स आयु, बाइट्स या सुरक्षा घटनाओं का उपयोग करते हैं, और लॉग में केवल फेज और परिणाम होते हैं। नेगोशिएशन, डिक्रिप्ट विफलताएं, रिट्रांसमिशन, क्लोज़ और CPU पर नज़र रखते हुए क्लाइंट संस्करण, क्षेत्र और कनेक्शन अनुपात के आधार पर रोल आउट करें। रोलबैक नए हैंडशेक पर क्षमता को रोकता है; मौजूदा नेगोशिएटेड सेशन अपनी स्थिति को पूरा करते हैं। इंटरऑपरेबिलिटी, लंबे कनेक्शन, माइग्रेशन, लॉस और की-इरेज़र परीक्षण कार्यान्वयन को पिन करते हैं क्योंकि ड्राफ्ट अभी भी बदल सकता है।

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

एक तरफ एक्सटेंशन को सक्षम करना और एक नया Key Phase भेजना → साथी इसकी व्याख्या नहीं कर सकता → हैंडशेक में पारस्परिक नेगोशिएशन की आवश्यकता रखें।
एक सेशन में दोनों अपडेट प्रक्रियाओं को मिश्रित करना → Key Phase सेमेंटिक्स परस्पर विरोधी होते हैं → नेगोशिएशन के बाद एक स्टेट मशीन तय करें।
लॉस के बाद पुरानी कीज़ को हमेशा के लिए बनाए रखना → मेमोरी और अटैक सरफेस बढ़ते हैं → एक सीमित विंडो और पुष्टिकरण का उपयोग करें।
प्रत्येक डिक्रिप्ट विफलता को हमला मानना → रीऑर्डरिंग को गलत तरीके से रिपोर्ट किया जाता है → फेज, प्रमाणीकरण और प्रोटोकॉल त्रुटियों को अलग करें।
रोलबैक के दौरान मौजूदा कनेक्शनों को जबरन वापस धकेलना → स्थिति दूषित हो जाती है → नए नेगोशिएशन को रोकें और नेगोशिएटेड सेशन्स को सुरक्षित रखें।
TLS सीक्रेट्स को लॉग करना → कीज़ लीक हो सकती हैं → केवल फेज, गणना, लेटेंसी और परिणाम लॉग करें।

फॉलो-अप प्रश्न और उत्तर

केवल संस्करण संख्या से ही समर्थन का अनुमान क्यों न लगाया जाए?

संस्करण केवल संभावित समर्थन का सुझाव देता है। प्रोटोकॉल को हैंडशेक में स्पष्ट फ्लैग की आवश्यकता होती है, और कंपाइल विकल्प तथा कॉन्फ़िगरेशन वास्तविक क्षमता को प्रभावित करते हैं। नेगोशिएटेड परिणाम का उपयोग करें।

क्या होगा यदि अपडेट के दौरान एक पुराना-Key-Phase पैकेट आता है?

एक सीमित पुरानी-की उम्मीदवार विंडो रखें, पैकेट-नंबर और प्रमाणीकरण जांच करें, और स्थिति के अनुसार इसे प्रोसेस करें। अनिश्चित काल तक प्रयास करने के बजाय विंडो के बाहर के पैकेटों को अस्वीकार करें और गिनें।

क्या किसी निष्क्रिय (idle) कनेक्शन को कीज़ अपडेट करनी चाहिए?

निर्णय को की (key) के उपयोग और जोखिम पर आधारित करें। बेकार नियंत्रण ट्रैफ़िक से बचने के लिए निष्क्रिय रहते हुए अगले सेंड की प्रतीक्षा करें, लेकिन दोबारा भेजने से पहले की (key) की स्थिति और समाप्ति की जांच करें।

आप कैसे साबित करते हैं कि पुरानी कीज़ मिटा दी गई थीं?

नियंत्रित परीक्षणों में, जीवनचक्र की घटनाओं को रिकॉर्ड करें और अपरिवर्तनीय परीक्षण-की मार्करों के साथ मेमोरी, क्रैश डंप और डिबग इंटरफेस का निरीक्षण करें। प्रोडक्शन लॉग में कभी भी सीक्रेट सामग्री प्रिंट न करें।

आप ड्राफ्ट की समाप्ति या संशोधन का प्रबंधन कैसे करते हैं?

ड्राफ्ट संस्करण और कार्यान्वयन कमिट को पिन करें, एक इंटरऑपरेबिलिटी मैट्रिक्स बनाए रखें, और परिवर्तनों की समीक्षा करें। एक अलग क्षमता सिग्नल के पीछे एक नए संस्करण को कैनरी करें; कभी यह न मानें कि प्रगति पर चल रहा (work-in-progress) व्यवहार स्थिर है।