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 ઉપલબ્ધ હોય ત્યારે અને ન હોય ત્યારે કેવી રીતે વર્તે છે. પછી સુસંગતતાનું પરિણામ નોંધો, કારણ કે ચૂપચાપ મેળ બંધ કરતું ફિલ્ટર ક્યારેય તૈનાત ન થયેલા ફિલ્ટર કરતાં ખરાબ છે.

અંતે, અનિશ્ચિતતા રેકોર્ડમાં રાખો. જૂના સાર્વત્રિક દાવાને નવા સાથે બદલવાથી એ જ ખાલી જગ્યા બીજા પ્રોટોકોલ નામ હેઠળ રહે છે, અને આગલો સમીક્ષક તેના પર એટલી જ દૃઢતાથી વિશ્વાસ કરશે.