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'

Առաջին հրամանը ցույց է տալիս՝ արդյոք ծագումը հրապարակում է HTTPS ռեսուրսի գրառում ECH կարգավորման պարամետրով, և այդպես են հաճախորդները սովորում բանալին։ Երկրորդը փնտրում է ձեռքսեղմման կարգավիճակի տեղեկություն, թեև հաճախորդի հաջողության հաղորդագրությունն ավելի ուժեղ ապացույց է։ Ընդունումն է, որ կարևոր է. սերվերը, որը չունի համապատասխան բանալին, չի կարող վերծանել ներքին hello-ն, և կապը հետ է գլորվում։

Ստուգեք նաև հաճախորդին, որովհետև զննարկիչների աջակցությունը և կարգավորումը տարբերվում են ըստ տարբերակի և հարթակի։ «Ժամանակակից զննարկիչները օգտագործում են ECH» վրա կառուցված քաղաքականությունը ենթադրություն է պարկի մասին, ոչ թե փաստ ձեր պարկի մասին։ Գույքագրեք այն տարբերակները, որոնք իրականում միանում են, ապա փորձարկեք դրանցից մեկը։ Նույն էջը, որն աշխատում է ընթացիկ աշխատասեղանի զննարկիչից, կարող է ոչինչ չթաքցնել ավելի հին հաճախորդից նույն ցանցում։

Գրեք դիտորդի շրջանակը քաղաքականության մեջ

Նշեք, թե որտեղ է նստում դիտորդը և ինչ է տեսանելի այդ կետում, նախքան որոշելը, թե ինչի վրա կարող է հենվել վերահսկողությունը։ Զննարկիչի կապը կայքի հետ, արտաքին VPN տրանսպորտը և TLS-ը ավարտող պրոքսին յուրաքանչյուրը բացահայտում է փաստերի այլ հավաքածու, և մեկ դիրքի համար գրված կանոնը հազվադեպ է մաքուր փոխանցվում մյուսին։

Եթե վերահսկողությունը կախված է SNI-ն կարդալուց, փորձարկեք, թե ինչպես են իրեն պահում տեղակայված հաճախորդները, երբ ECH-ը հասանելի է և երբ ոչ։ Այնուհետև գրանցեք համատեղելիության հետևանքը, որովհետև ֆիլտրը, որը լուռ դադարում է համապատասխանել, ավելի վատ է, քան այն, որը երբեք չի տեղակայվել։

Վերջապես, պահեք անորոշությունը արձանագրության մեջ։ Հին համընդհանուր պնդումը ավելի նորով փոխարինելը թողնում է նույն բացը՝ այլ արձանագրության անվան տակ, և հաջորդ գրախոսը նույնքան ամուր կհավատա դրան։