Cyflwyniad
Mae gan systemau hidlo cynnwys corfforaethol modern gan wneuthurwyr enwog fel Cisco, BlueCoat, FireEye lawer yn gyffredin Γ’'u cymheiriaid mwy pwerus - systemau DPI, sy'n cael eu gweithredu'n weithredol ar lefel genedlaethol. Hanfod gwaith y ddau yw archwilio traffig Rhyngrwyd sy'n dod i mewn ac yn mynd allan ac, yn seiliedig ar restrau du/gwyn, gwneud penderfyniad i wahardd cysylltiad Rhyngrwyd. A chan fod y ddau ohonyn nhw'n dibynnu ar egwyddorion tebyg yn hanfodion eu gwaith, bydd gan y dulliau o'u hosgoi lawer yn gyffredin hefyd.
Un o'r technolegau sy'n eich galluogi i osgoi DPI a systemau corfforaethol yn eithaf effeithiol yw technoleg blaen parth. Ei hanfod yw ein bod yn mynd i adnodd sydd wedi'i rwystro, gan guddio y tu Γ΄l i barth cyhoeddus arall sydd ag enw da, na fydd yn amlwg yn cael ei rwystro gan unrhyw system, er enghraifft google.com.
Mae cryn dipyn o erthyglau eisoes wedi'u hysgrifennu am y dechnoleg hon a llawer o enghreifftiau wedi'u rhoi. Fodd bynnag, mae'r technolegau DNS-over-HTTPS ac amgryptio-SNI poblogaidd a drafodwyd yn ddiweddar, yn ogystal Γ’'r fersiwn newydd o'r protocol TLS 1.3, yn ei gwneud hi'n bosibl ystyried opsiwn arall ar gyfer blaenio parth.
Deall y dechnoleg
Yn gyntaf, gadewch i ni ddiffinio ychydig o gysyniadau sylfaenol fel bod gan bawb ddealltwriaeth o bwy yw pwy a pham mae angen hyn i gyd. Soniasom am fecanwaith eSNI, a chaiff ei weithrediad ei drafod ymhellach. Mae'r mecanwaith eSNI (Dynodiad Enw Gweinyddwr wedi'i amgryptio) yn fersiwn ddiogel o SNI, sydd ar gael ar gyfer protocol TLS 1.3 yn unig. Y prif syniad yw amgryptio, ymhlith pethau eraill, gwybodaeth am ba barth yr anfonir y cais iddo.
Nawr, gadewch i ni edrych ar sut mae'r mecanwaith eSNI yn gweithio'n ymarferol.
Gadewch i ni ddweud bod gennym ni adnodd Rhyngrwyd sy'n cael ei rwystro gan ddatrysiad DPI modern (gadewch i ni gymryd, er enghraifft, y traciwr cenllif enwog rutracker.nl). Pan geisiwn gyrchu gwefan traciwr cenllif, rydym yn gweld bonyn safonol y darparwr yn nodi bod yr adnodd wedi'i rwystro:
Ar wefan RKN mae'r parth hwn wedi'i restru mewn gwirionedd yn y rhestrau stopio:
Pan fyddwch chi'n holi pwy yw, gallwch weld bod y parth ei hun yn "gudd" y tu Γ΄l i'r darparwr cwmwl Cloudflare.
Ond yn wahanol iβr βarbenigwyrβ o RKN, ni wnaeth gweithwyr mwy medrus yn dechnegol o Beeline (neu a ddysgwyd gan brofiad chwerw ein rheolydd enwog) wahardd y wefan yn wirion trwy gyfeiriad IP, ond ychwanegodd yr enw parth at y rhestr stopio. Gallwch chi wirio hyn yn hawdd os edrychwch chi ar ba barthau eraill sydd wedi'u cuddio y tu Γ΄l i'r un cyfeiriad IP, ymweld ag un ohonyn nhw a gweld nad yw mynediad wedi'i rwystro:
Sut mae hyn yn digwydd? Sut mae DPI y darparwr yn gwybod pa barth y mae fy mhorwr arno, gan fod pob cyfathrebiad yn digwydd trwy'r protocol https, ac nid ydym wedi sylwi eto ar amnewid tystysgrifau https gan Beeline? A yw'n glirweledydd neu a yw'n cael fy nilyn?
Gadewch i ni geisio ateb y cwestiwn hwn drwy edrych ar y traffig drwy wireshark
Mae'r sgrinlun yn dangos bod y porwr yn gyntaf yn cael cyfeiriad IP y gweinydd trwy DNS, yna mae ysgwyd llaw TCP safonol yn digwydd gyda'r gweinydd cyrchfan, ac yna mae'r porwr yn ceisio sefydlu cysylltiad SSL Γ’'r gweinydd. I wneud hyn, mae'n anfon pecyn SSL Client Hello, sy'n cynnwys enw'r parth ffynhonnell mewn testun clir. Mae gweinydd frontend cloudflare angen y maes hwn er mwyn llwybro'r cysylltiad yn gywir. Dyma lle mae DPI y darparwr yn ein dal ni, gan dorri ein cysylltiad. Ar yr un pryd, nid ydym yn derbyn unrhyw bonyn gan y darparwr, ac rydym yn gweld y gwall porwr safonol fel pe bai'r wefan yn anabl neu ddim yn gweithio:
Nawr, gadewch i ni alluogi'r mecanwaith eSNI yn y porwr, fel yr ysgrifennwyd yn y cyfarwyddiadau ar gyfer :
I wneud hyn rydym yn agor tudalen ffurfweddu Firefox am: ffurfweddu ac actifadu'r gosodiadau canlynol:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Ar Γ΄l hyn, byddwn yn gwirio bod y gosodiadau'n gweithio'n gywir ar wefan cloudflare. a gadewch i ni roi cynnig ar y tric gyda'n traciwr torrent eto.
Voila. Agorodd ein hoff draciwr heb unrhyw weinyddion VPN na dirprwy. Edrychwn yn awr ar y domen draffig yn wireshark i weld beth ddigwyddodd.
Y tro hwn, nid yw'r pecyn hello cleient ssl yn cynnwys y parth cyrchfan yn benodol, ond yn lle hynny, ymddangosodd maes newydd yn y pecyn - encrypted_server_name - dyma lle mae gwerth rutracker.nl wedi'i gynnwys, a dim ond gweinydd blaen cloudflare all ddadgryptio hyn maes. Ac os felly, yna nid oes gan y darparwr DPI unrhyw ddewis ond golchi ei ddwylo a chaniatΓ‘u traffig o'r fath. Nid oes unrhyw opsiynau eraill gydag amgryptio.
Felly, fe wnaethom edrych ar sut mae'r dechnoleg yn gweithio yn y porwr. Nawr, gadewch i ni geisio ei gymhwyso i bethau mwy penodol a diddorol. Ac yn gyntaf, byddwn yn dysgu'r un cyrl i ddefnyddio eSNI i weithio gyda TLS 1.3, ac ar yr un pryd byddwn yn gweld sut mae'r blaen parth sy'n seiliedig ar eSNI ei hun yn gweithio.
Parth o flaen eSNI
Oherwydd y ffaith bod Curl yn defnyddio'r llyfrgell openssl safonol i gysylltu trwy'r protocol https, yn gyntaf oll mae angen i ni ddarparu cefnogaeth eSNI yno. Nid oes unrhyw gefnogaeth eSNI yn y prif ganghennau openssl eto, felly mae angen inni lawrlwytho cangen openssl arbennig, ei llunio a'i gosod.
Rydym yn clonio'r ystorfa o GitHub ac yn llunio fel arfer:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Nesaf, rydym yn clonio'r ystorfa gyda curl ac yn ffurfweddu ei gasgliad gan ddefnyddio ein llyfrgell openssl a luniwyd:
$ 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
Yma mae'n bwysig nodi'n gywir yr holl gyfeiriaduron lle mae openssl wedi'i leoli (yn ein hachos ni, dyma /opt/openssl/) a gwneud yn siΕ΅r bod y broses ffurfweddu yn mynd drwodd heb wallau.
Os bydd y ffurfweddiad yn llwyddiannus, fe welwn y llinell:
RHYBUDD: esni ESNI wedi'i alluogi ond wedi'i farcio ARBROFOL. Defnyddiwch yn ofalus!
$ makeAr Γ΄l adeiladu'r pecyn yn llwyddiannus, byddwn yn defnyddio ffeil bash arbennig o openssl i ffurfweddu a rhedeg curl. Gadewch i ni ei gopΓ―o i'r cyfeiriadur gyda curl er hwylustod:
cp /opt/openssl/esnistuff/curl-esni a gwneud cais https prawf i'r gweinydd cloudflare, tra'n recordio pecynnau DNS a TLS yn Wireshark ar yr un pryd.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Yn ymateb y gweinydd, yn ogystal Γ’ llawer o wybodaeth dadfygio gan openssl a curl, byddwn yn derbyn ymateb HTTP gyda chod 301 o 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/
sy'n dangos bod ein cais wedi'i gyflwyno'n llwyddiannus i'r gweinydd cyrchfan, ei glywed a'i brosesu.
Nawr, gadewch i ni edrych ar y domen draffig yn wireshark, h.y. yr hyn a welodd DPI y darparwr yn yr achos hwn.
Gellir gweld bod Curl wedi troi at y gweinydd DNS yn gyntaf am allwedd eSNI cyhoeddus ar gyfer y gweinydd cloudflare - cais DNS TXT i _esni.cloudflare.com (pecyn Rhif 13). Yna, gan ddefnyddio'r llyfrgell openssl, anfonodd Curl gais TLS 1.3 at y gweinydd cloudflare lle cafodd y maes SNI ei amgryptio gyda'r allwedd gyhoeddus a gafwyd yn y cam blaenorol (pecyn #22). Ond, yn ogystal Γ’'r maes eSNI, roedd y pecyn SSL-helo hefyd yn cynnwys maes gyda'r SNI arferol - agored, y gallwn ei nodi mewn unrhyw drefn (yn yr achos hwn - ).
Ni chymerwyd y maes SNI agored hwn i ystyriaeth mewn unrhyw ffordd wrth ei brosesu gan weinyddion cloudflare a dim ond mwgwd ar gyfer DPI y darparwr oedd yn gwasanaethu. Derbyniodd y gweinydd cloudflare ein pecyn ssl-hello, dadgryptio'r eSNI, tynnu'r SNI gwreiddiol oddi yno a'i brosesu fel pe na bai dim wedi digwydd (gwnaeth popeth yn union fel y cynlluniwyd wrth ddatblygu eSNI).
Yr unig beth y gellir ei ddal yn yr achos hwn o safbwynt DPI yw'r cais DNS sylfaenol i _esni.cloudflare.com. Ond fe wnaethom agor y cais DNS yn unig i ddangos sut mae'r mecanwaith hwn yn gweithio o'r tu mewn.
I dynnu'r ryg allan o dan DPI o'r diwedd, rydym yn defnyddio'r mecanwaith DNS-over-HTTPS a grybwyllwyd eisoes. Ychydig o esboniad - mae DOH yn brotocol sy'n eich galluogi i amddiffyn rhag ymosodiad dyn-yn-y-canol trwy anfon cais DNS dros HTTPS.
Gadewch i ni weithredu'r cais eto, ond y tro hwn byddwn yn derbyn allweddi eSNI cyhoeddus trwy'r protocol https, nid DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Dangosir y dymp traffig cais yn y sgrinlun isod:
Gellir gweld bod Curl yn cyrchu'r gweinydd mozilla.cloudflare-dns.com yn gyntaf trwy'r protocol DoH (cysylltiad https Γ’ gweinydd 104.16.249.249) i gael ganddynt werthoedd allweddi cyhoeddus ar gyfer amgryptio SNI, ac yna i'r cyrchfan gweinydd, yn cuddio y tu Γ΄l i'r parth .
Yn ogystal Γ’'r Datrysydd DoH uchod mozilla.cloudflare-dns.com, gallwn ddefnyddio gwasanaethau DoH poblogaidd eraill, er enghraifft, gan y gorfforaeth ddrwg enwog.
Gadewch i ni redeg yr ymholiad canlynol:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/A chawn yr ateb:
< 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
Yn yr achos hwn, fe wnaethom droi at y gweinydd rutracker.nl sydd wedi'i rwystro, gan ddefnyddio'r DoH resolver dns.google (nid oes teipio yma, nawr mae gan y gorfforaeth enwog ei pharth lefel gyntaf ei hun) a gorchuddio ein hunain Γ’ pharth arall, sydd yn hollol gwaharddedig i bob DPI rwystro o dan boen marwolaeth. Yn seiliedig ar yr ymateb a dderbyniwyd, gallwch ddeall bod ein cais wedi'i brosesu'n llwyddiannus.
Fel gwiriad ychwanegol bod DPI y darparwr yn ymateb i'r SNI agored, yr ydym yn ei drosglwyddo fel clawr, gallwn wneud cais i rutracker.nl dan gochl rhyw adnodd gwaharddedig arall, er enghraifft, traciwr cenllif βdaβ arall:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Ni fyddwn yn derbyn ymateb gan y gweinydd, oherwydd... bydd ein cais yn cael ei rwystro gan y system DPI.
Casgliad byr i'r rhan gyntaf
Felly, roeddem yn gallu dangos ymarferoldeb eSNI gan ddefnyddio openssl a curl a phrofi gweithrediad blaen parth yn seiliedig ar eSNI. Yn yr un modd, gallwn addasu ein hoff offer sy'n defnyddio'r llyfrgell openssl i weithio βdan gochlβ parthau eraill. Mwy o fanylion am hyn yn ein herthyglau nesaf.
Ffynhonnell: hab.com