Ynlieding
Moderne systemen foar filterjen fan bedriuwen fan ynhâld fan sokke ferneamde fabrikanten as Cisco, BlueCoat, FireEye hawwe in protte mienskiplik mei har machtiger tsjinhingers - DPI-systemen, dy't aktyf wurde ymplementearre op nasjonaal nivo. De essinsje fan it wurk fan beide is om ynkommende en útgeande ynternetferkear te ynspektearjen en op basis fan swart/wite listen in beslút te nimmen om de ynternetferbining te ferbieden. En om't se beide yn 'e basis fan har wurk op lyksoartige prinsipes betrouwe, sille de metoaden foar it omgean fan har ek in protte mienskiplik hawwe.
Ien fan 'e technologyen wêrmei jo sawol DPI as bedriuwssystemen frij effektyf kinne omgean is domein-fronting technology. De essinsje dêrfan is dat wy nei in blokkearre boarne gean, ferburgen efter in oar, iepenbier domein mei in goede reputaasje, dy't fansels net blokkearre wurde troch gjin systeem, bygelyks google.com.
In protte artikels binne al skreaun oer dizze technology en in protte foarbylden binne jûn. De populêre en koartlyn besprutsen DNS-over-HTTPS en fersifere-SNI-technologyen, lykas de nije ferzje fan it TLS 1.3-protokol, meitsje it lykwols mooglik om in oare opsje te beskôgjen foar domeinfronting.
Begripe de technology
Lit ús earst in bytsje basisbegripen definiearje, sadat elkenien in begryp hat fan wa is wa en wêrom dit alles nedich is. Wy hawwe it eSNI-meganisme neamd, wêrfan de wurking fierder sil wurde besprutsen. It meganisme fan eSNI (fersifere Server Name Indication) is in feilige ferzje fan SNI, allinich beskikber foar it TLS 1.3-protokol. It haadgedachte is om ûnder oare ynformaasje te fersiferjen oer nei hokker domein it fersyk stjoerd wurdt.
Litte wy no sjen hoe't it eSNI-meganisme yn 'e praktyk wurket.
Litte wy sizze dat wy in ynternetboarne hawwe dy't blokkearre is troch in moderne DPI-oplossing (lite wy bygelyks de ferneamde torrent tracker rutracker.nl nimme). As wy besykje tagong te krijen ta de webside fan in torrent-tracker, sjogge wy de standertstub fan 'e provider dy't oanjout dat de boarne is blokkearre:
Op de RKN-webside stiet dit domein eins yn de stoplisten:
As jo query whois, kinne jo sjen dat it domein sels is "ferburgen" efter de wolk provider Cloudflare.
Mar oars as de "spesjalisten" fan RKN, mear technysk betûfte meiwurkers fan Beeline (of leard troch de bittere ûnderfining fan ús ferneamde regulator) net dom ferbean de side troch IP-adres, mar tafoege de domeinnamme oan de stop list. Jo kinne dit maklik ferifiearje as jo sjogge hokker oare domeinen ferburgen binne efter itselde IP-adres, besykje ien fan har en sjoch dat tagong net blokkearre is:
Hoe komt dit? Hoe wit de DPI fan 'e provider op hokker domein myn blêder is, om't alle kommunikaasje fia it https-protokol plakfynt, en wy hawwe de ferfanging fan https-sertifikaten fan Beeline noch net opmurken? Is hy helderziend of wurdt ik folge?
Litte wy besykje dizze fraach te beantwurdzjen troch te sjen nei it ferkear troch wireshark
De skermôfbylding lit sjen dat de browser earst it IP-adres fan 'e tsjinner krijt fia DNS, dan komt in standert TCP-handshake mei de bestimmingstsjinner, en dan besiket de browser in SSL-ferbining mei de tsjinner op te stellen. Om dit te dwaan, stjoert it in SSL Client Hello-pakket, dat de namme fan it boarnedomein yn dúdlike tekst befettet. Dit fjild is ferplichte troch de cloudflare frontend-tsjinner om de ferbining korrekt te routeren. Dit is wêr't de provider DPI ús fangt, ús ferbining brekt. Tagelyk ûntfange wy gjin stub fan 'e provider, en wy sjogge de standert browserflater as oft de side is útskeakele of gewoan net wurket:
Litte wy no it eSNI-meganisme ynskeakelje yn 'e browser, lykas skreaun yn' e ynstruksjes foar :
Om dit te dwaan iepenje wy de Firefox-konfiguraasjeside oer: config en aktivearje de folgjende ynstellings:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Hjirnei sille wy kontrolearje dat de ynstellingen goed wurkje op 'e cloudflare-webside. en lit ús de trúk nochris besykje mei ús torrent tracker.
Voila. Us favorite tracker iepene sûnder VPN- of proxy-tsjinners. Litte wy no nei de ferkearsdump yn wireshark sjen om te sjen wat der bard is.
Dizze kear befettet it ssl client hello-pakket net eksplisyt it bestimmingsdomein, mar ynstee ferskynde in nij fjild yn it pakket - encrypted_server_name - dit is wêr't de wearde fan rutracker.nl is befette, en allinich de cloudflare frontend-tsjinner kin dit ûntsiferje fjild. En as dat sa is, dan hat de provider DPI gjin oare kar as syn hannen te waskjen en sa'n ferkear ta te stean. D'r binne gjin oare opsjes mei fersifering.
Dat, wy seagen nei hoe't de technology wurket yn 'e browser. Litte wy no besykje it ta te passen op mear spesifike en nijsgjirrige dingen. En earst sille wy deselde krul leare om eSNI te brûken om te wurkjen mei TLS 1.3, en tagelyk sille wy sjen hoe't de eSNI-basearre domeinfronting sels wurket.
Domeinfronting mei eSNI
Fanwegen it feit dat curl de standert openssl-bibleteek brûkt om te ferbinen fia it https-protokol, moatte wy earst eSNI-stipe dêre leverje. D'r is noch gjin eSNI-stipe yn 'e openssl-mastertûken, dus wy moatte in spesjale openssl-tûke downloade, kompilearje en ynstallearje.
Wy klonje it repository fan GitHub en kompilearje lykas gewoanlik:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Folgjende klonen wy it repository mei curl en konfigurearje de kompilaasje mei ús kompilearre openssl-bibleteek:
$ 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
Hjir is it wichtich om alle mappen goed te spesifisearjen wêr't openssl leit (yn ús gefal is dit /opt/openssl/) en soargje derfoar dat it konfiguraasjeproses sûnder flaters trochgiet.
As de konfiguraasje suksesfol is, sille wy de rigel sjen:
WARSKOGING: esni ESNI ynskeakele, mar markearre EXPERIMENTAL. Brûk mei foarsichtigens!
$ makeNei it suksesfolle bouwen fan it pakket, sille wy in spesjale bash-bestân brûke fan openssl om curl te konfigurearjen en út te fieren. Litte wy it foar gemak kopiearje nei de map mei krul:
cp /opt/openssl/esnistuff/curl-esni en meitsje in test https-fersyk oan 'e cloudflare-tsjinner, wylst tagelyk DNS- en TLS-pakketten yn Wireshark opnimme.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Yn 'e tsjinner antwurd, neist in protte debuggen ynformaasje fan openssl en curl, sille wy in HTTP-antwurd krije mei koade 301 fan 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/
wat oanjout dat ús fersyk mei súkses waard levere oan de bestimmingstsjinner, heard en ferwurke.
Litte wy no sjen nei de ferkearshoop yn wireshark, d.w.s. wat de provider DPI seach yn dit gefal.
It kin sjoen wurde dat krul earst draaide nei de DNS tsjinner foar in iepenbiere eSNI kaai foar de cloudflare tsjinner - in TXT DNS fersyk oan _esni.cloudflare.com (pakket No. 13). Dan, mei help fan de openssl-bibleteek, stjoerde curl in TLS 1.3-fersyk nei de cloudflare-tsjinner wêryn it SNI-fjild fersifere waard mei de iepenbiere kaai krigen yn 'e foarige stap (pakket #22). Mar, neist it eSNI-fjild, omfette it SSL-hello-pakket ek in fjild mei de gewoane - iepen SNI, dy't wy yn elke folchoarder kinne oantsjutte (yn dit gefal - ).
Dit iepen SNI-fjild waard op gjin inkelde manier yn rekken brocht by it ferwurkjen troch cloudflare-tsjinners en tsjinne allinich as masker foar de provider DPI. De cloudflare-tsjinner ûntfong ús ssl-hello-pakket, ûntsifere de eSNI, helle dêr de orizjinele SNI út en ferwurke it as wie neat bard (it die alles krekt lykas pland by it ûntwikkeljen fan eSNI).
It ienige ding dat kin wurde fongen yn dit gefal út in DPI eachpunt is de primêre DNS fersyk oan _esni.cloudflare.com. Mar wy makken it DNS-fersyk allinich iepen om te sjen hoe't dit meganisme fan binnen wurket.
Om úteinlik de tapyt ûnder DPI út te lûken, brûke wy it al neamde DNS-over-HTTPS-meganisme. In lytse útlis - DOH is in protokol wêrmei jo te beskermjen tsjin in man-in-the-middle oanfal troch it ferstjoeren fan in DNS-fersyk oer HTTPS.
Litte wy it fersyk nochris útfiere, mar dizze kear krije wy iepenbiere eSNI-kaaien fia it https-protokol, net DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/De ferkearsdump foar fersyk wurdt werjûn yn 'e skermôfbylding hjirûnder:
It kin sjoen wurde dat curl earst tagong hat ta de mozilla.cloudflare-dns.com-tsjinner fia it DoH-protokol (https-ferbining mei server 104.16.249.249) om fan har de wearden fan iepenbiere kaaien foar SNI-fersifering te krijen, en dan nei de bestimming server, ferstoppe efter it domein .
Neist de boppesteande DoH-resolver mozilla.cloudflare-dns.com kinne wy oare populêre DoH-tsjinsten brûke, bygelyks fan 'e ferneamde kweade korporaasje.
Litte wy de folgjende query útfiere:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/En wy krije it antwurd:
< 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 dit gefal kearden wy ús nei de blokkearre rutracker.nl-tsjinner, mei help fan de DoH-resolver dns.google (d'r is hjir gjin typflater, no hat de ferneamde korporaasje in eigen earste-level-domein) en bedekke ússels mei in oar domein, dat strikt is ferbean foar alle DPI's om te blokkearjen ûnder pine fan 'e dea. Op grûn fan it ûntfongen antwurd kinne jo begripe dat ús fersyk mei súkses ferwurke is.
As in ekstra kontrôle dat de DPI fan 'e provider reagearret op' e iepen SNI, dy't wy as dekking stjoere, kinne wy in fersyk oan rutracker.nl yntsjinje ûnder it mom fan in oare ferbeane boarne, bygelyks in oare "goede" torrent tracker:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Wy krije gjin antwurd fan de tsjinner, omdat... ús fersyk sil blokkearre wurde troch it DPI-systeem.
In koarte konklúzje fan it earste diel
Dat, wy koenen de funksjonaliteit fan eSNI demonstrearje mei openssl en curl en testen de wurking fan domeinfronting basearre op eSNI. Op deselde manier kinne wy ús favorite ark oanpasse dy't de openssl-bibleteek brûke om "ûnder it mom" fan oare domeinen te wurkjen. Mear details oer dit yn ús folgjende artikels.
Boarne: www.habr.com