TLS कुंजी-साझा बनाम क्लाइंट प्रमाणपत्र: कौन लॉग इन करता है?
कुंजी-समझौते को क्लाइंट प्रमाणीकरण और अनुप्रयोग पहचान से अलग कीजिए, और हैंडशेक संदेश पढ़िए जो दिखाते हैं कि कनेक्शन ने वास्तव में किसका उपयोग किया।
हैंडशेक में सार्वजनिक कुंजी-विनिमय मान ले जाना वही घटना नहीं है जो क्लाइंट का लॉग इन होना है। एक कनेक्शन के लिए क्रिप्टोग्राफ़िक स्थिति स्थापित करता है; दूसरा बताता है कि क्लाइंट कौन है, और यह केवल तब होता है जब सर्वर इसकी माँग करता है और विनिमय इसे समर्थन देता है। पहले को दूसरा मानने से VPN क्या छिपाता है और क्या नहीं, इस पर गलत निष्कर्ष निकलते हैं। संदेश पढ़िए, फिर तय कीजिए कि चार गुणों में से किसे आपने वास्तव में देखा।
कैप्चर में एक जैसे दिखने वाले दो ऑब्जेक्ट
TLS 1.3 क्लाइंट बिना कोई प्रमाणपत्र प्रस्तुत किए अपनी पहली उड़ान में कुंजी-विनिमय सामग्री दे सकता है। यह योगदान डिज़ाइन से ही सार्वजनिक है, क्योंकि साझा रहस्य निकालने के लिए सर्वर को इसकी आवश्यकता होती है। क्लाइंट प्रमाणपत्र एक अलग संदेश है, और सर्वर के माँगने के बाद ही भेजा जाता है। यह एक पहचान रखता है जिसे सर्वर बाद में सत्यापित करता है, और पारस्परिक प्रमाणीकरण सर्वर का निर्णय है, सिफ़र सूट का अनिवार्य गुण नहीं। अनुप्रयोग पहचान बिल्कुल तीसरी चीज़ है: लॉगिन फ़ॉर्म, बियरर टोकन, कुकी। इनमें से कोई हैंडशेक में नहीं दिखता, और ये सभी नेटवर्क पथ बदलने पर टिके रहते हैं।
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
चारों पंक्तियाँ स्वतंत्र हैं। कनेक्शन में पहली और दूसरी पंक्ति हो सकती है, तीसरी छूट सकती है, और फिर भी कुकी हेडर में चौथी रह सकती है।
तय कीजिए कि पकड़ा गया हैंडशेक क्या सिद्ध कर सकता है
केवल हैंडशेक से पर्यवेक्षक बातचीत किया गया संस्करण, सिफ़र सूट, सर्वर का प्रमाणपत्र और सार्वजनिक कुंजी-विनिमय मान जानता है। यह क्लाइंट कार्यान्वयन का फ़िंगरप्रिंट लेने और यह देखने के लिए पर्याप्त है कि किस सर्वर से संपर्क हुआ। जो यह नहीं देता वह कनेक्शन को डिक्रिप्ट करने के लिए आवश्यक निजी स्थिति है, जिसकी गोपनीयता सार्वजनिक हिस्से पर नहीं बल्कि क्षणिक विनिमय पर टिकी है। यह खाता पहचान भी नहीं देता, जो शुरू से ही हैंडशेक में नहीं थी।
इसलिए ईमानदार निष्कर्ष सीमित है: इस विनिमय में कोई क्लाइंट प्रमाणपत्र प्रस्तुत नहीं किया गया। बात यह नहीं है कि क्लाइंट ने जोड़ने योग्य कुछ नहीं भेजा, और निश्चित रूप से यह नहीं कि सत्र कोई पहचानकर्ता नहीं रखता था।
सिफ़र का नाम नहीं, संदेश पढ़िए
सिफ़र सूट से अनुमान लगाने के बजाय सर्वर से पूछिए कि वह क्या माँगता है। प्रमाणपत्र अनुरोध सहित TLS 1.3 हैंडशेक ट्रांसक्रिप्ट में दिखता है, और उसका अभाव भी उतना ही दिखता है।
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'फिर क्लाइंट प्रमाणपत्र कॉन्फ़िगर करके दोहराइए और तुलना कीजिए। दूसरे रन में प्रमाणपत्र भेजा और स्वीकार किया जाता दिखना चाहिए; पहले में कुछ भी नहीं दिखना चाहिए, और यही वह ठोस अंतर है जिस पर बहस है।
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quietयदि आपको केवल सामान्य ब्राउज़िंग स्थिति चाहिए, तो क्लाइंट का विस्तृत आउटपुट प्रोटोकॉल संस्करण, सत्यापन परिणाम और यह देखने के लिए पर्याप्त है कि क्लाइंट प्रमाणपत्र दिया गया या नहीं। जो सर्वर कभी प्रमाणपत्र अनुरोध नहीं भेजता, उसे एक प्राप्त हो ही नहीं सकता।
जहाँ पुनःआरंभ उत्तर बदल देता है
TLS 1.3 में पुनःआरंभ गुप्त स्थिति से जुड़े टिकटों का उपयोग करता है, इसलिए बाद का कनेक्शन पूर्ण प्रमाणपत्र विनिमय के बिना पूरा हो सकता है। यह पर्यवेक्षक को कम दिखाता है और ट्रांसक्रिप्ट जो सिद्ध करता है उसे बदल देता है। यह वहाँ पहचान नहीं बनाता जहाँ पहले नहीं थी। पुनःआरंभ किया गया सत्र अब भी उसी अनुप्रयोग सत्र का हिस्सा है, और उस सत्र का कोई भी कुकी या टोकन महत्वपूर्ण पहचानकर्ता बना रहता है।
इसीलिए "कोई क्लाइंट प्रमाणपत्र नहीं" पर रुकने वाली गोपनीयता समीक्षा रोचक हिस्सा चूक जाती है। पूछने योग्य प्रश्न यह है कि कौन-सा पक्ष स्थिर पहचानकर्ता रखता है, यह नहीं कि एक हैंडशेक से कौन-सा संदेश अनुपस्थित था।
एक निर्णय नहीं, चार गुण लिखिए
कुंजी-समझौता, सर्वर सत्यापन, क्लाइंट प्रमाणीकरण और अनुप्रयोग पहचान को चार अलग पंक्तियों के रूप में लिखिए, प्रत्येक के प्रमाण सहित। यह सूची प्रोटोकॉल संस्करण बदलने पर भी टिकती है, और गोपनीयता पर तर्क को किसी और के लिए जाँचने योग्य बनाती है। फिर जोड़िए कि नेटवर्क पथ क्या देता है। VPN वह स्रोत पता बदलता है जो सेवा देखती है; यह उन लॉगिन, कुकी या डिवाइस फ़िंगरप्रिंट को नहीं हटाता जो अनुप्रयोग के पास पहले से हैं।
कनेक्शन का बातचीत किया गया संस्करण और प्रमाणपत्र अनुरोध का परिणाम साथ-साथ लिखिए, क्योंकि समीक्षक को अपने कैप्चर के बिना आपका निष्कर्ष दोहराने के लिए यही युग्म चाहिए।