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 सेवेला दिसणारा स्रोत पत्ता बदलते; ते अनुप्रयोगाकडे आधीच असलेले लॉग इन, कुकी किंवा डिव्हाइस फिंगरप्रिंट काढून टाकत नाही।
कनेक्शनची वाटाघाटी केलेली आवृत्ती आणि प्रमाणपत्र विनंतीचा निकाल एकत्र लिहा, कारण स्वतःच्या कॅप्चरशिवाय तुमचा निष्कर्ष पुन्हा तयार करण्यासाठी समीक्षकाला हेच जोडपे लागते।