Pendahuluan
Sistem penyaringan konten perusahaan modern dari produsen terkemuka seperti Cisco, BlueCoat, FireEye memiliki banyak kesamaan dengan rekan-rekan mereka yang lebih kuat - sistem DPI yang sedang dilaksanakan secara intensif di tingkat nasional. Inti dari pekerjaan keduanya adalah untuk mencari lalu lintas Internet yang masuk dan keluar dan, berdasarkan daftar hitam / putih, membuat keputusan untuk melarang koneksi Internet. Dan karena keduanya mengandalkan prinsip yang sama dalam dasar-dasar pekerjaan mereka, cara untuk mengelak dari mereka juga akan memiliki banyak kesamaan.
Salah satu teknologi yang memungkinkan mem-bypass DPI dan sistem korporat secara efisien adalah teknologi yang menghadap ke depan. Esensinya terletak pada kenyataan bahwa kita pergi ke sumber daya yang diblokir, bersembunyi di balik domain publik lainnya, dengan reputasi yang baik, yang jelas tidak akan diblokir oleh sistem apa pun, misalnya google.com.
Banyak artikel telah ditulis tentang teknologi ini dan banyak contoh telah diberikan. Namun, DNS-over-HTTPS dan teknologi terenkripsi-SNI, serta teknologi yang baru-baru ini dibahas, serta versi baru protokol TLS 1.3, memberikan kesempatan untuk mempertimbangkan varian lain dari domain yang menghadap ke depan.
Kami berurusan dengan teknologi
Pertama, mari kita putuskan sedikit tentang konsep dasar sehingga setiap orang memiliki pemahaman tentang siapa adalah siapa dan mengapa semua ini diperlukan. Kami menyebutkan mekanisme eSNI, yang karyanya akan dibahas nanti. Mekanisme eSNI (Indikasi Nama Server terenkripsi) adalah versi SNI yang aman, hanya tersedia untuk protokol TLS 1.3. Poin utamanya adalah mengenkripsi, termasuk informasi tentang ke domain mana permintaan dikirimkan.
Sekarang mari kita lihat bagaimana mekanisme eSNI bekerja dalam praktiknya.
Katakanlah kita memiliki sumber daya Internet yang diblokir oleh solusi DPI modern (ambil, misalnya, pelacak torrent yang terkenal - rutracker.nl). Ketika kami mencoba mengakses situs pelacak torrent, kami melihat rintisan standar penyedia yang sumbernya diblokir:
Di situs web ILV, domain ini memang tercantum dalam daftar berhenti:
Ketika Anda meminta whois, Anda dapat melihat bahwa domain itu sendiri "tersembunyi" di belakang penyedia cloud Cloudflare.
Tetapi tidak seperti "spesialis" dari ILV, karyawan yang lebih mengerti secara teknis dari langsung menuju (atau diajarkan oleh pengalaman pahit dari regulator terkenal kami) tidak secara bodoh melarang situs dengan alamat IP, tetapi memasukkan nama domain dalam daftar berhenti. Ini mudah untuk diverifikasi jika Anda melihat domain lain yang bersembunyi di balik alamat IP yang sama, kunjungi salah satunya dan melihat bahwa akses tidak diblokir:
Tetapi bagaimana itu bisa terjadi? Bagaimana penyedia DPI mengetahui domain mana yang digunakan browser saya, karena semua komunikasi dilakukan melalui protokol https, dan kami sepertinya tidak melihat substitusi sertifikat https dari langsung menuju? Apakah dia peramal atau dia diikuti oleh saya?
Mari kita coba menjawab pertanyaan ini dengan melihat lalu lintas melalui wireshark
Tangkapan layar menunjukkan bahwa pertama browser menerima alamat IP server melalui DNS, lalu ada handshake TCP standar dengan server tujuan, dan kemudian browser mencoba membuat koneksi ssl ke server. Untuk melakukan ini, ia mengirimkan paket Hello Client SSL, yang berisi nama domain sumber dalam teks yang jelas. Bidang ini diperlukan oleh server cloudflare front-end untuk merutekan koneksi dengan benar. Di sinilah penyedia DPI menangkap kami, memutuskan koneksi kami. Pada saat yang sama, kami tidak menerima rintisan dari penyedia, dan kami melihat kesalahan peramban standar seolah-olah situs itu terputus atau tidak berfungsi:
Sekarang mari kita aktifkan mekanisme eSNI di browser, seperti yang dijelaskan dalam instruksi untuk
Firefox :
Untuk melakukan ini, kami membuka halaman konfigurasi Firefox
tentang: 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 itu, kami akan memeriksa kebenaran pengaturan di situs web cloudflare menggunakan
tautan dan mencoba fokus dengan pelacak torrent kami lagi.
Voila. Pelacak favorit kami dibuka tanpa VPN atau proksi. Sekarang mari kita lihat tempat pembuangan lalu lintas di wireshark, apa yang terjadi.
Kali ini, paket halo klien ssl tidak secara eksplisit berisi domain tujuan, melainkan bidang baru yang muncul dalam paket - encrypted_server_name - ini adalah tempat nilai rutracker.nl terkandung, dan hanya server cloudflare front-end yang dapat mendekripsi bidang ini. Dan jika demikian, maka penyedia DPI tidak punya pilihan selain mencuci tangan dan mengizinkan lalu lintas tersebut. Tetapi tidak ada opsi lain dengan enkripsi.
Jadi, bagaimana teknologi ini bekerja di browser - kami melihat. Sekarang mari kita coba menerapkannya untuk hal-hal yang lebih spesifik dan menarik. Dan sebagai permulaan, kami akan mengajarkan ikal yang sama untuk menggunakan eSNI untuk bekerja dengan TLS 1.3, dan pada saat yang sama kita akan melihat bagaimana domain front-end berbasis eSNI itu sendiri bekerja.
Domain Front End dengan eSNI
Karena fakta bahwa curl menggunakan pustaka openssl standar untuk menghubungkan melalui https, pertama-tama, kita perlu memberikan dukungan eSNI di sana. Belum ada dukungan untuk eSNI di cabang master openssl, jadi kami perlu mengunduh cabang openssl khusus, kompilasi dan instal.
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 mengkonfigurasi kompilasi menggunakan pustaka openssl kami yang telah dirakit:
$ 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
Penting untuk menunjukkan dengan benar semua direktori di mana openssl berada (dalam kasus kami, itu adalah / opt / openssl /) dan pastikan bahwa proses konfigurasi berjalan tanpa kesalahan.
Jika konfigurasi berhasil, kita akan melihat baris:
PERINGATAN: esni ESNI diaktifkan tetapi ditandai EKSPERIMENTAL. Gunakan dengan hati-hati! $ make
Setelah berhasil membangun paket, kami akan menggunakan file bash openssl khusus untuk mengonfigurasi dan menjalankan curl. Salin ke direktori dengan curl untuk kenyamanan:
cp /opt/openssl/esnistuff/curl-esni
dan menjalankan permintaan https pengujian ke server cloudflare, sementara secara bersamaan menulis paket DNS dan TLS ke Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/
Dalam respons server, selain banyak informasi debug dari openssl dan curl, kami mendapatkan respons 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 menunjukkan bahwa permintaan kami berhasil dikirim ke server tujuan, didengar dan diproses.
Sekarang mari kita lihat tempat pembuangan lalu lintas di wireshark, mis. apa yang dilihat penyedia DPI dalam kasus ini.
Dapat dilihat bahwa ikal pertama beralih ke server DNS untuk kunci eSNI publik untuk server cloudflare - Permintaan DNS TXT ke _esni.cloudflare.com (paket No. 13). Kemudian, menggunakan perpustakaan openssl, curl mengirim permintaan TLS 1.3 ke server cloudflare di mana bidang SNI dienkripsi dengan kunci publik yang diperoleh pada langkah sebelumnya (paket No. 22).
Namun, selain bidang eSNI, sebagai bagian dari paket SSL-halo, bidang juga disisipkan dengan SNI biasa - terbuka, yang dapat kami tentukan dalam urutan apa pun (dalam hal ini - www.hello-rkn.ru ).Bidang SNI terbuka ini tidak diperhitungkan saat diproses oleh server cloudflare dan hanya merupakan penyamaran bagi penyedia DPI. Server cloudflare menerima paket ssl-hello kami, mendekripsi eSNI, mengekstraksi SNI asli dari sana dan mengolahnya seolah-olah tidak ada yang terjadi (ia melakukan segalanya persis seperti yang direncanakan selama pengembangan eSNI).
Satu-satunya hal dalam hal ini, Anda dapat berpegang teguh pada DPI - permintaan DNS utama di _esni.cloudflare.com. Tapi kami membuat permintaan DNS terbuka hanya untuk menunjukkan bagaimana mekanisme ini bekerja dari dalam.
Untuk akhirnya menjatuhkan tanah dari bawah DPI, kami menggunakan mekanisme DNS-over-HTTPS yang telah disebutkan. Penjelasan kecil - DOH - protokol yang memungkinkan Anda untuk melindungi diri dari seorang pria di serangan tengah dengan mengirimkan permintaan DNS melalui HTTPS.
Kami akan mengeksekusi permintaan lagi, tetapi kali ini kami akan mendapatkan kunci eSNI publik menggunakan protokol https, bukan DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/
Permintaan traffic traffic disajikan dalam tangkapan layar di bawah ini:
Terlihat bahwa pertama curl mengakses server mozilla.cloudflare-dns.com menggunakan protokol DoH (koneksi https ke server 104.16.249.249) untuk mendapatkan nilai kunci publik untuk enkripsi SNI dari mereka, dan kemudian ke server tujuan, bersembunyi di bawah domain.
www.hello-rkn.ru .
Selain DoH resolver mozilla.cloudflare-dns.com yang ditentukan di atas, kita dapat menggunakan layanan DoH populer lainnya, misalnya, dari perusahaan jahat yang terkenal.
Kami melaksanakan permintaan 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 kasus ini, kami beralih ke rutracker.nl server yang diblokir, menggunakan resolver dns.google DoH (tidak ada kesalahan ketik, sekarang perusahaan terkenal memiliki domain tingkat pertama sendiri) dan menutup diri dengan domain lain, yang dilarang keras oleh semua DPI untuk memblokir takut akan hukuman mati. Menurut jawaban Anda dapat memahami bahwa permintaan kami berhasil diproses.
Sebagai pemeriksaan tambahan bahwa penyedia DPI menanggapi SNI terbuka, yang kami sampaikan sebagai penutup - kami dapat melaksanakan permintaan ke rutracker.nl di belakang beberapa sumber daya terlarang lainnya, misalnya, pelacak torrent "baik" lainnya:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/
Kami tidak akan menerima respons dari server, karena permintaan kami akan diblokir oleh sistem DPI.
Kesimpulan kecil untuk bagian pertama
Jadi, kami dapat menunjukkan kesehatan eSNI menggunakan openssl dan curl dan menguji operasi front-end berbasis domain berdasarkan eSNI. Dengan cara yang sama, kita dapat mengadaptasi alat favorit kita menggunakan pustaka openssl untuk bekerja "di bawah penutup" dari domain lain. Lebih lanjut tentang ini di artikel kami berikutnya.