Pengenalan
Sistem penapisan kandungan korporat moden daripada pengeluar terkenal seperti Cisco, BlueCoat, FireEye mempunyai banyak persamaan dengan rakan sejawat mereka yang lebih berkuasa - sistem DPI, yang sedang giat dilaksanakan di peringkat kebangsaan. Intipati kerja kedua-duanya adalah untuk memeriksa trafik Internet masuk dan keluar dan, berdasarkan senarai hitam/putih, membuat keputusan untuk mengharamkan sambungan Internet. Dan kerana kedua-duanya bergantung pada prinsip yang sama dalam asas kerja mereka, kaedah untuk memintas mereka juga akan mempunyai banyak persamaan.
Salah satu teknologi yang membolehkan anda memintas kedua-dua DPI dan sistem korporat dengan agak berkesan ialah teknologi hadapan domain. Intipatinya ialah kita pergi ke sumber yang disekat, bersembunyi di sebalik domain awam yang lain dengan reputasi yang baik, yang jelas tidak akan disekat oleh mana-mana sistem, contohnya google.com.
Cukup banyak artikel telah ditulis mengenai teknologi ini dan banyak contoh telah diberikan. Walau bagaimanapun, teknologi DNS-over-HTTPS dan SNI yang disulitkan yang popular dan baru-baru ini dibincangkan, serta versi baharu protokol TLS 1.3, memungkinkan untuk mempertimbangkan pilihan lain untuk menghadapkan domain.
Memahami teknologi
Mula-mula, mari kita takrifkan sedikit konsep asas supaya setiap orang mempunyai pemahaman tentang siapa dan mengapa semua ini diperlukan. Kami menyebut mekanisme eSNI, yang operasinya akan dibincangkan lebih lanjut. Mekanisme eSNI (Petunjuk Nama Pelayan yang disulitkan) ialah versi SNI yang selamat, hanya tersedia untuk protokol TLS 1.3. Idea utama adalah untuk menyulitkan, antara lain, maklumat tentang domain mana permintaan itu dihantar.
Sekarang mari kita lihat bagaimana mekanisme eSNI berfungsi dalam amalan.
Katakan kita mempunyai sumber Internet yang disekat oleh penyelesaian DPI moden (mari kita ambil, sebagai contoh, penjejak torrent terkenal rutracker.nl). Apabila kami cuba mengakses tapak web penjejak torrent, kami melihat rintisan standard pembekal yang menunjukkan bahawa sumber itu disekat:
Di laman web RKN domain ini sebenarnya disenaraikan dalam senarai hentian:
Apabila anda menanyakan siapa, anda dapat melihat bahawa domain itu sendiri "tersembunyi" di belakang penyedia awan Cloudflare.
Tetapi tidak seperti "pakar" dari RKN, pekerja yang lebih bijak dari segi teknikal dari Beeline (atau diajar oleh pengalaman pahit pengawal selia terkenal kami) tidak secara bodoh mengharamkan tapak melalui alamat IP, tetapi menambah nama domain ke senarai hentian. Anda boleh mengesahkan ini dengan mudah jika anda melihat domain lain yang tersembunyi di sebalik alamat IP yang sama, lawati salah satu daripadanya dan lihat bahawa akses tidak disekat:
Bagaimana ini berlaku? Bagaimanakah DPI pembekal mengetahui domain mana penyemak imbas saya dihidupkan, kerana semua komunikasi berlaku melalui protokol https, dan kami masih belum melihat penggantian sijil https daripada Beeline? Adakah dia peramal atau saya diekori?
Mari cuba jawab soalan ini dengan melihat trafik melalui wireshark
Tangkapan skrin menunjukkan bahawa mula-mula penyemak imbas memperoleh alamat IP pelayan melalui DNS, kemudian jabat tangan TCP standard berlaku dengan pelayan destinasi, dan kemudian penyemak imbas cuba mewujudkan sambungan SSL dengan pelayan. Untuk melakukan ini, ia menghantar paket Hello Pelanggan SSL, yang mengandungi nama domain sumber dalam teks yang jelas. Medan ini diperlukan oleh pelayan bahagian hadapan cloudflare untuk menghalakan sambungan dengan betul. Di sinilah DPI pembekal menangkap kami, memutuskan sambungan kami. Pada masa yang sama, kami tidak menerima sebarang stub daripada pembekal, dan kami melihat ralat penyemak imbas standard seolah-olah tapak dilumpuhkan atau tidak berfungsi:
Sekarang mari kita dayakan mekanisme eSNI dalam penyemak imbas, seperti yang ditulis dalam arahan untuk :
Untuk melakukan ini, kami membuka halaman konfigurasi Firefox about: config dan aktifkan tetapan berikut:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Selepas ini, kami akan menyemak sama ada tetapan berfungsi dengan betul pada tapak web cloudflare. dan mari cuba helah dengan penjejak torrent kami sekali lagi.
Voila. Penjejak kegemaran kami dibuka tanpa sebarang VPN atau pelayan proksi. Sekarang mari kita lihat tempat pembuangan trafik di wireshark untuk melihat apa yang berlaku.
Kali ini, pakej hello klien ssl tidak mengandungi domain destinasi secara eksplisit, tetapi sebaliknya, medan baharu muncul dalam pakej - encrypted_server_name - di sinilah nilai rutracker.nl terkandung, dan hanya pelayan frontend cloudflare boleh menyahsulit ini padang. Dan jika ya, maka DPI pembekal tidak mempunyai pilihan selain mencuci tangannya dan membenarkan lalu lintas sedemikian. Tiada pilihan lain dengan penyulitan.
Jadi, kami melihat bagaimana teknologi berfungsi dalam penyemak imbas. Sekarang mari kita cuba menerapkannya pada perkara yang lebih spesifik dan menarik. Pertama sekali, kami akan mengajar curl yang sama untuk menggunakan eSNI untuk berfungsi dengan TLS 1.3, dan pada masa yang sama kami akan melihat cara fronting domain berasaskan eSNI itu sendiri berfungsi.
Menghadapi domain dengan eSNI
Disebabkan fakta bahawa curl menggunakan perpustakaan openssl standard untuk menyambung melalui protokol https, pertama sekali kami perlu menyediakan sokongan eSNI di sana. Tiada sokongan eSNI dalam cawangan induk openssl lagi, jadi kami perlu memuat turun cawangan openssl khas, menyusun dan memasangnya.
Kami mengklon repositori dari GitHub dan menyusun seperti biasa:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Seterusnya, kami mengklon repositori dengan curl dan mengkonfigurasi kompilasinya menggunakan perpustakaan openssl kami yang disusun:
$ 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
Di sini adalah penting untuk menentukan dengan betul semua direktori tempat openssl terletak (dalam kes kami, ini adalah /opt/openssl/) dan pastikan proses konfigurasi berjalan tanpa ralat.
Jika konfigurasi berjaya, kita akan melihat baris:
AMARAN: esni ESNI didayakan tetapi ditandakan EKSPERIMEN. Gunakan dengan berhati-hati!
$ makeSelepas berjaya membina pakej, kami akan menggunakan fail bash khas dari openssl untuk mengkonfigurasi dan menjalankan curl. Mari salin ke direktori dengan curl untuk kemudahan:
cp /opt/openssl/esnistuff/curl-esni dan buat permintaan https ujian kepada pelayan cloudflare, sambil merakam paket DNS dan TLS dalam Wireshark secara serentak.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Dalam respons pelayan, sebagai tambahan kepada banyak maklumat penyahpepijatan daripada openssl dan curl, kami akan menerima respons HTTP dengan kod 301 daripada 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/
yang menunjukkan bahawa permintaan kami telah berjaya dihantar ke pelayan destinasi, didengar dan diproses.
Sekarang mari kita lihat pembuangan trafik di wireshark, i.e. apa yang DPI pembekal lihat dalam kes ini.
Ia boleh dilihat bahawa curl mula-mula beralih ke pelayan DNS untuk kunci eSNI awam untuk pelayan cloudflare - permintaan DNS TXT kepada _esni.cloudflare.com (pakej No. 13). Kemudian, menggunakan perpustakaan openssl, curl menghantar permintaan TLS 1.3 kepada pelayan cloudflare di mana medan SNI disulitkan dengan kunci awam yang diperoleh dalam langkah sebelumnya (paket #22). Tetapi, sebagai tambahan kepada medan eSNI, paket SSL-hello juga termasuk medan dengan biasa - SNI terbuka, yang boleh kami tentukan dalam sebarang susunan (dalam kes ini - ).
Medan SNI terbuka ini tidak diambil kira dalam apa jua cara apabila diproses oleh pelayan cloudflare dan hanya berfungsi sebagai topeng untuk DPI pembekal. Pelayan cloudflare menerima paket ssl-hello kami, menyahsulit eSNI, mengekstrak SNI asal dari sana dan memprosesnya seolah-olah tiada apa yang berlaku (ia melakukan segala-galanya tepat seperti yang dirancang semasa membangunkan eSNI).
Satu-satunya perkara yang boleh ditangkap dalam kes ini dari sudut pandangan DPI ialah permintaan DNS utama kepada _esni.cloudflare.com. Tetapi kami membuat permintaan DNS terbuka hanya untuk menunjukkan cara mekanisme ini berfungsi dari dalam.
Untuk akhirnya menarik permaidani keluar dari bawah DPI, kami menggunakan mekanisme DNS-over-HTTPS yang telah disebutkan. Sedikit penjelasan - DOH ialah protokol yang membolehkan anda melindungi daripada serangan man-in-the-middle dengan menghantar permintaan DNS melalui HTTPS.
Mari laksanakan permintaan itu sekali lagi, tetapi kali ini kami akan menerima kunci eSNI awam melalui protokol https, bukan DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Lambakan trafik permintaan ditunjukkan dalam tangkapan skrin di bawah:
Dapat dilihat bahawa curl mula-mula mengakses pelayan mozilla.cloudflare-dns.com melalui protokol DoH (sambungan https ke pelayan 104.16.249.249) untuk mendapatkan daripada mereka nilai kunci awam untuk penyulitan SNI, dan kemudian ke destinasi pelayan, bersembunyi di sebalik domain .
Sebagai tambahan kepada penyelesai DoH mozilla.cloudflare-dns.com di atas, kami boleh menggunakan perkhidmatan DoH popular yang lain, contohnya, daripada syarikat jahat yang terkenal.
Mari jalankan pertanyaan berikut:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Dan kami mendapat jawapannya:
< 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
Dalam kes ini, kami beralih ke pelayan rutracker.nl yang disekat, menggunakan penyelesai DoH dns.google (tiada kesilapan menaip di sini, kini syarikat terkenal itu mempunyai domain peringkat pertamanya sendiri) dan menutup diri kami dengan domain lain, iaitu dengan ketat dilarang untuk semua DPI menyekat di bawah kesakitan kematian. Berdasarkan maklum balas yang diterima, anda boleh memahami bahawa permintaan kami telah berjaya diproses.
Sebagai semakan tambahan bahawa DPI pembekal bertindak balas kepada SNI terbuka, yang kami hantar sebagai perlindungan, kami boleh membuat permintaan kepada rutracker.nl di bawah samaran beberapa sumber terlarang lain, contohnya, satu lagi penjejak torrent "baik":
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Kami tidak akan menerima maklum balas daripada pelayan, kerana... permintaan kami akan disekat oleh sistem DPI.
Kesimpulan ringkas untuk bahagian pertama
Oleh itu, kami dapat menunjukkan kefungsian eSNI menggunakan openssl dan curl serta menguji operasi hadapan domain berdasarkan eSNI. Dengan cara yang sama, kami boleh menyesuaikan alat kegemaran kami yang menggunakan perpustakaan openssl untuk berfungsi "berselindung" domain lain. Butiran lanjut mengenai perkara ini dalam artikel kami yang seterusnya.
Sumber: www.habr.com