Pêşiya domainê li ser bingeha TLS 1.3

Pîrozbahiyê

Pêşiya domainê li ser bingeha TLS 1.3
Pergalên fîlterkirina naveroka pargîdanî ya nûjen ji hilberînerên navdar ên wekî Cisco, BlueCoat, FireEye bi hevpîşeyên wan ên bihêztir - pergalên DPI-yê, yên ku di asta neteweyî de bi rengek çalak têne bicîh kirin, pir hevpar in. Esasê xebata her duyan jî kontrolkirina seyrûsefera Înternetê ya hatinî û derketinê ye û, li ser bingeha navnîşên reş/spî, biryarek qedexekirina pêwendiya Înternetê ye. Û ji ber ku her du jî di bingehên xebata xwe de xwe dispêrin prensîbên wekhev, dê awayên dûrxistina wan jî pir hevpar bin.

Yek ji wan teknolojiyên ku destûrê dide we ku hûn hem pergalên DPI û hem jî pergalên pargîdanî bi rengek bi bandor derbas bikin teknolojiya pêş-domînê ye. Esasê wê ev e ku em diçin ser çavkaniyek astengkirî, li pişta din, qada gelemperî ya bi navûdengek baş vedişêrin, ku eşkere ye ku dê ji hêla ti pergalê ve neyê asteng kirin, mînakî google.com.

Jixwe gelek gotar li ser vê teknolojiyê hatine nivîsandin û gelek mînak hatine dayîn. Lêbelê, teknolojiyên DNS-ser-HTTPS û şîfrekirî-SNI-yên populer û nû hatine nîqaş kirin, û her weha guhertoya nû ya protokola TLS 1.3, dihêle ku meriv vebijarkek din ji bo pêşgotina domainê bifikire.

Têgihiştina teknolojiyê

Pêşî, bila em piçûkek têgehên bingehîn diyar bikin da ku her kes fêm bike ka kî kî ye û çima ev hemî hewce ne. Me behsa mekanîzmaya eSNI kir, ku operasyona wê dê bêtir were nîqaş kirin. Mekanîzmaya eSNI (Nîşandana Navê Pêşkêşkara şîfrekirî) guhertoyek ewledar a SNI ye, tenê ji bo protokola TLS 1.3 heye. Fikra sereke şîfrekirina, di nav tiştên din de, agahdariya li ser kîjan domainê daxwaz tê şandin e.

Naha em binihêrin ka mekanîzmaya eSNI di pratîkê de çawa dixebite.

Ka em bibêjin çavkaniyek Înternetê me heye ku ji hêla çareseriyek DPI-ya nûjen ve hatî asteng kirin (ka em, mînakî, şopînerê torrentê ya navdar rutracker.nl bigirin). Dema ku em hewl didin ku xwe bigihînin malpera şopînerek torrentê, em stûyê standardê pêşkêşker dibînin ku destnîşan dike ku çavkanî hatî asteng kirin:

Pêşiya domainê li ser bingeha TLS 1.3

Li ser malpera RKN ev domain bi rastî di navnîşên rawestanê de tête navnîş kirin:

Pêşiya domainê li ser bingeha TLS 1.3

Gava ku hûn li whois dipirsin, hûn dikarin bibînin ku domain bixwe li pişt peydakarê ewr Cloudflare "veşartî" ye.

Pêşiya domainê li ser bingeha TLS 1.3

Lê berevajî "pisporên" ji RKN, xebatkarên teknîkî yên jêhatîtir ji Beeline (an jî ji hêla ezmûna tal a sazûmankarê me yê navdar ve hatî fêr kirin) malper bi navnîşana IP-yê bi ehmeqî qedexe nekir, lê navê domainê li navnîşa rawestandinê zêde kir. Hûn dikarin bi hêsanî vê yekê verast bikin ger hûn li çi domên din li pişt heman navnîşana IP-yê veşartî ne, biçin yek ji wan û bibînin ku gihîştin nayê asteng kirin:

Pêşiya domainê li ser bingeha TLS 1.3

Ev çawa dibe? DPI-ya pêşkêşker çawa dizane geroka min li kîjan domainê ye, ji ber ku hemî danûstandin bi protokola https pêk tê, û me hîna guh nedaye cîgirkirina sertîfîkayên https ji Beeline? Ma ew ronakbîr e an ez têm şopandin?

Ka em hewl bidin ku bersiva vê pirsê bidin û li seyrûsefera wireshark mêze bikin

Pêşiya domainê li ser bingeha TLS 1.3

Dîmenê nîşan dide ku pêşî gerok navnîşana IP-ya serverê bi riya DNS-ê distîne, dûv re destanek standard TCP bi servera armancê re çêdibe, û dûv re gerok hewl dide ku têkiliyek SSL bi serverê re saz bike. Ji bo vê yekê, ew pakêtek SSL Client Hello dişîne, ku navê domaina çavkaniyê di nivîsa zelal de vedihewîne. Ev qad ji hêla servera pêşîn a cloudflare ve tê xwestin da ku pêwendiyê bi rêkûpêk rêve bike. Li vir peydaker DPI me digire, têkiliya me dişkîne. Di heman demê de, em ji pêşkêşkarê ti stûyê nagirin, û em xeletiya geroka standard dibînin wekî ku malper neçalak be an bi tenê nexebite:

Pêşiya domainê li ser bingeha TLS 1.3

Naha em mekanîzmaya eSNI di gerokê de çalak bikin, wekî ku di rêwerzan de hatî nivîsandin Firefox :
Ji bo vê yekê em rûpela veavakirina Firefoxê vedikin about: config û mîhengên jêrîn çalak bikin:

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

Piştî vê yekê, em ê kontrol bikin ka mîhengan li ser malpera cloudflare rast dixebitin. link û werin em dîsa bi şopînera xweya torrentê hîleyê biceribînin.

Pêşiya domainê li ser bingeha TLS 1.3

Voila. Şopandina meya bijare bêyî VPN an serverên proxy vekir. Ka em naha li çolê trafîkê li wireshark binêrin da ku bibînin ka çi qewimî.

Pêşiya domainê li ser bingeha TLS 1.3

Vê carê, pakêta hello ya muwekîlê ssl bi eşkere domaina armancê nagire, lê li şûna wê, qadek nû di pakêtê de xuya bû - encrypted_server_name - li vir nirxa rutracker.nl tê de heye, û tenê servera pêşîn a cloudflare dikare vê şîfre bike. erd. Û heke wusa be, wê hingê pêşkêşkarê DPI neçar e ku destên xwe bişo û destûr bide seyrûsefera wusa. Vebijarkên din ên bi şîfrekirinê tune.

Ji ber vê yekê, me nihêrî ka teknolojî di gerokê de çawa dixebite. Naha em hewl bidin ku wê li ser tiştên taybetî û balkêştir bicîh bînin. Û pêşî, em ê heman curl hîn bikin ku eSNI bikar bîne da ku bi TLS 1.3 re bixebite, û di heman demê de em ê bibînin ka pêşgotina domain-based eSNI xwe çawa dixebite.

Pêşiya domainê bi eSNI re

Ji ber ku curl pirtûkxaneya standard openssl bikar tîne da ku bi protokola https ve girêbide, berî her tiştî divê em li wir piştgirîya eSNI peyda bikin. Di şaxên masterê yên openssl de hîn piştgirîya eSNI tune, ji ber vê yekê divê em şaxek taybetî ya openssl dakêşin, berhev bikin û saz bikin.

Em depoyê ji GitHub klon dikin û wekî berê berhev dikin:

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

$ make
$ cd esnistuff
$ make

Dûv re, em depoyê bi curl klon dikin û berhevoka wê bi karanîna pirtûkxaneya xweya openssl ya berhevkirî mîheng dikin:

$ 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

Li vir girîng e ku meriv hemî peldankên ku openssl lê ye rast destnîşan bikin (di rewşa me de, ev /opt/openssl/ ye) û pê ewle bin ku pêvajoya veavakirinê bêyî xeletî derbas dibe.

Ger veavakirin serketî be, em ê rêzê bibînin:

HIŞYARÎ: esni ESNI çalak bû lê CERBÛNÎ hate nîşankirin. Bi hişyariyê bikar bînin!

$ make

Piştî avakirina pakêtê bi serfirazî, em ê pelek bash-a taybetî ya ji openssl bikar bînin da ku curl mîheng bikin û bimeşînin. Ka em ji bo rehetiyê wê li pelrêça bi curl kopî bikin:

cp /opt/openssl/esnistuff/curl-esni 

û ji servera cloudflare re ceribandinek https-ê bikin, di heman demê de pakêtên DNS û TLS li Wireshark tomar bikin.

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

Di bersiva serverê de, ji bilî gelek agahdariya xeletkirinê ji openssl û curl, em ê bersivek HTTP bi koda 301 ji cloudflare bistînin.

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/

ku destnîşan dike ku daxwaza me bi serfirazî gihîştiye servera armancê, hate bihîstin û pêvajo kirin.

Naha em li çolê trafîkê li wireshark binêrin, yanî. di vê rewşê de peydaker DPI çi dît.

Pêşiya domainê li ser bingeha TLS 1.3

Tê dîtin ku curl yekem car zivirî ser servera DNS-ê ji bo mifteyek eSNI ya gelemperî ji bo servera cloudflare - daxwazek TXT DNS ji _esni.cloudflare.com re (pakêta No. 13). Dûv re, bi karanîna pirtûkxaneya openssl, curl daxwazek TLS 1.3 ji servera cloudflare re şand ku tê de qada SNI bi mifteya giştî ya ku di gava berê de hatî peyda kirin (pakêta #22) hatî şîfre kirin. Lê, ji bilî qada eSNI, pakêta SSL-hello di heman demê de zeviyek bi gelemperî - SNI vekirî ye, ku em dikarin bi her rêzê diyar bikin (di vê rewşê de - www.hello-rkn.ru).

Ev qada SNI ya vekirî dema ku ji hêla serverên cloudflare ve hatî hilberandin bi ti awayî nehat hesibandin û tenê ji bo pêşkêşkarê DPI-ê wekî maskek xizmet kir. Pêşkêşkara cloudflare pakêta meya ssl-hello wergirt, eSNI deşîfre kir, SNI-ya orîjînal ji wir derxist û wekî ku tiştek neqewimî pêvajo kir (di dema pêşvebirina eSNI de her tişt tam li gorî plansazkirinê kir).

Tişta ku di vê rewşê de ji nêrînek DPI-ê ve dikare were girtin, daxwaza DNS-ya bingehîn a _esni.cloudflare.com e. Lê me daxwaza DNS-ê tenê vekir da ku nîşan bide ka ev mekanîzma ji hundur çawa dixebite.

Ji bo ku di dawiyê de xalîçeyê ji binê DPI-yê derxin, em mekanîzmaya ku berê hatî destnîşan kirin DNS-ser-HTTPS bikar tînin. Vegotinek piçûk - DOH protokolek e ku dihêle hûn bi şandina daxwazek DNS-ê li ser HTTPS-ê li hember êrişek mêr-di-navîn biparêzin.

Werin em dîsa daxwazê ​​bikin, lê vê carê em ê bi protokola https, ne DNS, bişkojkên eSNI yên giştî bistînin:

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

Daxistina seyrûsefera daxwazê ​​di dîmena jêrîn de tê xuyang kirin:

Pêşiya domainê li ser bingeha TLS 1.3

Tê dîtin ku curl pêşî bi protokola DoH-ê (girêdana https bi server 104.16.249.249) re digihîje servera mozilla.cloudflare-dns.com da ku ji wan re nirxên mifteyên gelemperî ji bo şîfrekirina SNI, û dûv re jî berbi cîhê bigire. server, li pişt domainê vedişêre www.hello-rkn.ru.

Ji bilî çareserkerê DoH-a jorîn mozilla.cloudflare-dns.com, em dikarin karûbarên din ên populer ên DoH-ê bikar bînin, mînakî, ji pargîdaniya xirab a navdar.
Ka em pirsa jêrîn bimeşînin:

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

Û em bersivê bistînin:

< 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

Pêşiya domainê li ser bingeha TLS 1.3

Di vê rewşê de, me zivirî servera rutracker.nl ya astengkirî, bi karanîna çareserkerê DoH dns.google (li vir xeletiyek tîpî tune, naha pargîdaniya navdar xwedan domaina xweya asta yekem e) û xwe bi domainek din vegirt, ku bi tundî ye. qedexe ye ku hemî DPI di bin êşa mirinê de asteng bikin. Li ser bingeha bersiva ku hatî wergirtin, hûn dikarin fêm bikin ku daxwaza me bi serfirazî hate pêvajo kirin.

Wekî kontrolek din ku DPI-ya pêşkêşker bersivê dide SNI-ya vekirî, ya ku em wekî pêvek vediguhezînin, em dikarin di bin navê hin çavkaniyek din a qedexekirî de daxwazek ji rutracker.nl re bikin, mînakî, şopgerek torrentek din a "baş":

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

Em ê bersivek ji serverê wernegirin, ji ber ku ... Daxwaza me dê ji hêla pergala DPI ve were asteng kirin.

Encamek kurt ji beşa yekem re

Ji ber vê yekê, me karîbû fonksiyona eSNI-yê bi karanîna openssl û curl nîşan bidin û xebata pêşgotina domainê li ser bingeha eSNI ceribandin. Bi heman rengî, em dikarin amûrên xweyên bijare yên ku pirtûkxaneya openssl bikar tînin biguhezînin da ku "di bin navê" domên din de bixebitin. Zêdetir hûrgulî li ser vê yekê di gotarên me yên pêş de.

Source: www.habr.com

Add a comment