Enkonduko
Modernaj kompaniaj filtrilaj sistemoj de tiaj famaj fabrikistoj kiel Cisco, BlueCoat, FireEye havas multe da komunaj kun siaj pli potencaj ekvivalentoj - DPI-sistemoj, kiuj aktive efektiviĝas je nacia nivelo. La esenco de la laboro de ambaŭ estas inspekti envenantan kaj elirantan interretan trafikon kaj, surbaze de nigraj/blankaj listoj, fari decidon malpermesi la interretan konekton. Kaj ĉar ambaŭ el ili dependas de similaj principoj en la bazoj de sia laboro, la metodoj por eviti ilin ankaŭ havos multon komuna.
Unu el la teknologioj, kiuj permesas vin sufiĉe efike preterpasi ambaŭ DPI kaj kompaniajn sistemojn, estas domajna fronta teknologio. Ĝia esenco estas, ke ni iras al blokita rimedo, kaŝante malantaŭ alia, publika havaĵo kun bona reputacio, kiu evidente ne estos blokita de iu ajn sistemo, ekzemple google.com.
Jam sufiĉe multe da artikoloj estis skribitaj pri ĉi tiu teknologio kaj multaj ekzemploj estis donitaj. Tamen, la popularaj kaj lastatempe diskutitaj teknologioj DNS-over-HTTPS kaj ĉifrita-SNI, same kiel la nova versio de la protokolo TLS 1.3, ebligas konsideri alian opcion por domajna frontado.
Komprenante la teknologion
Unue, ni difinu iomete bazajn konceptojn, por ke ĉiuj komprenu, kiu estas kiu kaj kial ĉio ĉi necesas. Ni menciis la eSNI-mekanismon, kies funkciado estos diskutita plu. La mekanismo eSNI (ĉifrita Server Name Indication) estas sekura versio de SNI, disponebla nur por la protokolo TLS 1.3. La ĉefa ideo estas ĉifri, interalie, informojn pri kiu domajno estas sendita la peto.
Nun ni rigardu kiel la mekanismo eSNI funkcias en la praktiko.
Ni diru, ke ni havas Interretan rimedon, kiu estas blokita de moderna DPI-solvo (ni prenu, ekzemple, la faman torentan spurilon rutracker.nl). Kiam ni provas aliri la retejon de torenta spuristo, ni vidas la norman stupon de la provizanto indikante, ke la rimedo estas blokita:
En la retejo de RKN ĉi tiu domajno fakte estas listigita en la haltlistoj:
Kiam vi demandas whois, vi povas vidi, ke la domajno mem estas "kaŝita" malantaŭ la nuba provizanto Cloudflare.
Sed male al la "specialistoj" de RKN, pli teknike lertaj dungitoj de Beeline (aŭ instruitaj de la amara sperto de nia fama reguligisto) ne stulte malpermesis la retejon per IP-adreso, sed aldonis la domajnan nomon al la haltlisto. Vi povas facile kontroli ĉi tion se vi rigardas, kiaj aliaj domajnoj estas kaŝitaj malantaŭ la sama IP-adreso, vizitu unu el ili kaj vidos, ke aliro ne estas blokita:
Kiel tio okazas? Kiel la DPI de la provizanto scias, en kiu domajno estas mia retumilo, ĉar ĉiuj komunikadoj okazas per la https protokolo, kaj ni ankoraŭ ne rimarkis la anstataŭigon de https-atestiloj de Beeline? Ĉu li estas klarvida aŭ ĉu mi estas sekvata?
Ni provu respondi ĉi tiun demandon rigardante la trafikon per wireshark
La ekrankopio montras, ke unue la retumilo akiras la IP-adreson de la servilo per DNS, tiam norma TCP-manpremo okazas kun la celservilo, kaj tiam la retumilo provas establi SSL-konekton kun la servilo. Por fari tion, ĝi sendas SSL-kliento Salutan pakaĵon, kiu enhavas la nomon de la fonta domajno en klara teksto. Ĉi tiu kampo estas postulata de la fasanta servilo cloudflare por ĝuste direkti la konekton. Jen kie la provizanto DPI kaptas nin, rompante nian konekton. Samtempe, ni ricevas neniun stumblon de la provizanto, kaj ni vidas la norman retumilon eraron kvazaŭ la retejo estas malŝaltita aŭ simple ne funkcias:
Nun ni ebligu la eSNI-mekanismon en la retumilo, kiel skribite en la instrukcioj por :
Por fari tion ni malfermas la agordan paĝon de Firefox pri: config kaj aktivigu la sekvajn agordojn:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Post ĉi tio, ni kontrolos, ke la agordoj funkcias ĝuste en la retejo de cloudflare. kaj ni provu la lertaĵon per nia torenta spurilo denove.
Voila. Nia plej ŝatata spurilo malfermiĝis sen VPN aŭ prokura servilo. Ni nun rigardu la trafikan rubejon en wireshark por vidi kio okazis.
Ĉi-foje, la ssl-klienta helo-pakaĵo ne eksplicite enhavas la cel-domajnon, sed anstataŭe, nova kampo aperis en la pakaĵo - encrypted_server_name - ĉi tie estas enhavita la valoro de rutracker.nl, kaj nur la cloudflare fasanta servilo povas deĉifri ĉi tion. kampo. Kaj se jes, tiam la provizanto DPI ne havas alian elekton ol lavi siajn manojn kaj permesi tian trafikon. Ne ekzistas aliaj ebloj kun ĉifrado.
Do, ni rigardis kiel la teknologio funkcias en la retumilo. Nun ni provu apliki ĝin al pli specifaj kaj interesaj aferoj. Kaj unue, ni instruos la saman buklon uzi eSNI por labori kun TLS 1.3, kaj samtempe ni vidos kiel funkcias la eSNI-bazita domajna fronto mem.
Domajna frontado kun eSNI
Pro la fakto, ke curl uzas la norman openssl-bibliotekon por konekti per la https-protokolo, unue ni devas provizi eSNI-subtenon tie. Ankoraŭ ne ekzistas eSNI-subteno en la majstraj branĉoj de openssl, do ni devas elŝuti specialan branĉon de openssl, kompili kaj instali ĝin.
Ni klonas la deponejon de GitHub kaj kompilas kiel kutime:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Poste, ni klonas la deponejon per buklo kaj agordas ĝian kompilon uzante nian kompilitan openssl-bibliotekon:
$ 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
Ĉi tie gravas ĝuste specifi ĉiujn dosierujojn, kie openssl troviĝas (en nia kazo, ĉi tio estas /opt/openssl/) kaj certigi, ke la agorda procezo iras sen eraroj.
Se la agordo sukcesas, ni vidos la linion:
AVERTO: esni ESNI ebligita sed markita EXPERIMENTA. Uzu kun singardemo!
$ makePost sukcese konstrui la pakaĵon, ni uzos specialan bash-dosieron de openssl por agordi kaj ruli curl. Ni kopiu ĝin al la dosierujo kun buklo por oportuno:
cp /opt/openssl/esnistuff/curl-esni kaj faru provan https-peton al la servilo cloudflare, samtempe registrante DNS kaj TLS-pakaĵojn en Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/En la servila respondo, krom multe da sencimigaj informoj de openssl kaj curl, ni ricevos HTTP-respondon kun kodo 301 de 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/
kiu indikas ke nia peto estis sukcese liverita al la celservilo, aŭdita kaj prilaborita.
Nun ni rigardu la trafikan rubejon en wireshark, t.e. kion la provizanto DPI vidis en ĉi tiu kazo.
Videblas, ke buklo unue turnis sin al la DNS-servilo por publika eSNI-ŝlosilo por la cloudflare-servilo - TXT DNS-peto al _esni.cloudflare.com (pako n-ro 13). Tiam, uzante la openssl-bibliotekon, curl sendis TLS 1.3-peton al la servilo cloudflare, en kiu la SNI-kampo estis ĉifrita per la publika ŝlosilo akirita en la antaŭa paŝo (pako #22). Sed, krom la eSNI-kampo, la SSL-hello-pako ankaŭ inkludis kampon kun la kutima - malfermita SNI, kiun ni povas specifi en ajna ordo (ĉi-kaze - ).
Ĉi tiu malferma SNI-kampo neniel estis konsiderata kiam prilaborita de cloudflare-serviloj kaj nur funkciis kiel masko por la provizanto DPI. La servilo cloudflare ricevis nian ssl-hello-pakaĵon, malĉifris la eSNI, ĉerpis la originan SNI de tie kaj prilaboris ĝin kvazaŭ nenio okazis (ĝi faris ĉion precize kiel planite dum disvolvado de eSNI).
La sola afero, kiu povas esti kaptita en ĉi tiu kazo de DPI-punkto, estas la primara DNS-peto al _esni.cloudflare.com. Sed ni malfermis la DNS-peton nur por montri kiel ĉi tiu mekanismo funkcias de interne.
Por fine eltiri la tapiŝon el sub DPI, ni uzas la jam menciitan DNS-super-HTTPS-mekanismon. Malgranda klarigo - DOH estas protokolo, kiu permesas vin protekti kontraŭ viro-en-la-meza atako sendante DNS-peton per HTTPS.
Ni plenumu la peton denove, sed ĉi-foje ni ricevos publikajn eSNI-ŝlosilojn per la https protokolo, ne DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/La peta trafikforĵeto estas montrita en la ekrankopio sube:
Videblas, ke curl unue aliras la servilon mozilla.cloudflare-dns.com per la protokolo DoH (https-konekto al servilo 104.16.249.249) por akiri de ili la valorojn de publikaj ŝlosiloj por SNI-ĉifrado, kaj poste al la celloko. servilo, kaŝante malantaŭ la domajno .
Krom ĉi-supra DoH-solvilo mozilla.cloudflare-dns.com, ni povas uzi aliajn popularajn DoH-servojn, ekzemple, de la fama malbona korporacio.
Ni rulu la sekvan demandon:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Kaj ni ricevas la respondon:
< 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
En ĉi tiu kazo, ni turnis nin al la blokita servilo rutracker.nl, uzante la DoH-solvilon dns.google (ĉi tie ne estas tajperaro, nun la fama korporacio havas sian propran unuanivelan domajnon) kaj kovris nin per alia domajno, kiu estas strikte malpermesite por ĉiuj DPI-oj bloki sub doloro de morto. Surbaze de la ricevita respondo, vi povas kompreni, ke nia peto estis sukcese procesita.
Kiel kroma kontrolo, ke la DPI de la provizanto respondas al la malfermita SNI, kiun ni transdonas kiel kovrilo, ni povas fari peton al rutracker.nl sub la alivestiĝo de iu alia malpermesita rimedo, ekzemple, alia "bona" torenta spurilo:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Ni ne ricevos respondon de la servilo, ĉar... nia peto estos blokita de la DPI-sistemo.
Mallonga konkludo al la unua parto
Do, ni povis pruvi la funkciecon de eSNI uzante openssl kaj curl kaj testi la funkciadon de domajna frontado bazita sur eSNI. De la sama maniero, ni povas adapti niajn plej ŝatatajn ilojn, kiuj uzas la openssl-bibliotekon por labori "sub la alivestiĝo" de aliaj domajnoj. Pli da detaloj pri tio en niaj sekvaj artikoloj.
fonto: www.habr.com