Esittely
Nykyaikaisilla yrityssisällön suodatusjärjestelmillä sellaisilta tunnetuilta valmistajilta kuin Cisco, BlueCoat, FireEye on melko paljon yhteistä tehokkaampien vastineidensa - DPI-järjestelmien kanssa, joita otetaan aktiivisesti käyttöön kansallisella tasolla. Molempien työn ydin on tarkastaa tuleva ja lähtevä Internet-liikenne ja tehdä mustien/valkoisten listojen perusteella päätös Internet-yhteyden kieltämisestä. Ja koska molemmat nojaavat samanlaisiin periaatteisiin työnsä perusteissa, niiden kiertämismenetelmillä on myös paljon yhteistä.
Yksi teknologioista, jonka avulla voit tehokkaasti ohittaa sekä DPI:n että yritysjärjestelmät, on toimialueen etuteknologia. Sen olemus on, että menemme estettyyn resurssiin piiloutuen toisen, julkisen ja hyvän maineen takana, jota mikään järjestelmä ei tietenkään estä, esimerkiksi google.com.
Tästä tekniikasta on jo kirjoitettu melko paljon artikkeleita ja monia esimerkkejä on annettu. Suositut ja äskettäin käsitellyt DNS-over-HTTPS- ja salattu SNI-teknologiat sekä TLS 1.3 -protokollan uusi versio antavat kuitenkin mahdollisuuden harkita toista vaihtoehtoa toimialueen frontingille.
Tekniikan ymmärtäminen
Ensin määritellään vähän peruskäsitteitä, jotta jokaisella on käsitys kuka on kuka ja miksi kaikkea tätä tarvitaan. Mainitsimme eSNI-mekanismin, jonka toiminnasta keskustellaan lisää. eSNI (encrypted Server Name Indication) -mekanismi on SNI:n suojattu versio, joka on saatavilla vain TLS 1.3 -protokollalle. Pääideana on salata muun muassa tiedot siitä, mille toimialueelle pyyntö lähetetään.
Katsotaan nyt kuinka eSNI-mekanismi toimii käytännössä.
Oletetaan, että meillä on Internet-resurssi, jonka moderni DPI-ratkaisu estää (otetaan esimerkiksi kuuluisa torrent-seurantalaite rutracker.nl). Kun yritämme käyttää torrent-seurannan verkkosivustoa, näemme palveluntarjoajan vakiotunnisteen, joka osoittaa, että resurssi on estetty:
RKN-verkkosivustolla tämä verkkotunnus on itse asiassa lueteltu pysäytysluetteloissa:
Kun teet kyselyn whois, näet, että itse verkkotunnus on "piilotettu" pilvipalveluntarjoajan Cloudflaren taakse.
Mutta toisin kuin RKN:n "asiantuntijat", Beelinen teknisesti taitavammat työntekijät (tai kuuluisan sääntelijämme katkeran kokemuksen opettamia) eivät tyhmästi kieltäneet sivustoa IP-osoitteen perusteella, vaan lisäsivät verkkotunnuksen lopetusluetteloon. Voit tarkistaa tämän helposti, jos katsot, mitä muita verkkotunnuksia on piilotettu saman IP-osoitteen taakse, käy yhdellä niistä ja huomaa, ettei pääsyä ole estetty:
Miten tämä tapahtuu? Mistä palveluntarjoajan DPI tietää, millä verkkotunnuksella selaimeni on, koska kaikki viestintä tapahtuu https-protokollan kautta, emmekä ole vielä huomanneet https-varmenteiden korvaamista Beelineltä? Onko hän selvänäkijä vai seurataanko minua?
Yritetään vastata tähän kysymykseen tarkastelemalla liikennettä wiresharkin kautta
Kuvakaappaus osoittaa, että ensin selain saa palvelimen IP-osoitteen DNS:n kautta, sitten tapahtuu tavallinen TCP-kättely kohdepalvelimen kanssa ja sitten selain yrittää muodostaa SSL-yhteyden palvelimeen. Tätä varten se lähettää SSL Client Hello -paketin, joka sisältää lähdeverkkotunnuksen nimen selkeänä tekstinä. Cloudflare-etupalvelin vaatii tämän kentän, jotta yhteys voidaan reitittää oikein. Tässä palveluntarjoajan DPI saa meidät kiinni ja katkaisee yhteytemme. Samaan aikaan emme saa palveluntarjoajalta mitään tynkä, ja näemme tavallisen selainvirheen ikään kuin sivusto olisi poistettu käytöstä tai ei yksinkertaisesti toimi:
Otetaan nyt eSNI-mekanismi käyttöön selaimessa, kuten ohjeissa on kirjoitettu :
Tätä varten avaamme Firefoxin asetussivun about: config ja aktivoi seuraavat asetukset:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Tämän jälkeen tarkistamme, että asetukset toimivat oikein cloudflare-verkkosivustolla. ja kokeillaan temppua torrent-seurannan avulla uudelleen.
Voila. Suosikkiseurantamme avautui ilman VPN- tai välityspalvelimia. Katsotaanpa nyt Wiresharkin kaatopaikkaa nähdäksemme mitä tapahtui.
Tällä kertaa ssl-asiakkaan hello-paketti ei sisällä nimenomaisesti kohdeverkkotunnusta, vaan sen sijaan pakettiin ilmestyi uusi kenttä - encrypted_server_name - tässä on rutracker.nl:n arvo, ja vain cloudflare-etupalvelin voi purkaa tämän salauksen. ala. Ja jos näin on, palveluntarjoajan DPI:llä ei ole muuta vaihtoehtoa kuin pestä kätensä ja sallia tällainen liikenne. Salauksella ei ole muita vaihtoehtoja.
Joten tarkastelimme, kuinka tekniikka toimii selaimessa. Yritetään nyt soveltaa sitä tarkempiin ja kiinnostavampiin asioihin. Ja ensin, opetamme saman curl:n käyttämään eSNI:tä TLS 1.3:n kanssa työskentelemiseen, ja samalla näemme, miten itse eSNI-pohjainen verkkotunnuksen fronting toimii.
Domain fronting eSNI:n avulla
Koska curl käyttää normaalia openssl-kirjastoa yhteyden muodostamiseen https-protokollan kautta, meidän on ensinnäkin tarjottava eSNI-tuki siellä. Openssl-päähaaroissa ei vielä ole eSNI-tukea, joten meidän on ladattava erityinen openssl-haara, käännettävä ja asennettava se.
Kloonamme arkiston GitHubista ja käännämme tavalliseen tapaan:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Seuraavaksi kloonaamme arkiston curlilla ja määritämme sen käännöksen käyttämällä käännettyä openssl-kirjastoamme:
$ 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
Tässä on tärkeää määrittää oikein kaikki hakemistot, joissa openssl sijaitsee (tässä tapauksessa tämä on /opt/openssl/) ja varmistaa, että määritysprosessi sujuu ilman virheitä.
Jos määritys onnistuu, näemme rivin:
VAROITUS: esni ESNI käytössä, mutta merkitty KOKEELLISESTI. Käytä varoen!
$ makeKun paketti on rakennettu onnistuneesti, käytämme erityistä bash-tiedostoa openssl:stä curlin määrittämiseen ja suorittamiseen. Kopioimme se hakemistoon curlilla mukavuuden vuoksi:
cp /opt/openssl/esnistuff/curl-esni ja tee testi https-pyyntö cloudflare-palvelimelle samalla kun tallennat DNS- ja TLS-paketit Wiresharkissa.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Palvelimen vastauksessa saamme useiden openssl- ja curl-virheenkorjaustietojen lisäksi cloudflarelta HTTP-vastauksen koodilla 301.
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/
mikä osoittaa, että pyyntömme toimitettiin onnistuneesti kohdepalvelimelle, kuultiin ja käsiteltiin.
Katsotaanpa nyt Wiresharkin liikennekaappausta, ts. mitä palveluntarjoaja DPI näki tässä tapauksessa.
Voidaan nähdä, että curl kääntyi ensin DNS-palvelimen puoleen saadakseen julkista eSNI-avainta cloudflare-palvelimelle - TXT DNS -pyyntö osoitteeseen _esni.cloudflare.com (paketti nro 13). Sitten curl lähetti openssl-kirjastoa käyttämällä TLS 1.3 -pyynnön cloudflare-palvelimelle, jossa SNI-kenttä salattiin edellisessä vaiheessa saadulla julkisella avaimella (paketti #22). Mutta eSNI-kentän lisäksi SSL-hello-paketti sisälsi myös kentän tavallisella - avoimella SNI:llä, jonka voimme määrittää missä tahansa järjestyksessä (tässä tapauksessa - ).
Tätä avointa SNI-kenttää ei otettu millään tavalla huomioon, kun cloudflare-palvelimet käsittelivät sitä, ja se toimi vain peitteenä tarjoajan DPI:lle. Cloudflare-palvelin vastaanotti ssl-hello-pakettimme, purki eSNI:n salauksen, puristi sieltä alkuperäisen SNI:n ja käsitteli sen ikään kuin mitään ei olisi tapahtunut (se teki kaiken täsmälleen suunnitellusti eSNI:tä kehitettäessä).
Ainoa asia, joka voidaan saada kiinni tässä tapauksessa DPI-näkökulmasta, on ensisijainen DNS-pyyntö osoitteeseen _esni.cloudflare.com. Mutta teimme DNS-pyynnön avoimeksi vain näyttääksemme, kuinka tämä mekanismi toimii sisältäpäin.
Vedäksemme lopuksi maton DPI:n alta, käytämme jo mainittua DNS-over-HTTPS -mekanismia. Pieni selitys - DOH on protokolla, jonka avulla voit suojautua välimieshyökkäykseltä lähettämällä DNS-pyynnön HTTPS:n kautta.
Suoritetaan pyyntö uudelleen, mutta tällä kertaa saamme julkiset eSNI-avaimet https-protokollan, ei DNS:n kautta:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Pyynnön liikennevedos näkyy alla olevassa kuvakaappauksessa:
Voidaan nähdä, että curl käyttää ensin mozilla.cloudflare-dns.com-palvelinta DoH-protokollan kautta (https-yhteys palvelimeen 104.16.249.249) saadakseen heiltä julkisten avainten arvot SNI-salausta varten ja sitten kohteeseen. palvelin, joka piiloutuu verkkotunnuksen taakse .
Yllä olevan DoH-ratkaisun mozilla.cloudflare-dns.com lisäksi voimme käyttää muita suosittuja DoH-palveluita, esimerkiksi kuuluisalta pahalta yhtiöltä.
Suoritetaan seuraava kysely:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Ja saamme vastauksen:
< 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
Tässä tapauksessa käännyimme estettyyn rutracker.nl-palvelimeen käyttämällä DoH-selvitintä dns.google (tässä ei ole kirjoitusvirhettä, nyt kuuluisalla yhtiöllä on oma ensimmäisen tason verkkotunnus) ja peitimme itsemme toisella verkkotunnuksella, joka on tiukasti kaikkien DPI:iden estäminen kuolemankivun alla on kielletty. Saatujen vastausten perusteella voit ymmärtää, että pyyntömme on käsitelty onnistuneesti.
Lisätarkistuksena, että palveluntarjoajan DPI vastaa avoimeen SNI:hen, jonka lähetämme suojana, voimme tehdä pyynnön rutracker.nl:lle jonkin muun kielletyn resurssin, esimerkiksi toisen "hyvän" torrent-seurannan varjolla:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Emme saa vastausta palvelimelta, koska... DPI-järjestelmä estää pyyntömme.
Lyhyt johtopäätös ensimmäiseen osaan
Pystyimme siis esittelemään eSNI:n toimivuuden openssl:n ja curlin avulla sekä testaamaan eSNI:hen perustuvan domain frontingin toimintaa. Samalla tavalla voimme mukauttaa openssl-kirjastoa käyttävät suosikkityökalumme toimimaan muiden verkkotunnusten "varjolla". Lisätietoja tästä seuraavissa artikkeleissamme.
Lähde: will.com