Ancaman terhadap privasi dan keamanan di Internet menjadi lebih serius. Kami di Mozilla mengikuti mereka dengan cermat. Kami menganggap itu tugas kami untuk melakukan segala yang mungkin untuk melindungi pengguna Firefox dan data mereka.
Kami khawatir tentang perusahaan dan organisasi yang secara diam-diam mengumpulkan dan menjual data pengguna. Oleh karena itu, kami menambahkan
perlindungan pelacakan dan membuat
ekstensi wadah Facebook . Lebih banyak tindakan perlindungan akan muncul dalam beberapa bulan mendatang.

Sekarang kami menambahkan dua teknologi lagi ke daftar:
- HTTPS DNS adalah standar IETF baru yang kami ambil bagian dalam pengembangan
- Penyelesai Rekursif Tepercaya - cara aman baru untuk menyelesaikan DNS, disediakan bersama dengan Cloudflare
Berkat dua inisiatif ini, kebocoran data yang telah menjadi bagian dari sistem nama domain sejak awal 35 tahun yang lalu telah dieliminasi. Dan kami membutuhkan bantuan Anda dalam pengujian. Mari kita lihat bagaimana HTTPS DNS dan Trusted Recursive Resolver melindungi pengguna kami.
Tetapi pertama-tama, mari kita lihat bagaimana halaman web dikirimkan melalui Internet.
Jika Anda sudah tahu cara kerja DNS dan HTTPS, Anda dapat beralih ke topik tentang bagaimana
DNS membantu melalui HTTPS .
Kursus Singkat HTTP
Ketika orang menjelaskan bagaimana browser memuat halaman web, mereka biasanya menjelaskannya seperti ini:
- Browser Anda membuat permintaan GET ke server.
- Server mengirimkan respons, yang merupakan file yang berisi HTML.

Sistem ini disebut HTTP.
Tetapi skema ini terlalu disederhanakan. Browser Anda tidak berbicara langsung ke server. Mungkin karena mereka tidak dekat satu sama lain.
Server dapat berjarak ribuan kilometer. Dan mungkin tidak ada koneksi langsung antara komputer Anda dan server.

Jadi, sebelum permintaan masuk dari browser ke server, ia akan melewati beberapa tangan. Hal yang sama berlaku untuk jawabannya.
Saya menganggapnya sebagai anak sekolah yang saling menyampaikan catatan di kelas. Di luar, catatan itu mengatakan kepada siapa itu dimaksudkan. Anak yang menulis catatan itu akan menyerahkannya kepada tetangga. Kemudian anak berikutnya menyerahkannya ke salah satu tetangga - mungkin bukan ke penerima akhir, tetapi ke seseorang yang berada di arah yang benar.
- Psst ... berikan ini pada SandyMasalahnya adalah bahwa siapa pun di sepanjang jalan dapat membuka catatan dan membacanya. Dan tidak ada cara untuk mengetahui sebelumnya ke mana surat itu akan pergi, jadi tidak diketahui orang mana yang akan mendapatkan akses ke sana.
Mungkin ada di tangan orang-orang yang akan melakukan hal-hal berbahaya ...
Misalnya, mereka akan membagikan konten catatan kepada semua orang.
- Oh, berair ... Hai teman-teman! Danny jatuh cinta pada Sandy!Atau ubah jawabannya.
"Apakah kamu juga menyukaiku?"
- Hehe, aku akan mengolok-oloknya dan menulis "Tidak" ...Untuk mengatasi masalah ini, versi HTTP aman baru telah dibuat. Ini disebut HTTPS: itu seperti kunci pada setiap pesan.

Hanya browser dan server yang tahu kombinasi untuk membuka kunci. Sekalipun pesan melewati beberapa router, hanya Anda dan situs web yang benar-benar dapat membaca kontennya.
Ini memecahkan banyak masalah keamanan. Tetapi masih ada pesan yang tidak terenkripsi antara browser Anda dan server. Jadi, orang-orang di jalan masih bisa mengganggu urusan Anda.
Misalnya, data masih terbuka selama pengaturan koneksi. Saat mengirim pesan asli ke server, Anda juga mengirim nama server di bidang “Indikasi Nama Server”. Ini memungkinkan operator server untuk menjalankan beberapa situs di komputer yang sama dan pada saat yang sama memahami siapa yang ingin Anda hubungi. Permintaan awal ini adalah bagian dari pengaturan enkripsi, tetapi permintaan awal itu sendiri tidak dienkripsi.
Tempat lain di mana data terbuka adalah DNS. Tapi apa itu DNS?
DNS: Sistem Nama Domain
Dalam sebuah metafora untuk memberikan catatan di kelas, saya mengatakan bahwa nama penerima harus ditulis di luar catatan. Hal yang sama berlaku untuk permintaan HTTP ... mereka harus menyatakan ke mana mereka akan pergi.
Tetapi Anda tidak dapat menggunakan nama situs yang biasa. Tidak ada router yang mengerti siapa yang Anda bicarakan. Sebaliknya, gunakan alamat IP. Inilah cara router memahami server mana yang ingin Anda kirimi permintaan.
- Silakan kirim ini ke 208.80.154.224Ini menyebabkan masalah. Tidak nyaman bagi pengguna untuk mengingat nomor alamat IP. Saya ingin memberikan situs nama yang menarik ... yang akan disimpan dalam memori orang.
Itu sebabnya kami memiliki sistem nama domain (DNS). Browser Anda menggunakan DNS untuk menyelesaikan nama situs ke alamat IP. Proses ini - mengonversi nama domain menjadi alamat IP - disebut resolusi atau penyelesaian nama domain.

Bagaimana cara browser mengatasi masalah?
Salah satu opsi adalah membuat daftar besar seperti direktori telepon di browser. Tetapi ketika situs web baru muncul atau pindah ke server baru, akan sulit untuk tetap memperbarui daftar ini.
Jadi, alih-alih daftar tunggal untuk semua nama domain, ada banyak daftar kecil yang saling terkait. Ini memungkinkan mereka untuk dikontrol secara independen.

Untuk mendapatkan alamat IP yang sesuai dengan nama domain, Anda perlu menemukan daftar spesifik yang berisi nama domain yang diinginkan. Ini seperti menemukan harta karun.
Seperti apa tampilan pencarian harta untuk situs seperti Wikipedia bahasa Inggris,
en.wikipedia.org
?
Domain dapat dibagi menjadi beberapa bagian.

Dengan bagian-bagian seperti itu, Anda dapat mulai mencari daftar yang berisi alamat IP situs. Tapi kami butuh bantuan untuk menemukannya. Alat yang melakukan perburuan ini alih-alih kami dan menemukan alamat IP disebut resolver.
Pertama, resolver mengakses apa yang disebut root DNS server. Dia tahu beberapa server DNS root berbeda, jadi dia mengirim permintaan ke salah satunya. Penyelesai meminta DNS root tempat mencari informasi tambahan tentang alamat di zona domain tingkat atas
.org
.
- Anda tidak tahu bagaimana menuju ke en.wikipedia.org?
- Saya tidak tahu apa-apa di zona .org, tetapi 5.6.7.8 dapat membantuServer berikutnya disebut server nama domain tingkat atas (TLD). Server TLD tahu tentang semua domain tingkat kedua yang berakhiran
.org
.
Namun, dia tidak tahu apa-apa tentang subdomain
wikipedia.org
, jadi dia juga tidak tahu alamat IP
en.wikipedia.org
.
Server nama TLD akan menyarankan resolver untuk mengajukan pertanyaan ini ke server nama Wikipedia.
- Anda tidak tahu bagaimana menuju ke en.wikipedia.org?
- Pergi dan tanyakan 11.21.31.41, dia tahu tentang situs-situs di domain wikipedia.orgPenyelesai hampir selesai. Server nama Wikipedia adalah apa yang disebut server otoritatif. Dia tahu tentang semua subdomain di
wikipedia.org
. Dengan demikian, dia tahu tentang
en.wikipedia.org
dan subdomain lainnya, seperti versi Jerman dari
de.wikipedia.org
. Server otoritatif memberi tahu resolver tempat alamat IP file HTML dapat diambil untuk situs ini.
- Anda tidak tahu bagaimana menuju ke en.wikipedia.org?
- Oh ya, langsung saja ke 208.80.154.224Penyelesai akan mengembalikan alamat IP
en.wikipedia.org
ke sistem operasi.
Proses ini disebut resolusi rekursif karena Anda harus bolak-balik, menanyakan server yang berbeda pada dasarnya pertanyaan yang sama.
Saya mengatakan bahwa kami membutuhkan resolver untuk membantu pencarian. Tetapi bagaimana browser menemukan resolver ini? Secara umum, ia menanyakan sistem operasi.
"Aku butuh resolver." Bisakah kamu membantu
- Tentu saja, izinkan saya memperkenalkan Anda kepada resolver yang saya gunakanBagaimana sistem operasi mengetahui resolver mana yang harus digunakan? Ada dua cara yang mungkin.
Anda
dapat mengonfigurasi komputer Anda untuk menggunakan resolver tertentu yang Anda percayai. Tetapi sangat sedikit orang melakukan ini.
Sebagai gantinya, sebagian besar hanya menggunakan pengaturan default. Dan secara default, OS akan menggunakan resolver apa pun yang dikatakan jaringan. Ketika komputer terhubung ke jaringan dan menerima alamat IP-nya, jaringan merekomendasikan resolver tertentu.
- Bolehkah saya mendapatkan alamat IP?
- Tidak masalah! Dan jika Anda membutuhkan resolver, saya merekomendasikan yang iniIni berarti bahwa resolver yang digunakan dapat diubah beberapa kali sehari. Jika Anda menuju ke sebuah kafe untuk bekerja di siang hari, Anda mungkin menggunakan resolver yang berbeda dari di pagi hari. Dan ini terjadi bahkan jika Anda mengatur resolver Anda sendiri, karena tidak ada keamanan dalam protokol DNS.
Bagaimana saya bisa mengeksploitasi DNS?
Jadi bagaimana sistem ini membahayakan pengguna?
Biasanya, resolver memberi tahu setiap server DNS domain mana yang Anda cari. Permintaan ini terkadang menyertakan alamat IP lengkap Anda. Dan jika bukan alamat lengkap, maka lebih sering permintaan mencakup sebagian besar alamat IP Anda, yang dapat dengan mudah digabungkan dengan informasi lain untuk menetapkan identitas Anda.
Berisi sebagian besar alamat IP Anda ...
... dan domain lengkap yang Anda cariIni berarti bahwa setiap server yang Anda minta bantuan dengan resolusi nama domain melihat situs apa yang Anda cari. Selain itu, siapa pun dalam perjalanan ke server ini juga melihat permintaan Anda.
Ada beberapa cara di mana sistem semacam itu membahayakan data pengguna. Dua yang utama adalah pelacakan (tracking) dan spoofing (spoofing).
Pelacakan
Seperti yang saya katakan di atas, tidak sulit untuk menentukan identitas orang yang meminta akses ke situs tertentu menggunakan informasi lengkap atau sebagian tentang alamat IP. Ini berarti bahwa server DNS dan pengguna mana pun dalam perjalanan ke server DNS ini (router di jalan) dapat membuat profil pengguna. Mereka dapat membuat daftar semua situs yang Anda lihat.
Dan ini adalah data yang berharga. Banyak orang dan perusahaan bersedia membayar banyak untuk melihat riwayat penelusuran Anda.
Berapa banyak yang bersedia Anda bayar untuk informasi tentang apa yang dilihat John Doe?Meskipun kami tidak perlu khawatir tentang server atau router DNS yang berpotensi terkenal, masih ada risiko bahwa data Anda akan dikumpulkan dan dijual. Karena resolver itu sendiri - yang diberikan jaringan kepada Anda - mungkin tidak dapat diandalkan.
Bahkan jika Anda mempercayai resolver yang disarankan dari jaringan, Anda mungkin hanya menggunakannya di rumah. Seperti yang saya sebutkan, setiap kali di kafe, hotel atau di jaringan lain, Anda mungkin akan diberikan resolver yang berbeda. Dan siapa yang tahu apa kebijakan pengumpulan datanya?
Selain fakta bahwa data Anda dikumpulkan dan kemudian dijual tanpa sepengetahuan atau persetujuan Anda, sistem ini digunakan dengan cara yang bahkan lebih berbahaya.
Spoofing
Dengan spoofing, seseorang di jalur antara Anda dan server DNS mengubah respons. Alih-alih alamat IP asli, penipu memberi tahu Anda alamat IP yang salah untuk situs tersebut. Dengan demikian, mereka dapat memblokir akses ke situs nyata atau mengirim versi palsu dari scammer.
Kirim ke 1.6.6.6 ... ini adalah alamat yang benar-benar benar, dan bukan situs web palsu yang saya kontrolSekali lagi, di sini resolver itu sendiri dapat bertindak sangat terkenal.
Misalkan Anda melakukan pembelian di toko Megastore. Anda ingin membandingkan harga dan melihat apakah produk seperti itu dijual lebih murah di toko online big-box.com yang bersaing.
Tetapi jika Anda menggunakan Megastore WiFi di ruang perdagangan mereka, maka Anda mungkin menggunakan resolver mereka. Dia dapat mencegat permintaan ke big-box.com dan berbohong kepada Anda bahwa situs tersebut tidak tersedia.
Bagaimana cara memperbaiki situasi menggunakan Trusted Recursive Resolver (TRR) dan DNS over HTTPS (DoH)?
Di Mozilla, kami sangat percaya bahwa kami bertanggung jawab untuk melindungi pengguna dan data mereka, dan oleh karena itu kami berupaya mengatasi kerentanan ini.
Memperkenalkan dua fitur baru untuk memperbaiki ini: Trusted Recursive Resolver (TRR) dan DNS over HTTPS (DoH). Karena sebenarnya ada tiga ancaman:
- Anda bisa berakhir menggunakan resolver yang tidak dapat dipercaya yang melacak permintaan Anda atau tanggapan palsu dari server DNS.
- Router di sepanjang jalan dapat melacak permintaan atau melakukan intervensi dengan cara yang sama.
- Server DNS dapat melacak kueri DNS.

Bagaimana cara menghindarinya?
- Hindari resolvers yang tidak dapat diandalkan dengan TRR.
- Lindungi dari mendengarkan dan spoofing menggunakan DNS over HTTPS.
- Transfer sesedikit mungkin data untuk melindungi pengguna dari de-anonimisasi.
Hindari resolvers yang tidak dapat diandalkan dengan TRR
Jaringan dapat berhenti merekomendasikan resolver yang tidak dapat dipercaya yang mengumpulkan data pengguna atau kueri DNS palsu karena sangat sedikit pengguna yang menyadari risiko atau cara melindungi diri mereka sendiri.
Bahkan untuk pengguna yang mengetahui risiko, sulit bagi pengguna individu untuk setuju dengan penyedia mereka atau organisasi lain bahwa mereka akan secara bertanggung jawab ditangani dengan permintaan DNS mereka.
Namun, kami telah mempelajari risiko ini ... dan kami memiliki pengaruh. Kami telah lama mencari perusahaan yang akan membantu kami melindungi data DNS pengguna. Dan mereka menemukan satu seperti itu:
Cloudflare .
Cloudflare menyediakan layanan penyelesaian rekursif dengan kebijakan privasi untuk pengguna. Mereka berjanji untuk menghapus semua data yang dapat diidentifikasi secara pribadi setelah 24 jam dan tidak pernah mentransfer data ini ke pihak ketiga. Pemeriksaan rutin akan dilakukan untuk memastikan bahwa data benar-benar dihapus seperti yang dijanjikan.
Berkat ini, kami memiliki resolver tepercaya untuk melindungi privasi pengguna. Ini artinya Firefox dapat mengabaikan resolver jaringan, dan langsung menuju ke Cloudflare. Sekarang Anda tidak perlu khawatir penyerang menggunakan resolver untuk menjual data pengguna atau spoofing DNS.
Mengapa kami memilih satu penyelesai? Seperti kami, Cloudflare prihatin tentang menciptakan layanan DNS pribadi. Bersama kami, mereka mengembangkan resolver DoH transparan yang baik. Perusahaan siap pergi untuk perlindungan tambahan layanan, jadi kami senang bekerja sama dengan mereka.
Tetapi ini tidak berarti bahwa Anda harus menggunakan Cloudflare. Pengguna dapat mengonfigurasi Firefox untuk menggunakan resolver berkemampuan DoH apa pun yang rekursif. Ketika layanan baru tersedia, kami berencana untuk menerapkan penemuan sederhana dan beralih di antara mereka.
Lindungi dari mendengarkan dan spoofing menggunakan DNS over HTTPS
Tapi resolver bukan satu-satunya ancaman. Router yang sedang dalam perjalanan dapat melacak dan memalsukan kueri DNS, karena mereka juga melihat konten kueri dan respons DNS. Untungnya, sudah ada teknologi di Internet untuk melindungi dari mendengarkan dari router di jalan. Ini adalah enkripsi yang saya bicarakan.
Menggunakan HTTPS untuk bertukar paket DNS melindungi permintaan DNS pengguna kami dari spionase.
Transfer sesedikit mungkin data untuk melindungi pengguna dari de-anonimisasi
Selain resolver tepercaya yang berjalan di bawah protokol DoH, Cloudflare dan saya sedang mengerjakan langkah-langkah keamanan tambahan.
Biasanya, resolver mengirim nama domain yang sepenuhnya memenuhi syarat ke setiap server: DNS root, domain tingkat atas, server nama domain tingkat kedua, dll. Tetapi server Cloudflare akan melakukan hal yang berbeda. Itu hanya akan mengirim bagian yang terkait dengan server DNS tertentu. Ini disebut
minimisasi QNAME .
"Kamu tidak tahu bagaimana menuju ke server .org?"Seringkali resolver juga memasukkan 24 bit pertama dari alamat IP Anda dalam permintaan. Ini membantu server DNS untuk mencari tahu di mana Anda berada dan memilih CDN terdekat. Tetapi server DNS dapat menggunakan informasi ini untuk menghubungkan permintaan yang berbeda satu sama lain.
Sebagai gantinya, Cloudflare akan membuat permintaan dari salah satu alamat IP-nya sendiri, yang berada di sebelah pengguna. Ini menyediakan geolokasi tanpa referensi ke orang tertentu. Kami juga sedang mengeksplorasi cara menerapkan keseimbangan beban yang lebih baik, dengan pertimbangan privasi.
Semua ini - menghapus bagian domain dan alamat IP yang tidak perlu - berarti server DNS dapat mengumpulkan lebih sedikit data tentang Anda.

Apa yang tertinggal dari TRR dengan DoH?
Langkah-langkah perlindungan ini mengurangi jumlah orang yang dapat melihat riwayat halaman yang Anda kunjungi. Tetapi mereka tidak sepenuhnya menghilangkan kebocoran data.
Setelah Anda melakukan pencarian DNS, Anda masih perlu terhubung ke server web di alamat itu untuk mendapatkan alamat IP. Untuk melakukan ini, kirim permintaan. Permintaan mencakup SNI (indikasi nama server) yang menunjukkan situs tertentu di server. Dan permintaan ini tidak dienkripsi.
Artinya, ISP Anda masih dapat mengetahui situs mana yang Anda kunjungi, karena terdaftar di sana dalam SNI. Informasi juga terbuka untuk router yang mengirimkan permintaan awal dari browser Anda ke server web.
Tapi begitu Anda terhubung ke server web, semuanya dienkripsi. Dan yang paling penting, koneksi terenkripsi ini dapat digunakan untuk situs apa pun di server ini, dan bukan hanya untuk yang Anda minta semula.
Ini kadang-kadang disebut sebagai penggabungan koneksi HTTP / 2 atau hanya menggunakan kembali koneksi. Ketika Anda membuka koneksi ke server yang kompatibel, itu akan memberi tahu Anda situs apa yang dihosting di sana. Anda kemudian dapat mengunjungi situs-situs ini menggunakan koneksi terenkripsi yang ada.
Mengapa ini berguna? Karena Anda tidak perlu membuka koneksi baru untuk terhubung ke situs lain ini. Artinya, Anda tidak perlu mengirim permintaan awal lain yang tidak dienkripsi yang menunjukkan SNI dan pengungkapan informasi di situs mana Anda akan pergi. Jadi, Anda dapat mengunjungi salah satu situs lain di server yang sama tanpa mengungkapkannya ke penyedia dan router Anda di sepanjang jalan.
Dengan semakin populernya CDN, semakin banyak situs individual dilayani oleh satu server. Dan karena Anda dapat memiliki beberapa koneksi terpadu terbuka, Anda secara bersamaan terhubung ke beberapa server atau CDN bersama, mengunjungi semua situs di server yang berbeda tanpa kebocoran data. Jadi fungsi ini semakin efektif berfungsi sebagai pelindung layar.
Apa statusnya?
Sudah di Firefox Anda dapat mengaktifkan DNS melalui HTTPS, dan kami
menyarankan Anda melakukannya .
Kami ingin mengaktifkan DoH secara default untuk semua pengguna, karena semua orang berhak atas privasi dan keamanan, terlepas dari apakah mereka tahu tentang kebocoran DNS atau tidak.
Tetapi ini adalah perubahan yang signifikan, dan perlu diuji terlebih dahulu. Karena itu, kami sedang melakukan penelitian. Setengah dari pengguna
Firefox Nightly kami meminta bantuan untuk mengumpulkan data kinerja.
Dalam pengujian, resolver default digunakan, seperti sekarang, tetapi permintaan juga dikirim ke resolver DoH Cloudflare. Kemudian kami membandingkan hasilnya untuk memverifikasi bahwa semuanya berfungsi seperti yang diharapkan.
Untuk peserta studi, respons Cloudflare DNS belum digunakan. Kami hanya memeriksa bahwa semuanya berfungsi, dan kemudian membuang respons Cloudflare.

Terima kasih kepada pengguna Nightly yang membantu menguji Firefox setiap hari. Kami harap Anda membantu kami juga.