Tetap Terenkripsi, Tetap Aman: Bekerja dengan ESNI, DoH, dan DoT

Perkembangan terbaru dalam melindungi privasi di internet termasuk indikasi nama server TLS terenkripsi (ESNI) dan DNS terenkripsi dalam bentuk DNS over HTTPS (DoH), yang keduanya dianggap sangat kontroversial oleh pengumpul data.

Jadi, inilah sekilas alasan mereka ada, detail tentang apa itu, dan teknologi di balik cara kerjanya.

DNS Perlu Berfungsi dengan Benar

Koneksi jaringan pribadi virtual (VPN) terowongan terpisah, protokol penemuan otomatis proxy web (WPAD), DNS multicast konfigurasi nol (mDNS), daftar hitam waktu-nyata (RBL), dan banyak teknologi lain yang digunakan secara luas rusak ketika DNS tidak berfungsi. t beroperasi dengan benar.

Memecah Internet untuk Keuntungan dan Ketenaran

Sejauh tahun 2003, pengguna internet belajar tentang pentingnya DNS dalam skala global ketika perusahaan yang kemudian menjalankan domain tingkat atas (TLD) .com memilih untuk berhenti mengeluarkan tanggapan NXDOMAIN . Mereka malah meniru domain yang tidak ada dalam upaya untuk menayangkan lebih banyak iklan, menjual lebih banyak domain, dan pada akhirnya menghasilkan lebih banyak pendapatan. Efek knock-on yang tidak terduga menghasilkan debat publik dan laporan yang memberatkan dari Komite Penasihat Keamanan dan Stabilitas ICANN (SSAC). Proyek ini memang ditutup tetapi dari sudut pandang teknis, kerentanan tetap ada.

Kemudian pada tahun 2008, upaya lain untuk memanipulasi DNS demi keuntungan diumumkan secara publik ketika beberapa ISP terbesar akhirnya memperkenalkan berbagai jalan untuk serangan skrip lintas situs terhadap situs web mana pun . Karena sifat kerentanannya, bahkan situs web yang dihosting di jaringan pribadi dan tidak dapat diakses dari internet dapat dieksploitasi.

Masalah yang ditemukan bukan pada protokol internet inti, melainkan masalah yang diperburuk oleh monetisasi yang tidak tepat dari fitur DNS tertentu.

Paul Vixie, Konsorsium Sistem Internet (ISC)

Meskipun benar bahwa protokol itu sendiri bukanlah penyebab masalah, juga benar bahwa protokol ini tidak mencegah pelaku jahat menyalahgunakan sistem. Jadi dari sudut pandang teknis, kerentanan tetap ada.

Melanggar Internet untuk Pengawasan dan Sensor

Pada 2016, diamati bahwa ISP di Iran memanipulasi DNS. Kali ini, alih-alih menyuntikkan iklan, mereka memblokir akses ke server email dari 139 dari 10.000 domain teratas di internet. Tidak jelas apakah ini adalah kebijakan penolakan layanan yang disengaja terhadap domain spesifik ini—mirip dengan sensor yang terkenal di dunia di China—atau mungkin hanya contoh implementasi teknis yang buruk dari sistem apa pun yang mencegat permintaan DNS.

Tidak mengetahui mengapa DNS dicegat itu penting: Bahkan jika kita mengesampingkan pertanyaan moral dan hukum tentang pengawasan menyeluruh dan sensor, teknologi yang digunakan untuk melakukan ini—pada dasarnya—tidak sesuai standar dan bisa sangat mengganggu penggunaan internet Anda yang normal, sehari-hari, wajar, dan sah.

Namun dari sudut pandang teknis, kerentanan tetap ada.

Memecah Internet untuk Tujuan Jahat

Tentu saja, bukan hanya entitas komersial dan pemerintah yang mencoba mencegat lalu lintas internet dengan cara mereka sendiri. Ada banyak contoh penjahat yang mencoba membajak koneksi, biasanya untuk tujuan mencuri data pengguna atau menipu pengguna agar mengungkapkan kredensial akses penting. Yang paling menonjol, keracunan cache DNS telah digunakan untuk mengarahkan pengguna ke situs phishing, menyebarkan ransomware, menyebarkan botnet, menolak layanan ke situs web tertentu, dan banyak lagi.

TLS Membocorkan Siapa yang Menghubungkan ke Siapa

Transport Layer Security (TLS) adalah teknologi di balik HTTPS, versi aman dari HTTP yang kita semua andalkan setiap hari. Membangun koneksi TLS memerlukan sejumlah langkah, selama waktu itu server membuktikan identitasnya dengan menunjukkan sertifikat, dan kunci enkripsi baru dipertukarkan.

Meminta server menggunakan sertifikat untuk membuktikan identitasnya adalah langkah yang sangat penting, karena bagian dari sertifikat adalah kunci enkripsi publik asimetris.

Ketika klien mengirim pesan menggunakan kunci ini, hanya server yang memiliki kunci pribadi terkait yang dapat membaca pesan. Akibatnya, siapa pun yang mencegat atau mendengarkan sambungan akan terkunci dan tidak dapat membaca konten.

Namun, pertukaran awal itu masih dilakukan secara clear tanpa enkripsi, yang berarti bahwa seorang pengamat akan selalu mengetahui identitas server.

Fronting Domain

Beberapa alat jenis anti-sensor mengatasi kebocoran ini di TLS untuk jangka waktu tertentu menggunakan teknik yang dikenal sebagai domain fronting. Ini mengeksploitasi fakta bahwa setelah koneksi HTTPS dibuat, sebagian besar penyedia hosting besar tidak memeriksa untuk melihat apakah nama host yang disajikan di setiap permintaan HTTP cocok dengan yang digunakan dalam handshake TLS. Dalam hal alat privasi, ini dilihat sebagai fitur yang berguna yang memungkinkan komunikasi rahasia dengan situs tersembunyi. Untuk penyedia hosting dan pengumpul data, ini dianggap sebagai penyalahgunaan cara spesifikasi diterapkan.

Ini dengan sendirinya merupakan kerentanan, dan karena itu telah diperbaiki oleh beberapa penyedia hosting utama, termasuk AWS.

Memecahkan Masalah dengan Mengubah Standar: SNI Terenkripsi (ESNI)

Ide di balik ESNI adalah untuk mencegah TLS membocorkan data apa pun dengan mengenkripsi semua pesan, termasuk pesan Client Hello awal. Ini membuat pengamat sama sekali tidak mengetahui tentang sertifikat server apa yang disajikan server.

Untuk melakukan ini, klien memerlukan kunci enkripsi sebelum membuat koneksi. Oleh karena itu, ESNI memerlukan satu set khusus kunci enkripsi ESNI untuk ditempatkan dalam catatan SRV di DNS.

Namun, detail pasti dari ini masih dalam perubahan, karena spesifikasinya belum diselesaikan. Meskipun demikian, implementasi ESNI telah dimasukkan ke dalam produksi oleh Mozilla Firefox dan Cloudflare.

Mengamankan dan Mengenkripsi DNS

Agar kunci ESNI dikirimkan tanpa dicegat, penting untuk melindungi dari gangguan DNS.

Sejak 1993, komunitas internet telah mencoba mengamankan DNS. IETF mencatat bahwa pertemuan pemecahan masalah awal membahas:

1. Melindungi dari pengungkapan data DNS kepada pihak yang tidak berwenang
2. Memastikan integritas data
3. Otentikasi asal data

Pertemuan ini menghasilkan standar Domain Name System Security Extensions (DNSSEC) pada tahun 1997. Standar tersebut memilih untuk mengatasi dua dari tiga masalah ini, karena tim desain membuat keputusan eksplisit untuk mengatur semua ancaman pengungkapan data secara eksplisit di luar cakupan.

Dengan demikian, DNSSEC berarti bahwa pengguna dapat mempercayai bahwa jawaban atas kueri DNS mereka sesuai dengan keinginan pemilik domain. Dalam konteks ESNI, ini berarti kita tahu bahwa kunci yang kita terima belum diubah, dan untungnya, banyak kerentanan yang disebutkan di atas hilang saat DNSSEC digunakan. Namun, itu tidak menjamin privasi dan karena itu masih rentan terhadap masalah yang ditimbulkan oleh sistem pengawasan dan sensor.

Sayangnya, karena sepenuhnya kompatibel dengan "DNS tidak aman" dan cukup sulit untuk diterapkan dengan benar, adopsi DNSSEC sangat rendah. Banyak pemilik domain menyerah di tengah jalan untuk mencoba mengonfigurasinya, sebagaimana dibuktikan oleh banyak konfigurasi yang tidak valid dan setengah penyiapan yang terlihat di alam liar.

DNS melalui HTTPS (DoH)

Agar kunci ESNI dikirimkan tanpa pengamat mengetahui situs mana yang coba dikunjungi pengguna, penting untuk melindungi dari penyadapan DNS. Dengan demikian, cukup logis dan dapat dimengerti untuk mengatakan bahwa DNS terenkripsi (seperti dengan DoH) adalah hal yang baik. Namun, seperti yang ada sekarang, DNS tidak dienkripsi.

Ada langkah Mozilla, Google, APNIC, Cloudflare, Microsoft, dan lainnya untuk mengubah ini.

Pengalaman Pengguna Terenkripsi yang Ideal

Pengguna yang ingin memanfaatkan teknologi di atas mungkin memiliki daftar persyaratan yang agak panjang terkait detail UX praktis dalam bekerja dengan enkripsi. Kemungkinan, mereka ingin menghindari hal-hal seperti:

• Dipaksa menggunakan penyedia layanan DNS tertentu (tidak peduli seberapa bagusnya itu) atau agar pilihannya tidak terlihat atau sulit ditemukan
• Setiap aplikasi pada perangkat yang menangani DNS secara berbeda (misalnya, Firefox dapat menemukan hal-hal yang tidak dapat dilakukan Safari)
• Semua aplikasi di perangkat harus membuat implementasi DNS amannya sendiri di dalamnya
• Harus mengonfigurasi DNS secara manual beberapa kali
• Harus memilih privasi dan keamanan
• Aplikasi jatuh kembali ke operasi tidak aman tanpa persetujuan pengguna

Pengguna yang sadar privasi malah menginginkan:

• Privasi dari pengawasan yang tidak beralasan oleh siapa pun
• Perlindungan dari iklan bertarget yang tidak mereka setujui
• Perlindungan konten yang mereka publikasikan sendiri (misalnya, di situs web pribadi) agar tidak diubah atau dimanipulasi dalam perjalanan ke pemirsa lain
• Jaminan bahwa pemirsa dari konten yang mereka terbitkan sendiri tidak akan mendapat masalah hanya karena mengaksesnya
• Untuk terus memiliki opsi untuk mengontrol DNS di jaringan mereka sendiri (karena terkadang, DNS split-horizon bagus untuk menjaga sumber daya internal yang dicakup untuk pengguna internal)
• Kemampuan untuk ikut serta, atau setidaknya menyisih dari, pemfilteran pada tingkat DNS (mis., Quad9, CleanBrowsing, dan OpenDNS Family Shield)
• Konfigurasi yang mudah dan tidak merepotkan (yaitu, DHCP)
• Diminta untuk menyetujui penggunaan DNS tanpa enkripsi
• Perlindungan tidak hanya untuk lalu lintas browser, tetapi untuk semua jenis lalu lintas, misalnya, email, Slack, VoIP, SSH, VPN, dll.

Upaya Enkripsi Saat Ini

Opsi apa yang tersedia untuk pengguna dengan tujuan di atas?

Solusi Mozilla adalah permulaan, tetapi jauh dari ideal. Mereka hanya mengamankan Firefox; defaultnya adalah mengesampingkan pengaturan OS Anda demi penyedia pilihan mereka (Cloudflare) tanpa mengatakan demikian, dan secara diam-diam kembali menjadi tidak aman (dalam kasus DNS terenkripsi diblokir, dll.)

Solusi Google adalah pendekatan yang lebih baik. Mereka mengamankan Android 9+—yang berlaku untuk semua aplikasi. (Saya tidak yakin dengan rencana mereka untuk Chrome OS, tapi saya curiga itu sedang berjalan.) Mereka juga mengamankan Chrome di semua platform, tetapi itu hanya memicu keamanan ketika platform host dikonfigurasi untuk menggunakan penyedia yang mendukung keamanan. Ini bagus dalam hal pilihan pengguna, tetapi tidak ideal karena diam-diam kembali menjadi tidak aman.

Semua browser utama lainnya juga menerapkan dukungan.

Dalam situasi yang ideal bagi pengguna, komunitas pengembang perangkat lunak dan OS yang lebih luas akan:

1. Berhenti menerapkan fitur keamanan DNS baru di tingkat aplikasi
2. Mulai menerapkannya di level OS
3. Hormati konfigurasi tingkat OS, atau dapatkan persetujuan pengguna

Menerapkan DNS terenkripsi di tingkat OS, kami dapat terus mengikuti model terdistribusi yang sama yang kami miliki saat ini untuk resolver DNS. Menjalankan server DNS sendiri di jaringan mereka sendiri, dan mampu membuat resolver itu aman, masuk akal untuk terus menjadi pilihan, sebagaimana seharusnya menggunakan penyedia terpusat.

Linux dan BSD sudah memiliki fungsi ini dengan berbagai pilihan yang tersedia. Sayangnya, tidak ada distro yang mengaktifkannya secara default, sejauh yang saya tahu. Lihat nss-tls jika Anda menginginkan sesuatu yang hanya akan dicolokkan ke glibc.

Implementasi DNS-over-TLS Google di Android 9+ juga sudah melakukan ini. Ini berfungsi dengan menguji server DNS untuk dukungan enkripsi. Jika memilikinya, maka ia akan menggunakannya. Jika tidak, maka—seperti halnya Chrome—itu berlanjut dengan cara yang tidak aman, tanpa meminta persetujuan.

Perlu dicatat bahwa sebagian besar jaringan dikonfigurasi untuk menggunakan server DNS yang tidak mendukung enkripsi, sehingga solusi yang ada di Android belum mengubah apa pun untuk sebagian besar pengguna. Mungkin akan lebih baik untuk menawarkan kembali ke DNS terenkripsi terpusat dalam kasus di mana desentralisasi tidak mendukung enkripsi.

Untuk perangkat rasa Apple dan Microsoft, dukungan untuk DNS terenkripsi belum secara resmi tiba pada tulisan ini. Dengan Microsoft yang mengumumkan pada November 2019 niat mereka untuk mendukung DNS terenkripsi, semoga Apple segera menyusul.

Solusi DNS Terenkripsi

Ada beberapa solusi dalam bentuk proxy yang dapat dijalankan secara lokal. Dengan ini, komputer pengguna berbicara DNS non-terenkripsi untuk dirinya sendiri, yang kemudian berbicara DNS terenkripsi ke penyedia apa pun yang dikonfigurasi untuk digunakan. Ini bukan solusi ideal, tetapi seiring berjalannya waktu, ini layak.

Inspirasi untuk menulis artikel ini adalah proxy DNSCrypt, yang sangat stabil, memiliki banyak lonceng dan peluit, dan bersifat lintas platform. Ini mendukung protokol DNSCrypt yang lebih lama, serta protokol DNS over TLS (DoT) dan DNS over HTTPS (DoH) yang lebih baru.

Untuk pengguna Windows, ada penginstal dan GUI bernama Simple DNSCrypt, yang fiturnya lengkap dan sangat mudah digunakan.

Saya merekomendasikannya, tetapi ketahuilah bahwa dunia mungkin belum siap untuk Anda, dan Anda mungkin perlu menonaktifkannya dari waktu ke waktu (misalnya, ketika Anda harus menggunakan portal captive di kafe favorit Anda, atau di LAN berpesta).

Pilihan lain

Selain itu, ada Technitium DNS Server, yang mendukung DNS terenkripsi, bersifat lintas platform (Windows, MacOS, Linux pada ARM/Raspberry Pi), dan menampilkan antarmuka web yang apik. Itu berada di bawah "lainnya" karena ini lebih merupakan alat serba guna daripada solusi khusus untuk masalah ini. (Ini kemungkinan akan menjadi pilihan yang baik jika Anda ingin menjalankan server DNS Raspberry Pi Anda di rumah. Saya akan tertarik untuk mendengar umpan balik dari orang-orang yang mencobanya di komentar di bawah.)

Untuk perangkat Android atau iOS (iPhone, iPad, dll.), ada juga aplikasi 1.1.1.1, yang akan memaksa semua permintaan DNS Anda melalui layanan DNS Terenkripsi Cloudflare. Saya mendengar bahwa ada aplikasi yang lebih fleksibel juga, seperti Intra, tetapi saya belum menghabiskan waktu untuk mengujinya.

Tentu saja, Anda juga dapat mengaktifkan DNS terenkripsi di Firefox dan Chrome - ingatlah semua peringatan yang dibahas di atas.

Keandalan DNS: Pekerjaan Nomor Satu

Ada banyak kontroversi dengan teknologi privasi internet. Namun, ketika menerapkan langkah-langkah keamanan dan privasi, teknologi yang dimaksud bukan terutama tentang menjaga rahasia. Ini tentang memastikan keandalan dan menjamin bahwa teknologi terus berfungsi dengan benar terlepas dari perilaku orang lain. Namun, kita perlu menyadari bahwa, seperti halnya teknologi tanpa perlindungan privasi itu buruk, perlindungan yang diterapkan dengan buruk hanya dapat memperburuk situasi.