Ներածություն
Ժամանակակից կորպորատիվ բովանդակության զտման համակարգերը այնպիսի հայտնի արտադրողների, ինչպիսիք են Cisco-ն, BlueCoat-ը, FireEye-ն, բավականին ընդհանրություններ ունեն իրենց ավելի հզոր գործընկերների՝ DPI համակարգերի հետ, որոնք ակտիվորեն ներդրվում են ազգային մակարդակում: Երկուսի աշխատանքի էությունն էլ ներգնա և ելքային ինտերնետ տրաֆիկի ստուգումն է և սև/սպիտակ ցուցակների հիման վրա որոշում կայացնել ինտերնետ կապն արգելելու մասին։ Եվ քանի որ երկուսն էլ իրենց աշխատանքի հիմունքներում հիմնվում են նմանատիպ սկզբունքների վրա, դրանք շրջանցելու մեթոդները նույնպես շատ ընդհանրություններ կունենան։
Տեխնոլոգիաներից մեկը, որը թույլ է տալիս բավականին արդյունավետ կերպով շրջանցել ինչպես DPI, այնպես էլ կորպորատիվ համակարգերը, տիրույթի ճակատային տեխնոլոգիան է։ Դրա էությունն այն է, որ մենք գնում ենք դեպի արգելափակված ռեսուրս՝ թաքնվելով մեկ այլ, բարի համբավ ունեցող հանրային տիրույթի հետևում, որն ակնհայտորեն չի արգելափակվի որևէ համակարգի կողմից, օրինակ՝ google.com-ը։
Այս տեխնոլոգիայի մասին արդեն բավականին շատ հոդվածներ են գրվել ու բազմաթիվ օրինակներ են բերվել։ Այնուամենայնիվ, հանրաճանաչ և վերջերս քննարկված DNS-over-HTTPS և կոդավորված-SNI տեխնոլոգիաները, ինչպես նաև TLS 1.3 արձանագրության նոր տարբերակը հնարավորություն են տալիս դիտարկել տիրույթի ֆրոնտինգի մեկ այլ տարբերակ:
Հասկանալով տեխնոլոգիան
Նախ, եկեք սահմանենք մի փոքր հիմնական հասկացություններ, որպեսզի բոլորը հասկանան, թե ով ով է և ինչու է անհրաժեշտ այս ամենը: Մենք նշեցինք eSNI մեխանիզմը, որի գործունեության մասին կքննարկենք հետագա։ eSNI (գաղտնագրված սերվերի անվան ցուցում) մեխանիզմը SNI-ի անվտանգ տարբերակն է, որը հասանելի է միայն TLS 1.3 արձանագրության համար: Հիմնական գաղափարը, ի թիվս այլ բաների, գաղտնագրելն է այն մասին, թե որ տիրույթին է ուղարկվում հարցումը:
Հիմա եկեք տեսնենք, թե ինչպես է eSNI մեխանիզմը գործում գործնականում:
Ենթադրենք, որ մենք ունենք ինտերնետ ռեսուրս, որն արգելափակված է ժամանակակից DPI լուծումով (օրինակ՝ հայտնի torrent tracker rutracker.nl): Երբ մենք փորձում ենք մուտք գործել torrent tracker-ի կայք, մենք տեսնում ենք մատակարարի ստանդարտ կոճակը, որը ցույց է տալիս, որ ռեսուրսն արգելափակված է.
RKN կայքում այս տիրույթը իրականում նշված է կանգառների ցուցակներում.
Երբ հարցում եք անում whois-ին, կարող եք տեսնել, որ տիրույթն ինքնին «թաքնված է» Cloudflare ամպային մատակարարի հետևում:
Բայց ի տարբերություն RKN-ի «մասնագետների», Beeline-ի ավելի տեխնիկապես ըմբռնող աշխատակիցները (կամ մեր հայտնի կարգավորողի դառը փորձով ուսուցանված) հիմարաբար չեն արգելել կայքը IP հասցեով, այլ ավելացրել են տիրույթի անունը կանգառի ցուցակում: Դուք կարող եք հեշտությամբ հաստատել դա, եթե նայեք, թե ինչ այլ տիրույթներ են թաքնված նույն IP հասցեի հետևում, այցելեք դրանցից մեկը և տեսնեք, որ մուտքն արգելափակված չէ.
Ինչպե՞ս է դա տեղի ունենում: Ինչպե՞ս է պրովայդերի DPI-ն իմանում, թե որ տիրույթում է իմ բրաուզերը, քանի որ բոլոր հաղորդակցությունները կատարվում են https պրոտոկոլի միջոցով, և մենք դեռ չենք նկատել Beeline-ից https սերտիֆիկատների փոխարինումը: Նա պայծառատես է, թե՞ ինձ հետևում են։
Փորձենք պատասխանել այս հարցին՝ դիտելով երթևեկությունը wireshark-ի միջոցով
Սքրինշոթը ցույց է տալիս, որ նախ զննարկիչը ստանում է սերվերի IP հասցեն DNS-ի միջոցով, այնուհետև տեղի է ունենում ստանդարտ TCP ձեռքսեղմում նպատակակետ սերվերի հետ, այնուհետև զննարկիչը փորձում է SSL կապ հաստատել սերվերի հետ: Դա անելու համար այն ուղարկում է SSL Client Hello փաթեթ, որը պարունակում է աղբյուրի տիրույթի անունը մաքուր տեքստով: Այս դաշտը պահանջվում է cloudflare frontend սերվերի կողմից՝ կապը ճիշտ ուղղորդելու համար: Այստեղ է, որ մատակարար DPI-ն բռնում է մեզ՝ խզելով մեր կապը: Միևնույն ժամանակ, մենք պրովայդերից ոչ մի անավարտ չենք ստանում, և մենք տեսնում ենք բրաուզերի ստանդարտ սխալը, կարծես կայքը անջատված է կամ պարզապես չի աշխատում.
Այժմ եկեք միացնենք eSNI մեխանիզմը բրաուզերում, ինչպես գրված է հրահանգների մեջ :
Դա անելու համար մենք բացում ենք Firefox-ի կազմաձևման էջը մասին: config և ակտիվացրեք հետևյալ կարգավորումները.
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Դրանից հետո մենք կստուգենք, որ կարգավորումները ճիշտ են աշխատում cloudflare կայքում: և եկեք նորից փորձենք հնարքը մեր torrent tracker-ով:
Voila. Մեր սիրելի թրեքերը բացվեց առանց VPN կամ պրոքսի սերվերների: Եկեք հիմա նայենք wireshark-ի երթևեկության աղբին, որպեսզի տեսնենք, թե ինչ է տեղի ունեցել:
Այս անգամ ssl client hello փաթեթը բացահայտորեն չի պարունակում նպատակակետ տիրույթը, փոխարենը փաթեթում հայտնվեց նոր դաշտ՝ encrypted_server_name - այստեղ է պարունակվում rutracker.nl-ի արժեքը, և միայն cloudflare frontend սերվերը կարող է դա վերծանել: դաշտ. Եվ եթե այո, ապա պրովայդերի DPI-ն այլ ելք չունի, քան ձեռքերը լվանալ և թույլ տալ նման թրաֆիկ։ Կոդավորման հետ կապված այլ տարբերակներ չկան:
Այսպիսով, մենք նայեցինք, թե ինչպես է տեխնոլոգիան աշխատում բրաուզերում: Հիմա փորձենք դա կիրառել ավելի կոնկրետ ու հետաքրքիր բաների վրա։ Եվ նախ, մենք կսովորեցնենք նույն curl-ին օգտագործել eSNI՝ TLS 1.3-ի հետ աշխատելու համար, և միևնույն ժամանակ կտեսնենք, թե ինչպես է աշխատում eSNI-ի վրա հիմնված տիրույթի ֆրոնտինգը:
Դոմենի ճակատավորում eSNI-ով
Հաշվի առնելով այն հանգամանքը, որ curl-ն օգտագործում է ստանդարտ openssl գրադարանը՝ https արձանագրության միջոցով միանալու համար, նախևառաջ պետք է այնտեղ ապահովել eSNI աջակցություն։ Openssl-ի գլխավոր մասնաճյուղերում դեռևս չկա eSNI աջակցություն, ուստի մենք պետք է ներբեռնենք հատուկ openssl մասնաճյուղ, կազմենք և տեղադրենք այն:
Մենք կլոնավորում ենք պահոցը GitHub-ից և հավաքում, ինչպես միշտ.
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Այնուհետև մենք կլոնավորում ենք պահոցը curl-ով և կազմաձևում դրա կոմպիլյացիան՝ օգտագործելով մեր կազմված openssl գրադարանը.
$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni
$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug
Այստեղ կարևոր է ճիշտ նշել բոլոր այն դիրեկտորիաները, որտեղ գտնվում է openssl-ը (մեր դեպքում սա /opt/openssl/ է) և համոզվել, որ կազմաձևման գործընթացն անցնում է առանց սխալների:
Եթե կոնֆիգուրացիան հաջող է, մենք կտեսնենք տողը.
ԶԳՈՒՇԱՑՈՒՄ. esni ESNI-ն միացված է, բայց նշվել է ՓՈՐՁԱՐԿԱՆ: Օգտագործեք զգուշությամբ:
$ makeՓաթեթը հաջողությամբ կառուցելուց հետո մենք կօգտագործենք հատուկ bash ֆայլ openssl-ից՝ curl-ը կարգավորելու և գործարկելու համար: Հարմարության համար եկեք պատճենենք այն գրացուցակում՝ curl-ով.
cp /opt/openssl/esnistuff/curl-esni և կատարեք թեստային https հարցում cloudflare սերվերին՝ միաժամանակ ձայնագրելով DNS և TLS փաթեթները Wireshark-ում:
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Սերվերի պատասխանում, բացի openssl-ից և curl-ից վրիպազերծող բազմաթիվ տեղեկություններից, մենք կստանանք HTTP պատասխան 301 կոդով cloudflare-ից:
HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/
ինչը ցույց է տալիս, որ մեր հարցումը հաջողությամբ առաքվել է նպատակակետ սերվերին, լսվել և մշակվել:
Հիմա եկեք նայենք երթևեկության թափոնին wireshark-ում, այսինքն. ինչ տեսավ մատակարար DPI-ն այս դեպքում:
Կարելի է տեսնել, որ curl-ը սկզբում դիմել է DNS սերվերի՝ cloudflare սերվերի համար հանրային eSNI բանալի ստանալու համար՝ TXT DNS հարցում _esni.cloudflare.com-ին (փաթեթ թիվ 13): Այնուհետև, օգտագործելով openssl գրադարանը, curl-ը TLS 1.3 հարցում ուղարկեց cloudflare սերվերին, որտեղ SNI դաշտը գաղտնագրված էր նախորդ քայլում ստացված հանրային բանալիով (փաթեթ #22): Բայց, բացի eSNI դաշտից, SSL-hello փաթեթը ներառում էր նաև դաշտ սովորական բաց SNI-ով, որը մենք կարող ենք նշել ցանկացած կարգով (այս դեպքում՝ ).
Այս բաց SNI դաշտը որևէ կերպ հաշվի չի առնվել cloudflare սերվերների կողմից մշակվելիս և ծառայել է միայն որպես դիմակ մատակարարողի DPI-ի համար: Cloudflare սերվերը ստացավ մեր ssl-hello փաթեթը, ապակոդավորեց eSNI-ն, այնտեղից հանեց բնօրինակ SNI-ը և մշակեց այն այնպես, կարծես ոչինչ չէր պատահել (այն ամեն ինչ արեց ճիշտ այնպես, ինչպես պլանավորված էր eSNI-ն մշակելիս):
Միակ բանը, որ կարելի է բացահայտել այս դեպքում DPI-ի տեսանկյունից, առաջնային DNS հարցումն է _esni.cloudflare.com-ին: Բայց մենք բացեցինք DNS հարցումը միայն ցույց տալու համար, թե ինչպես է այս մեխանիզմը աշխատում ներսից:
Գորգը DPI-ի տակից վերջնականապես հանելու համար մենք օգտագործում ենք արդեն նշված DNS-over-HTTPS մեխանիզմը: Մի փոքր բացատրություն – DOH-ը արձանագրություն է, որը թույլ է տալիս պաշտպանվել մարդ-միջին հարձակումից՝ ուղարկելով DNS հարցում HTTPS-ով:
Եկեք նորից կատարենք հարցումը, բայց այս անգամ մենք կստանանք հանրային eSNI բանալիներ https արձանագրության միջոցով, ոչ թե DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Հարցման երթևեկության աղբանոցը ներկայացված է ստորև ներկայացված սքրինշոթում.
Տեսանելի է, որ curl-ը սկզբում մուտք է գործում mozilla.cloudflare-dns.com սերվեր DoH արձանագրության միջոցով (https միացում սերվերին 104.16.249.249)՝ նրանցից SNI կոդավորման համար հանրային բանալիների արժեքները ստանալու համար, այնուհետև՝ դեպի նպատակակետ։ սերվեր, որը թաքնվում է տիրույթի հետևում .
Բացի վերը նշված DoH լուծիչից mozilla.cloudflare-dns.com, մենք կարող ենք օգտվել այլ հայտնի DoH ծառայություններից, օրինակ՝ հայտնի չար կորպորացիայից:
Եկեք կատարենք հետևյալ հարցումը.
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Եվ մենք ստանում ենք պատասխանը.
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH
Այս դեպքում մենք դիմեցինք արգելափակված rutracker.nl սերվերին՝ օգտագործելով DoH լուծիչը dns.google (այստեղ տառասխալ չկա, այժմ հայտնի կորպորացիան ունի իր առաջին մակարդակի տիրույթը) և ծածկվել մեկ այլ տիրույթով, որը խիստ է։ արգելվում է բոլոր ՀՏՎ-ների արգելափակումը մահվան ցավի դեպքում: Ստացված պատասխանի հիման վրա կարող եք հասկանալ, որ մեր հարցումը հաջողությամբ մշակվել է:
Որպես լրացուցիչ ստուգում, որ մատակարարի DPI-ն արձագանքում է բաց SNI-ին, որը մենք փոխանցում ենք որպես ծածկույթ, մենք կարող ենք հարցում կատարել rutracker.nl-ին որևէ այլ արգելված ռեսուրսի քողի ներքո, օրինակ՝ մեկ այլ «լավ» հեղեղի հետքեր.
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Սերվերից պատասխան չենք ստանա, քանի որ... մեր հարցումը կարգելափակվի DPI համակարգի կողմից:
Առաջին մասի կարճ եզրակացություն
Այսպիսով, մենք կարողացանք ցուցադրել eSNI-ի ֆունկցիոնալությունը՝ օգտագործելով openssl-ը և curl-ը և փորձարկել eSNI-ի վրա հիմնված տիրույթի ճակատավորման աշխատանքը: Նույն կերպ, մենք կարող ենք հարմարեցնել մեր սիրելի գործիքները, որոնք օգտագործում են openssl գրադարանը՝ այլ տիրույթների «քողի տակ» աշխատելու համար։ Այս մասին ավելի մանրամասն մեր հաջորդ հոդվածներում:
Source: www.habr.com