Lénsviðmið byggt á TLS 1.3

Inngangur

Nútíma innihaldssíukerfi fyrirtækja frá svo þekktum framleiðendum eins og Cisco, BlueCoat, FireEye eiga töluvert sameiginlegt með öflugri hliðstæða þeirra - DPI kerfi, sem eru virkir innleiddir á landsvísu. Kjarninn í starfi beggja er að skoða inn- og útleið á netið og, út frá svart/hvítum listum, taka ákvörðun um að banna nettenginguna. Og þar sem báðir reiða sig á svipuð lögmál í grundvallaratriðum í starfi sínu, munu aðferðirnar til að sniðganga þær einnig eiga margt sameiginlegt.

Ein af þeim tækni sem gerir þér kleift að komast framhjá bæði DPI og fyrirtækjakerfum er lénstækni. Kjarni þess er að við förum í lokaða auðlind, felum okkur á bak við annað opinbert lén með gott orðspor, sem augljóslega verður ekki lokað af neinu kerfi, til dæmis google.com.

Nú þegar hafa verið skrifaðar töluvert margar greinar um þessa tækni og mörg dæmi hafa verið gefin. Hins vegar, vinsæla og nýlega rædda DNS-yfir-HTTPS og dulkóðaða-SNI tæknin, sem og nýja útgáfan af TLS 1.3 samskiptareglum, gera það mögulegt að íhuga annan valkost fyrir lénsframsetningu.

Að skilja tæknina

Í fyrsta lagi skulum við skilgreina smá grunnhugtök þannig að allir hafi skilning á hver er hver og hvers vegna allt þetta er þörf. Við nefndum eSNI vélbúnaðinn, en rekstur hans verður ræddur frekar. eSNI (dulkóðuð Server Name Indication) vélbúnaður er örugg útgáfa af SNI, aðeins fáanleg fyrir TLS 1.3 samskiptareglur. Meginhugmyndin er að dulkóða meðal annars upplýsingar um á hvaða lén beiðnin er send.

Nú skulum við skoða hvernig eSNI vélbúnaðurinn virkar í reynd.

Segjum að við séum með internetauðlind sem er læst af nútíma DPI lausn (tökum til dæmis hinn fræga torrent tracker rutracker.nl). Þegar við reynum að fá aðgang að vefsíðu torrent rekja spor einhvers sjáum við staðalstubb veitunnar sem gefur til kynna að auðlindin sé læst:

Á vefsíðu RKN er þetta lén í raun skráð á stöðvunarlistum:

Þegar þú spyrð í whois geturðu séð að lénið sjálft er „falið“ á bak við skýjaveituna Cloudflare.

En ólíkt „sérfræðingunum“ frá RKN, þá bönnuðu tæknilega kunnátta starfsmenn frá Beeline (eða kennt af biturri reynslu fræga eftirlitsstofunnar okkar) síðuna ekki heimskulega eftir IP tölu, heldur bættu léninu við stöðvunarlistann. Þú getur auðveldlega staðfest þetta ef þú skoðar hvaða önnur lén eru falin á bak við sömu IP tölu, heimsækir eitt þeirra og sérð að aðgangur er ekki lokaður:

Hvernig gerist þetta? Hvernig veit DPI þjónustuveitunnar á hvaða léni vafrinn minn er, þar sem öll samskipti eiga sér stað í gegnum https samskiptareglur og við höfum ekki enn tekið eftir því að https vottorðum hefur verið skipt út frá Beeline? Er hann skyggn eða er verið að elta mig?

Við skulum reyna að svara þessari spurningu með því að skoða umferðina í gegnum wireshark

Skjáskotið sýnir að fyrst fær vafrinn IP-tölu netþjónsins í gegnum DNS, síðan kemur venjulegt TCP handtak við áfangaþjóninn og síðan reynir vafrinn að koma á SSL tengingu við netþjóninn. Til að gera þetta sendir það SSL Client Hello pakka, sem inniheldur nafn upprunalénsins í skýrum texta. Þessi reitur er nauðsynlegur af cloudflare framendaþjóninum til að beina tengingunni rétt. Þetta er þar sem veitandinn DPI grípur okkur og slítur tengingu okkar. Á sama tíma fáum við enga stubba frá þjónustuveitunni og við sjáum venjulega vafravillu eins og vefsvæðið sé óvirkt eða einfaldlega virki ekki:

Nú skulum við virkja eSNI vélbúnaðinn í vafranum, eins og skrifað er í leiðbeiningunum fyrir Firefox :
Til að gera þetta opnum við Firefox stillingarsíðuna um: config og virkjaðu eftirfarandi stillingar:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

Eftir þetta munum við athuga hvort stillingarnar virka rétt á cloudflare vefsíðunni. tengill og við skulum reyna bragðið með torrent rekja spor einhvers okkar aftur.

Voila. Uppáhalds rekja spor einhvers opnaði án VPN eða proxy netþjóna. Við skulum nú líta á umferðarhauginn í wireshark til að sjá hvað gerðist.

Að þessu sinni inniheldur ssl client hello pakkinn ekki beinlínis áfangalénið, en í staðinn birtist nýr reitur í pakkanum - encrypted_server_name - þetta er þar sem gildi rutracker.nl er innifalið og aðeins cloudflare framendaþjónninn getur afkóðað þetta sviði. Og ef svo er, þá hefur veitandinn DPI ekkert val en að þvo hendur sínar og leyfa slíka umferð. Það eru engir aðrir valkostir með dulkóðun.

Svo skoðuðum við hvernig tæknin virkar í vafranum. Nú skulum við reyna að nota það á sértækari og áhugaverðari hluti. Og fyrst munum við kenna sömu krullunni að nota eSNI til að vinna með TLS 1.3, og á sama tíma munum við sjá hvernig eSNI-undirstaða lénsframhliðin virkar.

Domain fronting með eSNI

Vegna þess að curl notar staðlaða openssl bókasafnið til að tengjast í gegnum https samskiptareglur, þá þurfum við fyrst og fremst að veita eSNI stuðning þar. Það er enginn eSNI stuðningur í openssl master útibúunum ennþá, svo við þurfum að hlaða niður sérstöku openssl útibúi, setja saman og setja það upp.

Við klónum geymsluna frá GitHub og tökum saman eins og venjulega:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

Næst klónum við geymsluna með krulla og stillum samantekt hennar með því að nota uppsett openssl bókasafnið okkar:

$ 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

Hér er mikilvægt að tilgreina rétt allar möppur þar sem openssl er staðsett (í okkar tilfelli er þetta /opt/openssl/) og ganga úr skugga um að stillingarferlið gangi í gegn án villna.

Ef uppsetningin tekst, munum við sjá línuna:

VIÐVÖRUN: esni ESNI virkt en merkt EXPERIMENTAL. Notaðu með varúð!

$ make

Eftir að hafa búið til pakkann munum við nota sérstaka bash skrá frá openssl til að stilla og keyra curl. Við skulum afrita það í möppuna með krullu til hægðarauka:

cp /opt/openssl/esnistuff/curl-esni 

og gerðu https-prófsbeiðni til cloudflare netþjónsins, en taka samtímis upp DNS og TLS pakka í Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

Í svari netþjónsins, auk mikilla villuupplýsinga frá openssl og curl, munum við fá HTTP svar með kóða 301 frá 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/

sem gefur til kynna að beiðni okkar hafi tekist að afhenda áfangaþjóninn, heyrt og afgreidd.

Lítum nú á umferðarhauginn í wireshark, þ.e. það sem veitandinn DPI sá í þessu tilviki.

Það sést að krullan sneri fyrst að DNS þjóninum fyrir opinberan eSNI lykil fyrir cloudflare þjóninn - TXT DNS beiðni til _esni.cloudflare.com (pakki nr. 13). Síðan, með því að nota openssl bókasafnið, sendi curl TLS 1.3 beiðni til cloudflare netþjónsins þar sem SNI reiturinn var dulkóðaður með opinbera lyklinum sem fékkst í fyrra skrefi (pakki #22). En til viðbótar við eSNI reitinn innihélt SSL-halló pakkinn einnig reit með venjulegu - opnu SNI, sem við getum tilgreint í hvaða röð sem er (í þessu tilfelli - www.hello-rkn.ru).

Ekki var tekið tillit til þessa opna SNI sviðs á nokkurn hátt þegar hann var unninn af cloudflare netþjónum og þjónaði aðeins sem gríma fyrir DPI veitandann. Cloudflare þjónninn fékk ssl-hello pakkann okkar, afkóðaði eSNI, dró upprunalega SNI þaðan út og vann það eins og ekkert hefði í skorist (hann gerði allt nákvæmlega eins og áætlað var þegar eSNI þróaðist).

Það eina sem hægt er að ná í þessu tilfelli frá DPI sjónarhóli er aðal DNS beiðnin til _esni.cloudflare.com. En við gerðum DNS beiðnina opna aðeins til að sýna hvernig þetta kerfi virkar innan frá.

Til að draga teppið loksins úr undir DPI notum við DNS-over-HTTPS vélbúnaðinn sem áður hefur verið nefndur. Smá útskýring - DOH er siðareglur sem gerir þér kleift að verjast mann-í-miðju árás með því að senda DNS beiðni yfir HTTPS.

Við skulum framkvæma beiðnina aftur, en að þessu sinni munum við fá opinbera eSNI lykla í gegnum https samskiptareglur, ekki DNS:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

Umferðarþurrðbeiðnin er sýnd á skjámyndinni hér að neðan:

Það má sjá að curl fer fyrst inn á mozilla.cloudflare-dns.com netþjóninn í gegnum DoH siðareglur (https tenging við netþjón 104.16.249.249) til að fá frá þeim gildi opinberra lykla fyrir SNI dulkóðun og síðan á áfangastað þjónn, felur sig á bak við lénið www.hello-rkn.ru.

Til viðbótar við ofangreinda DoH lausnarmann mozilla.cloudflare-dns.com, getum við notað aðra vinsæla DoH þjónustu, til dæmis frá hinu fræga illa fyrirtæki.
Við skulum keyra eftirfarandi fyrirspurn:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Og við fáum svarið:

< 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

Í þessu tilviki snerum við okkur að læsta rutracker.nl þjóninum með því að nota DoH lausnarann ​​dns.google (það er engin innsláttarvilla hér, nú er hið fræga fyrirtæki með sitt eigið fyrsta stigs lén) og huldum okkur með öðru léni, sem er stranglega bannað fyrir alla DPI að loka vegna sársauka dauða. Byggt á svarinu sem barst geturðu skilið að beiðni okkar var afgreidd með góðum árangri.

Til viðbótar við athugun á því að DPI þjónustuveitunnar bregðist við opnu SNI, sem við sendum sem hlíf, getum við lagt fram beiðni til rutracker.nl undir því yfirskini að einhver önnur bönnuð auðlind sé, til dæmis annar „góður“ straumrekja:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Við munum ekki fá svar frá þjóninum, vegna þess að... beiðni okkar verður lokað af DPI kerfinu.

Stutt ályktun að fyrri hluta

Þannig að við gátum sýnt fram á virkni eSNI með því að nota openssl og curl og prófað virkni lénsframhliða byggt á eSNI. Á sama hátt getum við aðlagað uppáhalds verkfærin okkar sem nota openssl bókasafnið til að vinna „undir skjóli“ annarra léna. Nánari upplýsingar um þetta í næstu greinum okkar.

Heimild: www.habr.com