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 అందుబాటులో ఉన్నప్పుడు మరియు లేనప్పుడు అమర్చిన క్లయింట్లు ఎలా ప్రవర్తిస్తాయో పరీక్షించండి. తర్వాత అనుకూలత పరిణామాన్ని నమోదు చేయండి, ఎందుకంటే నిశ్శబ్దంగా సరిపోలికను ఆపే ఫిల్టర్ ఎప్పుడూ అమర్చని దాని కంటే అధ్వాన్నం.

చివరగా, అనిశ్చితిని రికార్డులో ఉంచండి. పాత సార్వత్రిక దావాను కొత్త దానితో భర్తీ చేయడం అదే ఖాళీని మరో ప్రోటోకాల్ పేరు కింద వదిలిస్తుంది, మరియు తదుపరి సమీక్షకుడు అదే దృఢత్వంతో దాన్ని నమ్ముతారు.