pengenalan
Sistem penyaringan konten korporat modern dari produsen terkenal seperti Cisco, BlueCoat, FireEye memiliki banyak kesamaan dengan sistem DPI yang lebih kuat, yang secara aktif diterapkan di tingkat nasional. Inti dari pekerjaan keduanya adalah memeriksa lalu lintas Internet masuk dan keluar dan, berdasarkan daftar hitam/putih, membuat keputusan untuk melarang koneksi Internet. Dan karena keduanya mengandalkan prinsip serupa dalam dasar pekerjaannya, metode untuk menghindarinya juga akan memiliki banyak kesamaan.
Salah satu teknologi yang memungkinkan Anda melewati DPI dan sistem perusahaan secara efektif adalah teknologi domain-fronting. Esensinya adalah kita pergi ke sumber daya yang diblokir, bersembunyi di balik domain publik lain dengan reputasi baik, yang jelas tidak akan diblokir oleh sistem apa pun, misalnya google.com.
Cukup banyak artikel yang telah ditulis tentang teknologi ini dan banyak contoh telah diberikan. Namun, teknologi DNS-over-HTTPS dan SNI terenkripsi yang populer dan baru-baru ini dibahas, serta versi baru protokol TLS 1.3, memungkinkan untuk mempertimbangkan opsi lain untuk fronting domain.
Memahami teknologi
Pertama, mari kita definisikan sedikit konsep dasar agar setiap orang memahami siapa adalah siapa dan mengapa semua ini diperlukan. Kami telah menyebutkan mekanisme eSNI yang cara kerjanya akan dibahas lebih lanjut. Mekanisme eSNI (Indikasi Nama Server terenkripsi) adalah versi SNI yang aman, hanya tersedia untuk protokol TLS 1.3. Ide utamanya adalah untuk mengenkripsi, antara lain, informasi tentang domain mana permintaan dikirim.
Sekarang mari kita lihat bagaimana mekanisme eSNI bekerja dalam praktiknya.
Katakanlah kita memiliki sumber daya Internet yang diblokir oleh solusi DPI modern (misalnya, pelacak torrent terkenal rutracker.nl). Saat kami mencoba mengakses situs web pelacak torrent, kami melihat rintisan standar penyedia yang menunjukkan bahwa sumber daya tersebut diblokir:
Di website RKN domain ini sebenarnya tercantum dalam daftar pemberhentian:
Saat Anda menanyakan whois, Anda dapat melihat bahwa domain itu sendiri βtersembunyiβ di balik penyedia cloud Cloudflare.
Namun tidak seperti βspesialisβ dari RKN, karyawan Beeline yang lebih paham secara teknis (atau diajar oleh pengalaman pahit regulator terkenal kami) tidak dengan bodohnya melarang situs tersebut berdasarkan alamat IP, tetapi menambahkan nama domain ke daftar berhenti. Anda dapat dengan mudah memverifikasi ini jika Anda melihat domain lain apa yang tersembunyi di balik alamat IP yang sama, kunjungi salah satunya dan lihat bahwa akses tidak diblokir:
Bagaimana ini bisa terjadi? Bagaimana DPI penyedia mengetahui di domain mana browser saya berada, karena semua komunikasi terjadi melalui protokol https, dan kami belum melihat penggantian sertifikat https dari Beeline? Apakah dia peramal atau aku sedang diikuti?
Mari kita coba menjawab pertanyaan ini dengan melihat lalu lintas melalui Wireshark
Tangkapan layar menunjukkan bahwa pertama-tama browser memperoleh alamat IP server melalui DNS, kemudian terjadi jabat tangan TCP standar dengan server tujuan, dan kemudian browser mencoba membuat koneksi SSL dengan server. Untuk melakukan hal ini, ia mengirimkan paket SSL Client Hello, yang berisi nama domain sumber dalam teks yang jelas. Bidang ini diperlukan oleh server frontend cloudflare untuk merutekan koneksi dengan benar. Di sinilah DPI penyedia menangkap kita, memutus koneksi kita. Pada saat yang sama, kami tidak menerima rintisan apa pun dari penyedia, dan kami melihat kesalahan browser standar seolah-olah situs tersebut dinonaktifkan atau tidak berfungsi:
Sekarang mari aktifkan mekanisme eSNI di browser, seperti yang tertulis di petunjuknya :
Untuk melakukan ini kita membuka halaman konfigurasi Firefox about: config dan aktifkan pengaturan berikut:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Setelah ini, kami akan memeriksa apakah pengaturan di situs cloudflare berfungsi dengan benar. dan mari kita coba lagi triknya dengan pelacak torrent kita.
Voila. Pelacak favorit kami dibuka tanpa VPN atau server proxy apa pun. Sekarang mari kita lihat traffic dump di Wireshark untuk melihat apa yang terjadi.
Kali ini, paket hello klien ssl tidak secara eksplisit berisi domain tujuan, melainkan bidang baru muncul di paket - nama_server_enkripsi - di sinilah nilai rutracker.nl terkandung, dan hanya server frontend cloudflare yang dapat mendekripsi ini bidang. Dan jika demikian, maka penyedia DPI tidak punya pilihan selain mencuci tangan dan mengizinkan lalu lintas tersebut. Tidak ada pilihan lain dengan enkripsi.
Jadi, kami melihat cara kerja teknologi di browser. Sekarang mari kita coba menerapkannya pada hal-hal yang lebih spesifik dan menarik. Dan pertama-tama, kita akan mengajarkan curl yang sama untuk menggunakan eSNI agar berfungsi dengan TLS 1.3, dan pada saat yang sama kita akan melihat cara kerja fronting domain berbasis eSNI itu sendiri.
Tampilan depan domain dengan eSNI
Karena curl menggunakan pustaka openssl standar untuk terhubung melalui protokol https, pertama-tama kita perlu menyediakan dukungan eSNI di sana. Belum ada dukungan eSNI di cabang master openssl, jadi kita perlu mengunduh cabang openssl khusus, mengkompilasi dan menginstalnya.
Kami mengkloning repositori dari GitHub dan mengkompilasi seperti biasa:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Selanjutnya, kami mengkloning repositori dengan curl dan mengonfigurasi kompilasinya menggunakan perpustakaan openssl kami yang telah dikompilasi:
$ 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 penting untuk menentukan dengan benar semua direktori tempat openssl berada (dalam kasus kami, ini adalah /opt/openssl/) dan memastikan bahwa proses konfigurasi berjalan tanpa kesalahan.
Jika konfigurasi berhasil, kita akan melihat baris:
PERINGATAN: esni ESNI diaktifkan tetapi ditandai EKSPERIMENTAL. Gunakan dengan hati-hati!
$ makeSetelah berhasil membangun paket, kita akan menggunakan file bash khusus dari openssl untuk mengkonfigurasi dan menjalankan curl. Mari salin ke direktori dengan curl untuk kenyamanan:
cp /opt/openssl/esnistuff/curl-esni dan melakukan uji permintaan https ke server cloudflare, sekaligus merekam paket DNS dan TLS di Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Pada respon server, selain banyak informasi debugging dari openssl dan curl, kita akan menerima respon HTTP dengan kode 301 dari 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 menandakan permintaan kita berhasil terkirim ke server tujuan, didengar dan diproses.
Sekarang mari kita lihat dump lalu lintas di Wireshark, mis. apa yang dilihat penyedia DPI dalam kasus ini.
Dapat dilihat bahwa curl pertama kali beralih ke server DNS untuk kunci eSNI publik untuk server cloudflare - permintaan DNS TXT ke _esni.cloudflare.com (paket No. 13). Kemudian, dengan menggunakan perpustakaan openssl, curl mengirimkan permintaan TLS 1.3 ke server cloudflare di mana bidang SNI dienkripsi dengan kunci publik yang diperoleh pada langkah sebelumnya (paket #22). Namun, selain kolom eSNI, paket SSL-hello juga menyertakan kolom dengan SNI terbuka biasa, yang dapat kita tentukan dalam urutan apa pun (dalam hal ini - ).
Bidang SNI terbuka ini tidak diperhitungkan dengan cara apa pun saat diproses oleh server cloudflare dan hanya berfungsi sebagai masker untuk DPI penyedia. Server cloudflare menerima paket ssl-hello kami, mendekripsi eSNI, mengekstrak SNI asli dari sana dan memprosesnya seolah-olah tidak terjadi apa-apa (semuanya dilakukan persis seperti yang direncanakan saat mengembangkan eSNI).
Satu-satunya hal yang dapat ditangkap dalam kasus ini dari sudut pandang DPI adalah permintaan DNS utama ke _esni.cloudflare.com. Namun kami membuat permintaan DNS terbuka hanya untuk menunjukkan cara kerja mekanisme ini dari dalam.
Untuk akhirnya keluar dari DPI, kami menggunakan mekanisme DNS-over-HTTPS yang telah disebutkan. Sedikit penjelasan - DOH adalah protokol yang memungkinkan Anda melindungi dari serangan man-in-the-middle dengan mengirimkan permintaan DNS melalui HTTPS.
Mari kita jalankan permintaannya lagi, tapi kali ini kita akan menerima kunci eSNI publik 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/Dump lalu lintas permintaan ditunjukkan pada gambar di bawah:
Terlihat bahwa curl pertama-tama mengakses server mozilla.cloudflare-dns.com melalui protokol DoH (koneksi https ke server 104.16.249.249) untuk mendapatkan dari mereka nilai kunci publik untuk enkripsi SNI, dan kemudian ke tujuan server, bersembunyi di balik domain .
Selain penyelesai DoH di atas mozilla.cloudflare-dns.com, kita dapat menggunakan layanan DoH populer lainnya, misalnya, dari perusahaan jahat terkenal.
Mari kita jalankan kueri berikut:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Dan kami mendapatkan jawabannya:
< 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 hal ini, kami beralih ke server rutracker.nl yang diblokir, menggunakan penyelesai DoH dns.google (tidak ada kesalahan ketik di sini, sekarang perusahaan terkenal memiliki domain tingkat pertama sendiri) dan menutupi diri kami dengan domain lain, yang secara ketat dilarang bagi semua DPI untuk memblokir di bawah ancaman kematian. Berdasarkan respon yang diterima, Anda dapat memahami bahwa permintaan kami berhasil diproses.
Sebagai pemeriksaan tambahan bahwa DPI penyedia merespons SNI terbuka, yang kami kirimkan sebagai kedok, kami dapat membuat permintaan ke rutracker.nl dengan kedok beberapa sumber terlarang lainnya, misalnya pelacak torrent "bagus" lainnya:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Kami tidak akan menerima respon dari server, karena... permintaan kita akan diblokir oleh sistem DPI.
Kesimpulan singkat untuk bagian pertama
Jadi, kami dapat mendemonstrasikan fungsionalitas eSNI menggunakan openssl dan curl serta menguji pengoperasian domain fronting berdasarkan eSNI. Dengan cara yang sama, kita dapat mengadaptasi alat favorit kita yang menggunakan perpustakaan openssl untuk bekerja βdengan kedokβ domain lain. Detail lebih lanjut tentang ini di artikel kami berikutnya.
Sumber: www.habr.com