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 उपलब्ध हो और जब न हो। फिर अनुकूलता का परिणाम दर्ज करें, क्योंकि चुपचाप मिलान बंद करने वाला फ़िल्टर उससे बुरा है जो कभी तैनात ही नहीं हुआ।

अंत में, अनिश्चितता को रिकॉर्ड में रखें। पुराने वैश्विक दावे को नए से बदलने पर वही खाई किसी दूसरे प्रोटोकॉल नाम के तहत बची रहती है, और अगला समीक्षक उसी दृढ़ता से उस पर विश्वास करेगा।