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 ले सेवाले देख्ने स्रोत ठेगाना बदल्छ; यसले अनुप्रयोगसँग पहिले नै भएको लगइन, कुकी वा यन्त्र फिंगरप्रिन्ट हटाउँदैन।
कनेक्सनको वार्ता गरिएको संस्करण र प्रमाणपत्र अनुरोधको नतिजा सँगै लेख्नुहोस्, किनकि आफ्नै क्याप्चरबिना तपाईंको निष्कर्ष पुनः उत्पादन गर्न समीक्षकलाई यही जोडी चाहिन्छ।