Uwekaji mbele wa kikoa kulingana na TLS 1.3

Utangulizi

Mifumo ya kisasa ya kuchuja yaliyomo kwenye kampuni kutoka kwa watengenezaji mashuhuri kama Cisco, BlueCoat, FireEye ina mambo mengi sawa na wenzao wenye nguvu zaidi - mifumo ya DPI, ambayo inatekelezwa kikamilifu katika kiwango cha kitaifa. Kiini cha kazi ya wote wawili ni kukagua trafiki ya mtandao inayoingia na kutoka na, kulingana na orodha nyeusi/nyeupe, kufanya uamuzi wa kupiga marufuku muunganisho wa Mtandao. Na kwa kuwa wote wawili wanategemea kanuni zinazofanana katika misingi ya kazi zao, njia za kuziepuka pia zitakuwa na mengi sawa.

Mojawapo ya teknolojia ambayo hukuruhusu kupita kwa ufanisi mifumo yote miwili ya DPI na ushirika ni teknolojia ya kuelekeza kikoa. Kiini chake ni kwamba tunaenda kwenye rasilimali iliyozuiwa, tukijificha nyuma ya kikoa kingine, cha umma na sifa nzuri, ambayo ni wazi haitazuiwa na mfumo wowote, kwa mfano google.com.

Nakala nyingi tayari zimeandikwa juu ya teknolojia hii na mifano mingi imetolewa. Hata hivyo, teknolojia maarufu na zilizojadiliwa hivi karibuni za DNS-over-HTTPS na encrypted-SNI, pamoja na toleo jipya la itifaki ya TLS 1.3, hufanya iwezekane kuzingatia chaguo jingine la kuweka mbele kikoa.

Kuelewa teknolojia

Kwanza, hebu tufafanue dhana kidogo za msingi ili kila mtu awe na ufahamu wa nani ni nani na kwa nini hii yote inahitajika. Tulitaja utaratibu wa eSNI, uendeshaji ambao utajadiliwa zaidi. Utaratibu wa eSNI (Ashirio la Jina la Seva iliyosimbwa kwa njia fiche) ni toleo salama la SNI, linapatikana kwa itifaki ya TLS 1.3 pekee. Wazo kuu ni kusimba, kati ya mambo mengine, habari kuhusu kikoa ambacho ombi hutumwa.

Sasa hebu tuangalie jinsi utaratibu wa eSNI unavyofanya kazi kwa vitendo.

Hebu sema tuna rasilimali ya mtandao ambayo imefungwa na ufumbuzi wa kisasa wa DPI (hebu tuchukue, kwa mfano, tracker maarufu ya torrent rutracker.nl). Tunapojaribu kufikia tovuti ya kifuatiliaji cha mkondo, tunaona kipengee cha kawaida cha mtoa huduma kinachoonyesha kuwa rasilimali imezuiwa:

Kwenye tovuti ya RKN kikoa hiki kimeorodheshwa katika orodha za vituo:

Unapouliza ni nani, unaweza kuona kwamba kikoa chenyewe "kimefichwa" nyuma ya mtoa huduma wa wingu Cloudflare.

Lakini tofauti na "wataalamu" kutoka RKN, wafanyakazi werevu zaidi wa kitaalamu kutoka Beeline (au wale waliofundishwa na uzoefu mchungu wa mdhibiti wetu maarufu) hawakupiga marufuku tovuti hiyo kwa anwani ya IP tu, bali waliiongeza kwenye orodha ya vituo haswa. jina la kikoaHili linaweza kuthibitishwa kwa urahisi kwa kuangalia ni vikoa vipi vingine vilivyofichwa nyuma ya hiki hiki. Anwani ya IP, tembelea mmoja wao na uone kwamba ufikiaji haujazuiwa:

Je, hii hutokeaje? Je, DPI ya mtoa huduma inajua kikoa kipi kimewashwa kivinjari changu, kwa kuwa mawasiliano yote yanatokea kupitia itifaki ya https, na bado hatujaona uingizwaji wa vyeti vya https kutoka Beeline? Je, yeye ni mkali au ninafuatwa?

Wacha tujaribu kujibu swali hili kwa kuangalia trafiki kupitia wireshark

Picha ya skrini inaonyesha kwamba kivinjari hupata anwani ya IP ya seva kwanza kupitia DNS, kisha kushikana mkono kwa kawaida kwa TCP na seva ya mwisho hutokea, na kisha kivinjari hujaribu kuanzisha muunganisho wa SSL kwenye seva. Ili kufanya hivyo, hutuma pakiti. SSL Mteja Hujambo, ambayo ina jina la kikoa chanzo katika maandishi wazi. Sehemu hii inahitajika na seva ya mbele ya Cloudflare ili kuelekeza muunganisho kwa usahihi. Hapa ndipo DPI ya Mtoa Huduma za Intaneti inatupata, ikikata muunganisho wetu. Hata hivyo, hatupokei kijitabu chochote kutoka kwa Mtoa Huduma za Intaneti na kuona hitilafu ya kivinjari cha kawaida, kana kwamba tovuti haifanyi kazi au haifanyi kazi:

Sasa wacha tuwashe utaratibu wa eSNI kwenye kivinjari, kama ilivyoandikwa katika maagizo ya Firefox :
Ili kufanya hivyo tunafungua ukurasa wa usanidi wa Firefox kuhusu: config na uamilishe mipangilio ifuatayo:

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

Baada ya hayo, tutaangalia kuwa mipangilio inafanya kazi kwa usahihi kwenye tovuti ya cloudflare. kiungo na tujaribu hila na kifuatiliaji chetu cha kijito tena.

Voila. Kifuatiliaji chetu tunachopenda kilifunguliwa bila VPN au seva mbadala. Wacha sasa tuangalie dampo la trafiki kwenye wireshark ili kuona nini kilifanyika.

Wakati huu, kifurushi cha ssl hujambo cha mteja hakina kikoa lengwa kwa uwazi, lakini badala yake, sehemu mpya ilionekana kwenye kifurushi - encrypted_server_name - hapa ndipo thamani ya rutracker.nl inapatikana, na ni seva ya mbele ya cloudflare pekee inayoweza kusimbua hii. shamba. Na ikiwa ni hivyo, basi DPI ya mtoa huduma hana chaguo ila kuosha mikono yake na kuruhusu trafiki hiyo. Hakuna chaguzi zingine zilizo na usimbaji fiche.

Kwa hiyo, tuliangalia jinsi teknolojia inavyofanya kazi katika kivinjari. Sasa hebu tujaribu kuitumia kwa mambo maalum zaidi na ya kuvutia. Na kwanza, tutafundisha curl sawa kutumia eSNI kufanya kazi na TLS 1.3, na wakati huo huo tutaona jinsi kikoa cha msingi cha eSNI kinavyofanya kazi.

Mbele ya kikoa na eSNI

Kutokana na ukweli kwamba curl hutumia maktaba ya kawaida ya openssl kuunganisha kupitia itifaki ya https, kwanza kabisa tunahitaji kutoa usaidizi wa eSNI huko. Hakuna usaidizi wa eSNI katika matawi makuu ya openssl bado, kwa hivyo tunahitaji kupakua tawi maalum la openssl, kukusanya na kuiweka.

Tunatengeneza hazina kutoka GitHub na kukusanya kama kawaida:

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

$ make
$ cd esnistuff
$ make

Ifuatayo, tunaunganisha hazina na curl na kusanidi mkusanyiko wake kwa kutumia maktaba yetu ya openssl iliyojumuishwa:

$ 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

Hapa ni muhimu kutaja kwa usahihi saraka zote ambapo openssl iko (kwa upande wetu, hii ni /opt/openssl/) na uhakikishe kuwa mchakato wa usanidi unapita bila makosa.

Ikiwa usanidi umefanikiwa, tutaona mstari:

ONYO: esni ESNI imewezeshwa lakini imetiwa alama ya MAJARIBIO. Tumia kwa tahadhari!

$ make

Baada ya kuunda kifurushi kwa mafanikio, tutatumia faili maalum ya bash kutoka openssl ili kusanidi na kukimbia curl. Wacha tuinakili kwenye saraka na curl kwa urahisi:

cp /opt/openssl/esnistuff/curl-esni 

na ufanye jaribio la ombi la https kwa seva ya cloudflare, huku ukirekodi kwa wakati mmoja pakiti za DNS na TLS katika Wireshark.

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

Katika jibu la seva, pamoja na maelezo mengi ya utatuzi kutoka kwa openssl na curl, tutapokea jibu la HTTP na msimbo 301 kutoka kwa 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/

ambayo inaonyesha kuwa ombi letu liliwasilishwa kwa seva lengwa, lilisikika na kuchakatwa.

Sasa hebu tuangalie dampo la trafiki katika wireshark, i.e. kile DPI ya mtoa huduma iliona katika kesi hii.

Inaweza kuonekana kuwa curl kwanza iligeuka kwenye seva ya DNS kwa ufunguo wa umma wa eSNI kwa seva ya cloudflare - ombi la TXT DNS kwa _esni.cloudflare.com (mfuko No. 13). Kisha, kwa kutumia maktaba ya openssl, curl ilituma ombi la TLS 1.3 kwa seva ya cloudflare ambayo uwanja wa SNI ulisimbwa kwa njia fiche na ufunguo wa umma uliopatikana katika hatua ya awali (pakiti # 22). Lakini, pamoja na uwanja wa eSNI, pakiti ya SSL-hello pia ilijumuisha shamba na kawaida - SNI wazi, ambayo tunaweza kutaja kwa mpangilio wowote (katika kesi hii - www.hello-rkn.ru).

Sehemu hii ya wazi ya SNI haikuzingatiwa kwa njia yoyote ilipochakatwa na seva za cloudflare na ilitumika tu kama kinyago kwa DPI ya mtoa huduma. Seva ya cloudflare ilipokea pakiti yetu ya ssl-hello, ikasimbua eSNI, ikatoa SNI asili kutoka hapo na kuichakata kana kwamba hakuna kilichotokea (ilifanya kila kitu haswa jinsi ilivyopangwa wakati wa kutengeneza eSNI).

Kitu pekee ambacho kinaweza kupatikana katika kesi hii kutoka kwa mtazamo wa DPI ni ombi la msingi la DNS kwa _esni.cloudflare.com. Lakini tulifungua ombi la DNS ili tu kuonyesha jinsi utaratibu huu unavyofanya kazi kutoka ndani.

Ili hatimaye kuvuta rug kutoka chini ya DPI, tunatumia utaratibu uliotajwa tayari wa DNS-over-HTTPS. Maelezo kidogo - DOH ni itifaki inayokuruhusu kujilinda dhidi ya shambulio la mtu wa kati kwa kutuma ombi la DNS kupitia HTTPS.

Wacha tutekeleze ombi tena, lakini wakati huu tutapokea funguo za umma za eSNI kupitia itifaki ya https, sio DNS:

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

Utupaji wa ombi la trafiki unaonyeshwa kwenye picha ya skrini hapa chini:

Inaweza kuonekana kuwa curl kwanza hupata seva ya mozilla.cloudflare-dns.com kupitia itifaki ya DoH (uunganisho wa https kwa seva 104.16.249.249) ili kupata kutoka kwao maadili ya funguo za umma kwa usimbaji fiche wa SNI, na kisha kwa marudio. seva, kujificha nyuma ya kikoa www.hello-rkn.ru.

Kando na kisuluhishi cha DoH hapo juu mozilla.cloudflare-dns.com, tunaweza kutumia huduma zingine maarufu za DoH, kwa mfano, kutoka kwa shirika maarufu la uovu.
Wacha tuendeshe swali lifuatalo:

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

Na tunapata jibu:

< 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

Katika kesi hii, tuligeukia seva ya rutracker.nl iliyozuiwa, kwa kutumia DoH solver dns.google (hakuna typo hapa, sasa shirika maarufu lina kikoa chake cha ngazi ya kwanza) na tukajifunika na kikoa kingine, ambacho ni madhubuti. marufuku kwa DPI zote kuzuia chini ya maumivu ya kifo. Kulingana na jibu lililopokelewa, unaweza kuelewa kuwa ombi letu lilichakatwa kwa ufanisi.

Kama hundi ya ziada kuwa DPI ya mtoa huduma inajibu SNI iliyo wazi, ambayo tunasambaza kama jalada, tunaweza kutuma ombi kwa rutracker.nl chini ya kivuli cha rasilimali nyingine iliyopigwa marufuku, kwa mfano, tracker nyingine "nzuri" ya mkondo:

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

Hatutapokea jibu kutoka kwa seva, kwa sababu... ombi letu litazuiwa na mfumo wa DPI.

Hitimisho fupi la sehemu ya kwanza

Kwa hivyo, tuliweza kuonyesha utendakazi wa eSNI kwa kutumia openssl na curl na kujaribu utendakazi wa kuweka mbele kikoa kulingana na eSNI. Kwa njia hiyo hiyo, tunaweza kurekebisha zana zetu tunazopenda zinazotumia maktaba ya openssl kufanya kazi "chini ya kivuli" cha vikoa vingine. Maelezo zaidi kuhusu hili katika makala zetu zifuatazo.

Chanzo: mapenzi.com