TLS 1.3 अजूनही सर्व्हर नाव साध्या मजकुरात पाठवते
TLS 1.3 हँडशेक एन्क्रिप्ट करते पण SNI नाही। ClientHello वाचा, खरी ECH स्वीकृती तपासा आणि निरीक्षक अजून काय पाहू शकतो ते नोंदवा।
लिसनरला 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 उपलब्ध असताना आणि नसताना कसे वागतात ते तपासा। नंतर सुसंगतीचा परिणाम नोंदवा, कारण गपचूप जुळणी थांबवणारा गाळणी कधीही तैनात न झालेल्यापेक्षा वाईट आहे।
शेवटी, अनिश्चितता नोंदीत ठेवा। जुना सार्वत्रिक दावा नव्याने बदलल्यास तीच पोकळी दुसऱ्या प्रोटोकॉल नावाखाली राहते, आणि पुढील परीक्षक त्यावर तितक्याच दृढतेने विश्वास ठेवेल।