TLS 1.3 अझै सर्भर नाम सादा पाठमा पठाउँछ

लिसनरलाई TLS 1.3 मा अपग्रेड गर्नाले पर्यवेक्षकले के पढ्न सक्छ भन्ने परिवर्तन हुन्छ, तर संस्करण नम्बरले संकेत गरेजति होइन। ClientHello अझै कुनै पनि इन्क्रिप्शनमा वार्ता हुनुअघि यात्रा गर्छ, र सामान्य जडानमा अनुरोध गरिएको सर्भर नाम त्यहाँ सादा पाठमा रहन्छ। Encrypted Client Hello त्यसलाई लुकाउने संयन्त्र हो, र यो आफ्नै पूर्वसर्तहरू भएको छुट्टै तैनाथी हो। दुवैमध्ये कुनै पनि व्यवहार मान्ने नीति लेख्नुअघि यी चार चरणहरू गर्नुहोस्।

ह्यान्डशेकले वास्तवमा के खोल्छ

TLS 1.3 ले सर्भरको प्रमाणपत्र र ServerHello पछि आउने अधिकांश ह्यान्डशेक इन्क्रिप्ट गर्छ। क्लाइन्टले पहिलो पठाउने सबै कुरा त्यो सुरक्षाबाहिर रहन्छ, किनकि कुञ्जीहरू अझै अवस्थित छैनन्। सर्भर नामको संकेत त्यही पहिलो उडानको भाग हो, त्यसैले निष्क्रिय पर्यवेक्षक बिना केही तोडी अझै पढ्न सक्छ।

ECH विनिर्देश, RFC 9849, सहयोगी सर्भरका लागि भित्री ClientHello इन्क्रिप्ट गरेर यसलाई बदल्छ। बाहिरी ह्यान्डशेक रहन्छ र नेटवर्कले देख्न सक्ने सार्वजनिक नाम बोक्छ, त्यसैले तैनाथीलाई अझै बाहिरी पहिचान चाहिन्छ जुन बिचौलियाका लागि अर्थपूर्ण होस्। त्यो बाहिरी नाम नै त्यो भाग हो जुन मानिसहरूले जडान अनाम हुने अपेक्षा गर्दा छुटाउँछन्। यो आवरण नाम हो, लुकेको नाम होइन, र यो अरू जस्तै समाधान र प्रमाणित हुनुपर्छ।

यीमध्ये केहीले पनि डेलिभरी मार्ग लुकाउँदैन। स्रोत र गन्तव्य ठेगाना, पोर्ट, प्याकेट आकार र समय अवलोकनयोग्य रहन्छन्, र ती प्रायः नामभन्दा बढी कसले बोलिरहेको छ भन्ने बताउँछन्। नाम विश्लेषण र अनुप्रयोग तहका सम्बन्ध अर्को तह हो, प्रत्येकको आफ्नै दृश्यता।

अनुमान गर्नुको साटो ClientHello पढ्नुहोस्

ServerHello मा भएको संस्करणले क्लाइन्टले के पठायो भनेर बताउँदैन। पहिलो उडान सिधै हेर्नुहोस्, तपाईंका लागि महत्त्वपूर्ण पर्यवेक्षक प्रतिनिधित्व गर्ने स्थितिबाट।

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

पहिलो आदेशले ह्यान्डशेक गर्छ र सहमत प्यारामिटरहरू देखाउँछ, जसमा प्रोटोकल संस्करण र तपाईंले मागेको नाम समावेश छ। दोस्रोले वास्तविक जडानका पहिलो प्याकेटहरू क्याप्चर गर्छ, र तेस्रोले त्यो क्याप्चरबाट SNI फिल्ड निकाल्छ। फिल्ड भरिएको भए, तपाईंले अनुकरण गरेको पर्यवेक्षकले त्यो पढ्न सक्छ।

दुई नमिलेमा क्लाइन्ट पक्ष र मार्गमा छुट्टाछुट्टै क्याप्चर गर्नुहोस्, किनकि स्थानीय क्याप्चरले middlebox पछि पुनः लेख्ने वा फाल्ने नाम देखाउन सक्छ। आफैं TLS अन्त्य नगर्ने होस्टबाट पनि क्याप्चर गर्नुहोस्, किनकि अन्त्य गर्ने प्रोक्सीले सादा पाठ आफ्नो संरचनाअनुसार देख्छ र नेटवर्कले के देख्छ भन्ने केही प्रमाणित गर्दैन।

ECH विस्तारलाई दाबी मान्नुहोस्, प्रमाण होइन

ClientHello मा ECH विस्तार देख्नुको अर्थ जडानले ECH प्रयोग गर्यो भन्ने होइन। क्लाइन्टसँग प्रयोगयोग्य कन्फिगरेसन नभए GREASE ECH पठाउँछन्, ठ्याक्कै तिनका ह्यान्डशेक एउटै देखियोस् भनेर। विस्तार उपस्थित छ, भित्री hello चारो हो, र वास्तविक नाम अझै पढ्न सकिने छ।

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

पहिलो आदेशले मूलले ECH कन्फिगरेसन प्यारामिटरसहित HTTPS स्रोत रेकर्ड प्रकाशित गर्छ कि भनेर देखाउँछ, र यसरी क्लाइन्टले कुञ्जी सिक्छन्। दोस्रोले ह्यान्डशेकको स्थिति जानकारी खोज्छ, यद्यपि क्लाइन्टको सफलता सन्देश बलियो प्रमाण हो। स्वीकृति महत्त्वपूर्ण छ: जसको सँग मिल्ने कुञ्जी छैन त्यो सर्भरले भित्री hello डिक्रिप्ट गर्न सक्दैन, र जडान पछाडि हट्छ।

क्लाइन्ट पनि जाँच्नुहोस्, किनकि ब्राउजर समर्थन र कन्फिगरेसन संस्करण र प्लेटफर्मअनुसार फरक पर्छ। „आधुनिक ब्राउजरले ECH प्रयोग गर्छन्“ मा आधारित नीति बेडाको बारेमा अनुमान हो, तपाईंको बेडाको बारेमा तथ्य होइन। वास्तवमा जोडिने संस्करणको सूची बनाउनुहोस्, त्यसपछि प्रत्येकबाट एउटा परीक्षण गर्नुहोस्। सायद हालको डेस्कटप ब्राउजरबाट काम गर्ने त्यही पृष्ठले उही नेटवर्कको पुरानो क्लाइन्टबाट केही पनि लुकाउँदैन।

पर्यवेक्षकको दायरा नीतिमा लेख्नुहोस्

कुन नियन्त्रण केमा भर पर्न सक्छ भनेर निर्णय गर्नुअघि पर्यवेक्षक कहाँ बस्छ र त्यो बिन्दुमा के देखिन्छ भनेर बताउनुहोस्। ब्राउजरको साइटसँग जडान, बाहिरी VPN ढुवानी र TLS अन्त्य गर्ने प्रोक्सी — प्रत्येकले फरक तथ्यसंग्रह खोल्छ, र एउटा स्थितिका लागि लेखिएको नियम अर्कोमा सायदै सफा सर्छ।

यदि कुनै नियन्त्रण SNI पढ्नमा निर्भर छ भने, तैनाथ क्लाइन्टले ECH उपलब्ध हुँदा र नहुँदा कसरी व्यवहार गर्छन् परीक्षण गर्नुहोस्। त्यसपछि अनुकूलताको परिणाम रेकर्ड गर्नुहोस्, किनकि चुपचाप मिलाउन छोड्ने फिल्टर कहिल्यै तैनाथ नभएकोभन्दा नराम्रो हो।

अन्तमा, अनिश्चितता अभिलेखमा राख्नुहोस्। पुरानो सार्वभौमिक दाबीलाई नयाँले बदल्दा त्यही खाली ठाउँ अर्को प्रोटोकल नाममुनि रहन्छ, र अर्को समीक्षकले त्यसमा उत्तिकै दृढतासाथ विश्वास गर्नेछ।