HTTPS DNS - Solusi Setengah dan Salah

Sepanjang keberadaan Internet, keterbukaan telah menjadi salah satu karakteristik yang menentukan, dan sebagian besar lalu lintas saat ini masih ditransmisikan tanpa enkripsi. Sebagian besar permintaan untuk halaman HTML dan konten terkait dibuat dalam teks biasa, dan respons dikembalikan dengan cara yang sama, terlepas dari kenyataan bahwa protokol HTTPS telah ada sejak 1994.

Namun, terkadang ada kebutuhan untuk keamanan dan / atau kerahasiaan. Meskipun enkripsi lalu lintas Internet tersebar luas di bidang-bidang seperti perbankan online dan belanja, masalah menjaga kerahasiaan di banyak protokol Internet tidak begitu cepat diselesaikan. Khususnya, ketika menanyakan alamat IP suatu situs untuk suatu host, permintaan DNS hampir selalu dikirim dalam teks yang jelas, yang memungkinkan semua komputer dan penyedia untuk menentukan situs mana yang Anda kunjungi, bahkan jika Anda menggunakan HTTPS setelah membuat koneksi.

Gagasan bahwa enkripsi juga diperlukan untuk permintaan DNS bukanlah hal baru, dan upaya pertama dilakukan pada tahun 2000-an - DNSCrypt, DNS over TLS (DoT), dll. Mozilla, Google dan perusahaan Internet besar lainnya sedang mempromosikan metode baru mengenkripsi permintaan DNS : DNS over HTTPS (DoH).

DoH tidak hanya mengenkripsi kueri DNS, tetapi juga mentransfernya ke server web "biasa", bukan server DNS, yang membuat lalu lintas DNS mustahil dibedakan dari HTTPS biasa. Koin ini memiliki dua sisi. Prosedur ini melindungi permintaan DNS itu sendiri, seperti DNSCrypt atau DoT, dan juga membuat orang-orang dari layanan keamanan perusahaan-perusahaan besar tidak dapat melacak spoofing DNS , dan mentransfer tanggung jawab untuk fungsi-fungsi jaringan penting dari OS ke aplikasi. Dan juga itu tidak membantu dengan cara apa pun menyembunyikan alamat IP situs web yang baru saja Anda minta - lagipula, Anda tetap pergi ke sana.

Dibandingkan dengan DoT, DoH memusatkan informasi tentang situs yang Anda kunjungi di beberapa perusahaan: hari ini adalah Cloudflare, yang berjanji untuk menyingkirkan data Anda dalam 24 jam, dan Google, yang bermaksud untuk menyimpan dan memonetisasi semua detail dari semua hal yang pernah Anda rencanakan untuk lakukan.

DNS dan privasi adalah topik penting, jadi mari kita mempelajari detailnya.

Server DNS dan kepercayaan

Konsep sistem nama domain tanggal kembali ke ARPANET , ketika satu-satunya file teks pada setiap node ARPANET - dengan nama HOSTS.TXT - berisi semua korespondensi antara nama-nama sistem yang terhubung ke ARPANET dan alamat digitalnya. Saat Anda mengisi ulang file ini sendiri, mudah untuk memverifikasi apakah itu benar. Dengan pertumbuhan jaringan, menjadi tidak realistis untuk mempertahankan salinan pusat dan lokal dari file-file ini. Pada awal 1980-an, upaya sudah mulai membuat sistem otomasi untuk proses ini.

Server nama depan (Berkeley Internet Name Domain Server atau BIND) ditulis pada tahun 1984 oleh sekelompok mahasiswa di University of California, Berkeley, berdasarkan RFC 882 dan RFC 883. Pada tahun 1987, standar DNS direvisi beberapa kali, yang mengarah pada munculnya RFC 1034 dan RFC 1035 yang sejak saat itu pada umumnya tidak berubah.



Dasar dari struktur DNS adalah struktur pohonnya, di mana node dan daun dibagi menjadi zona-zona. Zona root DNS adalah tingkat atas, yang terdiri dari tiga belas kelompok server root yang membentuk server DNS root resmi. Server DNS baru apa pun (yang diangkat oleh penyedia atau perusahaan) menerima catatan DNS dari setidaknya salah satu dari server utama ini.

Setiap zona DNS berikutnya menambahkan domain lain ke sistem nama. Biasanya, setiap negara memiliki domain sendiri, dan domain .org atau .com yang tidak terkait dengan negara disajikan secara terpisah. Kueri untuk nama host melalui DNS dimulai dengan nama domain (misalnya, .com), kemudian dengan nama (misalnya, google), diikuti oleh subdomain yang memungkinkan. Jika data belum mencapai cache, untuk menyelesaikan permintaan, Anda mungkin perlu melakukan beberapa transisi melalui zona DNS.

DNSSEC: menambah kepercayaan pada sistem DNS

Sebelum melanjutkan ke enkripsi permintaan DNS, Anda harus memastikan bahwa kami dapat mempercayai server DNS. Kebutuhan ini menjadi jelas pada 1990-an, dan mengarah pada perluasan operasional pertama ke Standar Keamanan DNS (DNSSEC), RFC 2353, dan RFC 4033 yang direvisi (DNSSEC-bis).


Peta internet 2006

DNSSEC bekerja dengan menandatangani catatan permintaan DNS dengan kunci publik. Keaslian catatan DNS dapat dikonfirmasi oleh kunci publik dari zona root DNS, yang merupakan pihak ketiga tepercaya dalam skenario ini. Pemilik domain menghasilkan kunci mereka, ditandatangani oleh operator zona dan ditambahkan ke DNS.

Meskipun DNSSEC memungkinkan Anda untuk relatif yakin bahwa jawaban dari server DNS adalah nyata, protokol ini harus disertakan dalam OS. Sayangnya, beberapa OS menerapkan layanan DNS yang dapat melakukan lebih dari sekadar "tahu tentang DNSSEC" —yaitu, mereka tidak benar-benar mengkonfirmasi respons DNS. Jadi, hari ini Anda tidak dapat memastikan bahwa jawaban yang Anda terima dari DNS adalah nyata.

Masalah dengan DoH

Misalkan Anda menggunakan DNSSEC. Anda siap mengenkripsi pesan untuk menambahkan privasi ke transfer data Anda. Mungkin ada banyak alasan untuk menjaga kerahasiaan pertanyaan DNS. Di antara yang paling tidak bersalah adalah melewati filter korporasi dan penyedia, melarang pelacakan kebiasaan internet, dan sebagainya. Di antara yang lebih serius adalah upaya untuk menghindari penganiayaan oleh pemerintah karena mengekspresikan pandangan politik di Internet. Secara alami, enkripsi permintaan DNS tidak memungkinkan orang untuk memata-matai pertanyaan ini, tetapi sebagai hasilnya, masalah yang lebih besar dengan keamanan DNS dan, tentu saja, semua protokol komunikasi lainnya diabaikan.

Pesaing utama di sini adalah DoT menggunakan TLS dan DoH menggunakan HTTPS. Perbedaan yang paling jelas antara keduanya adalah port: DoT berjalan pada port TCP khusus 853, dan DoH bercampur dengan lalu lintas HTTPS lain pada port 443. Ini memberikan keuntungan kontroversial membuat kueri DNS tidak dapat dibedakan dari lalu lintas lain, yang membuatnya tidak mungkin untuk operator jaringan (swasta dan perusahaan) ) amankan jaringan Anda sendiri, seperti yang diumumkan Paul Vixie, salah satu arsitek DNS di Twitter tahun lalu.

Yang kedua dari perbedaan utama adalah bahwa jika DoT hanya mengirim permintaan DNS melalui TLS, maka DoH pada dasarnya adalah DNS-over-HTTP-over-TLS, memerlukan aplikasi Jenis Media sendiri / pesan-dns-pesan, dan membuat segalanya menjadi lebih rumit. Mencampur DoH dengan protokol yang ada menyebabkan setiap permintaan dan respons DNS melewati tumpukan HTTPS. Ini adalah mimpi buruk untuk aplikasi tertanam dan juga tidak kompatibel dengan hampir semua jenis peralatan yang ada.

DoT memiliki keunggulan lain - protokol ini telah diterapkan, dan jauh lebih lama daripada DoH ada, digunakan oleh perusahaan-perusahaan seperti Cloudflare, Google, serta penyedia internet lokal; perangkat lunak server standar seperti BIND menggunakan DoT langsung dari kotak. Pada OS Android Pie (versi 9), DNS over TLS akan digunakan secara default jika server DNS yang dipilih mendukung DoT.

Mengapa beralih ke DoH jika DoT sudah diluncurkan? Jika aplikasi non-standar seperti Firefox mem-bypass sistem DNS berbasis DoT dan menggunakan sistem pencarian nama domain mereka sendiri melalui DoH, maka situasi ini akan menjadi sangat sulit dari sudut pandang keamanan. Mentransfer DNS ke aplikasi individual, yang sedang terjadi sekarang, sepertinya merupakan langkah mundur. Apakah Anda tahu metode DNS mana yang digunakan setiap aplikasi? Apakah Anda tahu bahwa itu mencampur proses ini dengan lalu lintas TCP pada port 443?

Enkripsi tidak mengganggu pengintaian

Dua perusahaan besar, Cloudflare dan Mozilla, singkatan dari DNS over HTTPS, dan yang terakhir bahkan merilis strip komik kecil yang bagus , di mana ia mencoba menjelaskan skema DoH. Tidak mengherankan, mereka sama sekali tidak menyebut DNSSEC (meskipun disebut "kritis" di RFC 8484), dan alih-alih menawarkan sesuatu yang disebut Trusted Recursive Resolver (TRR), yang pada dasarnya merupakan saran "gunakan tepercaya" DNS Server ”dimana Mozilla berarti Cloudflare.

Selain DoH, mereka menyebutkan standar minimalisasi QNAME ( RFC 7816 ), yang harus mengurangi jumlah informasi tidak penting yang dikirim oleh server DNS. Pada saat yang sama, standar ini tidak bergantung pada DoH dengan cara apa pun dan akan berfungsi tanpa enkripsi DNS. Seperti halnya DNSSEC, keamanan dan privasi ditingkatkan melalui evolusi standar DNS.

Yang paling menarik terdapat di bagian "Apa yang tidak diperbaiki TRR + DoH"? Seperti yang dikatakan banyak pakar, enkripsi DNS tidak mencegah pengintaian. Segala permintaan selanjutnya ke alamat IP yang diterima dengan cara yang sangat rahasia akan tetap terlihat jelas. Semua sama, mereka akan tahu bahwa Anda telah mengunjungi Facebook.com, atau situs untuk pembangkang. Tidak ada enkripsi DNS atau lalu lintas Internet yang akan menyembunyikan informasi penting untuk pengoperasian jaringan seperti Internet.

Akankah Internet di masa depan menjadi titik kegagalan tunggal?

Mozilla menawarkan untuk menangani masalah IP snooping hanya dengan menyatakan bahwa ini bukan masalah melalui penggunaan Cloud. Semakin banyak situs web dan jaringan distribusi konten (CDN) menggantung pada sejumlah kecil layanan (Cloudflare, Azure, AWS, dll.), Semakin sedikit alamat IP ini berarti - Anda hanya perlu percaya bahwa yang dipilih layanan cloud Anda tidak akan mencuri data Anda dan tidak akan jatuh selama sehari.

Tahun ini, 24 Juni, ada penurunan besar dalam layanan, ketika kesalahan konfigurasi yang dibuat oleh penyedia Verizon membuat Cloudflare, Amazon, Linode dan banyak lainnya tidak tersedia untuk sebagian besar hari itu. Pada 2 Juli tahun ini , Cloudflare jatuh sekitar setengah jam, dan dengan itu banyak situs web yang mengandalkan layanannya.

Secara kebetulan, layanan cloud Microsoft Office365 juga berbaring selama beberapa jam pada hari itu, itulah sebabnya banyak pengguna tidak dapat menggunakan layanannya. Pada akhir pekan sebelum Hari Buruh [Hari libur nasional AS dirayakan pada hari Senin pertama bulan September / sekitar. trans.] kegagalan daya di pusat data AWS US-East-1 menyebabkan terabyte data pelanggan yang tersimpan di sana ditutupi dengan baskom tembaga . Jelas, masih ada beberapa kelemahan pada gagasan manfaat memusatkan Internet.

Lagu-lagu lama dengan cara baru

Hebatnya, tidak ada menyebutkan jaringan pribadi virtual (VPN) sepanjang diskusi tentang privasi dan pelacakan ini. Mereka memecahkan masalah dengan enkripsi data dan permintaan DNS, dengan menyembunyikan alamat IP dan banyak lagi, hanya dengan memindahkan titik di mana PC Anda atau perangkat lain yang terhubung ke Internet terhubung ke Internet. Pembangkang dalam rezim otoriter telah menggunakan VPN selama beberapa dekade untuk menghindari sensor internet; VPN, termasuk fitur khusus seperti Tor, adalah elemen penting kebebasan Internet.


Bagaimana cara kerja Tor

Jika Anda mempercayai perusahaan komersial besar seperti Cloudflare dalam skema seperti DoH, maka menemukan penyedia VPN tepercaya yang tidak menyimpan atau menjual data Anda akan mudah. Dan browser Opera umumnya memiliki dukungan proxy bawaan gratis, yang menawarkan banyak manfaat VPN .

Pada akhirnya, kita dapat mengatakan bahwa DoH mengkonfirmasi akronimnya, berkinerja buruk bahwa DoT sudah bekerja dengan baik [“Doh!” - tanda seru yang menunjukkan kebodohan dari tindakan yang sempurna, terutama tindakan sendiri / kira-kira. diterjemahkan.]. Kita perlu lebih fokus pada implementasi DNSSEC di mana-mana, bersama dengan DoT dan meminimalkan QNAME. Dan jika Anda peduli dengan privasi nyata, maka Anda harus beralih ke VPN.