प्रॉम्प्ट और संदर्भ
आप एक लंबे समय तक चलने वाले प्रशासनिक कनेक्शन का संचालन करते हैं। अधिकांश अनुरोधों को क्लाइंट-प्रमाणपत्र कार्य से बचना चाहिए, लेकिन उच्च-जोखिम वाले परिचालनों को क्लाइंट की पहचान करनी चाहिए। TLS 1.3 पोस्ट-हैंडशेक क्लाइंट प्रमाणीकरण डिज़ाइन करें और प्रारंभिक हैंडशेक के दौरान म्यूचुअल TLS की तुलना में इसकी सीमा की व्याख्या करें।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
उत्तर में पोस्ट-हैंडशेक प्रमाणीकरण को एक वैकल्पिक TLS 1.3 संदेश प्रवाह के रूप में माना जाना चाहिए, न कि दूसरे TLS कनेक्शन के रूप में। इसमें क्लाइंट द्वारा अपने प्रारंभिक ClientHello में post_handshake_auth क्षमता का विज्ञापन करना, सर्वर द्वारा बाद में CertificateRequest भेजना, क्लाइंट द्वारा अपनी प्रमाणपत्र श्रृंखला और CertificateVerify वापस करना, विफलता से निपटना और परिणाम को HTTP/2, HTTP/3, या किसी एप्लिकेशन अनुरोध से जोड़ना शामिल होना चाहिए।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
प्रमाणीकरण का दायरा
पूछें कि क्या प्रमाणीकरण प्रति कनेक्शन एक बार है, प्रति उच्च-जोखिम अनुरोध एक बार है, या किरायेदार (tenant) पर निर्भर है। इसे बहुत लंबे समय तक कैश करने से निरसन विंडो (revocation window) बढ़ जाती है; इसे बहुत बार अनुरोध करने से प्रमाणपत्र-सत्यापन लागत और प्रोटोकॉल संदेश बढ़ जाते हैं।
प्रोटोकॉल और कार्यान्वयन सीमा
पुष्टि करें कि कनेक्शन HTTP/1.1, HTTP/2, HTTP/3, या कोई कस्टम प्रोटोकॉल ले जाता है, और क्या TLS लाइब्रेरी पोस्ट-हैंडशेक API को उजागर करती है। प्रमाणीकरण पूरा होने तक एप्लिकेशन को संरक्षित परिचालनों को ब्लॉक करना चाहिए।
विफलता और निरसन नीति
परिभाषित करें कि क्या समाप्त हो चुका प्रमाणपत्र, अज्ञात CA, अमान्य हस्ताक्षर, या असमर्थित क्षमता किसी एक अनुरोध को अस्वीकार करती है, कनेक्शन बंद करती है, या कम विशेषाधिकार वाला सत्र छोड़ती है। OCSP, अल्पकालिक प्रमाणपत्र, या निरसन-सूची स्रोत की पहचान करें।
30-सेकंड उत्तर ढांचा
"TLS 1.3 पोस्ट-हैंडशेक प्रमाणीकरण के लिए क्लाइंट को अपने प्रारंभिक ClientHello में post_handshake_auth का विज्ञापन करने की आवश्यकता होती है। सर्वर बाद में CertificateRequest भेजता है; क्लाइंट Certificate, CertificateVerify और Finished लौटाता है। सर्वर बाद के अनुरोधों से पहचान को जोड़ने से पहले श्रृंखला, उपयोग, हस्ताक्षर और निरसन स्थिति को मान्य करता है। यदि क्षमता पर बातचीत नहीं की गई थी या सत्यापन विफल हो जाता है, तो नीति को चुपचाप डाउनग्रेड करने के बजाय संरक्षित संचालन को अस्वीकार करना चाहिए या कनेक्शन बंद करना चाहिए।"
चरण-दर-चरण गहन उत्तर
चरण 1: क्षमता पर बातचीत करें और एक अप्रमाणित एन्क्रिप्टेड सत्र बनाएं
क्लाइंट ClientHello में समर्थन का विज्ञापन करता है। सर्वर सामान्य TLS 1.3 हैंडशेक पूरा करता है लेकिन कनेक्शन को एन्क्रिप्टेड और क्लाइंट-अप्रमाणित के रूप में चिह्नित करता है। एक क्लाइंट जिसने क्षमता का विज्ञापन नहीं किया था, उसे बाद में प्रमाणपत्र प्रस्तुत करने की आवश्यकता नहीं हो सकती है; इसे कम विशेषाधिकार पर रूट करें या नीति के अनुसार पुन: कनेक्ट करें।
चरण 2: नीति की आवश्यकता होने पर CertificateRequest भेजें
जब कोई उच्च-जोखिम वाला एंडपॉइंट या किरायेदार नीति पहचान की मांग करती है, तो सर्वर स्वीकार्य हस्ताक्षर एल्गोरिदम और प्रमाणपत्र-प्राधिकरण बाधाओं के साथ CertificateRequest भेजता है। TLS स्टेट मशीन को इसे एप्लिकेशन राइट्स के साथ क्रमबद्ध (serialize) करना चाहिए ताकि समवर्ती स्ट्रीम आधी-अपडेट की गई स्थिति का निरीक्षण न कर सकें।
चरण 3: क्लाइंट प्रतिक्रिया को मान्य करें
क्लाइंट अपनी प्रमाणपत्र श्रृंखला, CertificateVerify और Finished भेजता है। श्रृंखला, SAN या URI पहचान, कुंजी उपयोग, हस्ताक्षर एल्गोरिदम, वैधता और निरसन को मान्य करें। उसके बाद ही पहचान, प्रमाणपत्र फ़िंगरप्रिंट और प्रमाणीकरण समय को कनेक्शन संदर्भ से जोड़ें। पहले आने वाले संवेदनशील अनुरोधों को कतारबद्ध या अस्वीकार किया जाना चाहिए।
चरण 4: विफलता और पुनरावृत्ति (retries) को संभालें
असमर्थित क्षमता, अनुपलब्ध प्रमाणपत्र, अमान्य हस्ताक्षर, या निरसन के लिए, एक एप्लिकेशन त्रुटि लौटाएं, एक TLS अलर्ट भेजें, या नीति के अनुसार बंद करें। पुनरावृत्तियों को गणना और समय द्वारा सीमित करें। कभी भी किसी विफल उच्च-जोखिम वाले अनुरोध को स्वचालित रूप से एक अज्ञात अनुरोध में न बदलें। निजी कुंजी सामग्री या अनावश्यक प्रमाणपत्र सामग्री के बिना त्रुटि वर्गों और कॉन्फ़िगरेशन संस्करणों को लॉग करें।
चरण 5: पुनरारंभ, समवर्तीता और माइग्रेशन का हिसाब रखें
सत्र का पुनरारंभ स्वचालित रूप से यह साबित नहीं करता है कि वर्तमान एप्लिकेशन प्राधिकरण अभी भी मान्य है। पुनरारंभ किए गए कनेक्शन पर नीति का पुनर्मूल्यांकन करें। HTTP/2 मल्टीप्लेक्सिंग के साथ, एक स्ट्रीम प्रमाणीकरण को ट्रिगर कर सकती है जबकि अन्य स्ट्रीम अनुरोध भेजती हैं, इसलिए ब्लॉकिंग सीमा को परिभाषित करें। वादा करने से पहले पुष्टि करें कि HTTP/3 QUIC/TLS कार्यान्वयन संदेश प्रवाह का समर्थन करता है।
चरण 6: ट्रस्ट और कुंजी सामग्री का संचालन करें
एक समर्पित क्लाइंट CA, अल्पकालिक प्रमाणपत्र और एक ऑडिट योग्य ट्रस्ट-स्टोर रोलआउट का उपयोग करें। CA रोटेशन के दौरान एक दोहरी-विश्वास विंडो और एक रोलबैक पथ रखें। सर्वर निजी कुंजियों, ट्रस्ट स्टोर और नीति प्रकाशन के लिए अनुमतियों को अलग करें; क्लाइंट सत्यापन से सर्वर-कुंजी परिचालनों तक पहुंच नहीं मिलनी चाहिए।
चरण 7: परीक्षण और निरीक्षण करें
क्षमता वाले और बिना क्षमता वाले क्लाइंट का एक मैट्रिक्स बनाएं। सफलता, समाप्त हो चुके प्रमाणपत्र, गलत हस्ताक्षर, निरसन, टाइमआउट, समवर्ती स्ट्रीम और पुनरारंभ का परीक्षण करें। CertificateRequest दर, सफलता दर, विफलता वर्ग, प्रमाणीकरण विलंबता, अस्वीकृत संरक्षित अनुरोध और कनेक्शन बंद होने की निगरानी करें। सुनिश्चित करें कि परीक्षण लॉग निजी कुंजियों या पूर्ण संवेदनशील पेलोड को उजागर न करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं दो स्थितियों को मॉडल करूंगा: एन्क्रिप्टेड-लेकिन-अप्रमाणित और क्लाइंट-प्रमाणित। सर्वर द्वारा CertificateRequest भेजे जाने से पहले क्लाइंट को ClientHello में post_handshake_auth का विज्ञापन करना चाहिए। क्लाइंट अपनी श्रृंखला, CertificateVerify और Finished लौटाता है; सर्वर उच्च-जोखिम वाले अनुरोध से पहचान को जोड़ने से पहले CA, SAN, उपयोग, हस्ताक्षर, वैधता और निरसन की जांच करता है।
यदि क्षमता पर बातचीत नहीं की गई थी या सत्यापन विफल हो जाता है, तो संरक्षित संचालन को अस्वीकार करें; चुपचाप डाउनग्रेड न करें। प्रमाणीकरण लंबित रहने के दौरान संरक्षित HTTP/2 स्ट्रीम को फ्रीज करें, और HTTP/3 के लिए लाइब्रेरी समर्थन सत्यापित करें। पुनरारंभ के बाद प्राधिकरण का पुनर्मूल्यांकन करें। क्लाइंट मैट्रिक्स के साथ रोल आउट करें और आरंभ, सफलता, विफलता के कारणों, विलंबता और निरसन व्यवहार का निरीक्षण करें।
सामान्य गलतियाँ
- गलती: यह मान लेना कि एक स्थापित कनेक्शन का अर्थ है कि क्लाइंट प्रमाणित है। → यह क्यों विफल होता है: एन्क्रिप्शन और क्लाइंट पहचान अलग-अलग स्थितियां हैं। → सुधार: दोनों स्थितियों को स्पष्ट रूप से ट्रैक करें।
- गलती: ऐसे क्लाइंट से प्रमाणपत्र की मांग करना जिसने क्षमता पर बातचीत नहीं की थी। → यह क्यों विफल होता है: क्षमता का विज्ञापन प्रारंभिक ClientHello में किया जाना चाहिए। → सुधार: कम विशेषाधिकार या पुन: कनेक्ट नीति का उपयोग करें।
- गलती: प्रमाणीकरण विफल होने के बाद अनुरोध को निष्पादित करना। → यह क्यों विफल होता है: प्रमाणीकरण संदेश एसिंक्रोनस रूप से आते हैं और कार्य को पूर्वव्यापी रूप से सुरक्षित नहीं करते हैं। → सुधार: सत्यापन पूरा होने तक संरक्षित स्ट्रीम को ब्लॉक करें।
- गलती: नए किरायेदार प्राधिकरण के लिए पुराने कनेक्शन पहचान का पुन: उपयोग करना। → यह क्यों विफल होता है: पुनरारंभ और नीति परिवर्तन पुरानी एप्लिकेशन स्थिति को अमान्य कर सकते हैं। → सुधार: प्राधिकरण संस्करण का उपयोग करके पुनर्मूल्यांकन करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: प्रारंभिक म्यूचुअल TLS अभी भी सामान्य क्यों है?
प्रारंभिक म्यूचुअल TLS हैंडशेक समाप्त होने से पहले पहचान का चयन और सत्यापन करता है, इसलिए जब प्रत्येक अनुरोध को प्रमाणीकरण की आवश्यकता होती है तो इसकी स्थिति और अनुकूलता की कहानी सरल होती है। पोस्ट-हैंडशेक प्रमाणीकरण लंबे समय तक चलने वाले कनेक्शनों के लिए उपयुक्त है जहां केवल कुछ ही परिचालनों को अतिरिक्त पहचान की आवश्यकता होती है, जिसके लिए अधिक स्थिति और समवर्ती नियमों की लागत आती है।
फॉलो-अप 2: क्या यह एप्लिकेशन प्राधिकरण को बदल सकता है?
नहीं। यह एक निजी कुंजी और एक वैध प्रमाणपत्र श्रृंखला के कब्जे को साबित करता है। एप्लिकेशन अभी भी SAN, किरायेदार, भूमिका, संचालन और निरसन स्थिति को एक प्राधिकरण निर्णय पर मैप करता है और निर्णय संस्करण को रिकॉर्ड करता है।
फॉलो-अप 3: क्या प्रमाणपत्र के बिना क्लाइंट को डिस्कनेक्ट किया जाना चाहिए?
हमेशा नहीं। एक नीति कम विशेषाधिकार वाले सत्र को बनाए रख सकती है और संरक्षित अनुरोधों को अस्वीकार कर सकती है। एक प्रबंधन विमान जिसे निरंतर प्रमाणीकरण की आवश्यकता होती है, उसे एक स्पष्ट त्रुटि लौटानी चाहिए और बंद करना चाहिए। विकल्प को ऑडिट योग्य और देखने योग्य बनाएं।
फॉलो-अप 4: आप कैसे साबित करते हैं कि कोई लाइब्रेरी प्रवाह का समर्थन करती है?
एक्सटेंशन वार्ता, CertificateRequest, अमान्य प्रमाणपत्र, समवर्ती स्ट्रीम और पुनरारंभ के लिए संस्करणित API और इंटरऑपरेबिलिटी परीक्षणों की जांच करें। एक एकल कॉन्फ़िगरेशन ध्वज यह साबित नहीं करता है कि संपूर्ण स्टेट मशीन लागू की गई है।