Infrastruktur dasar, yang akan memungkinkan hal ini, ada dan disebut Otentikasi Berbasis-DNS Entitas Bernama (DANE) dan ditentukan dalam RFC6698 . Ini bekerja dengan cara aTLSA catatan sumber daya, yang menentukan sertifikat atau kunci publik entitas akhir atau salah satu CA-nya dalam rantai (Sebenarnya ada empat jenis yang berbeda, lihat RFC untuk detail).
Adopsi
Namun DANE belum melihat adopsi secara luas. VeriSign memonitor adopsi DNSSEC dan DANE dan melacak pertumbuhannya seiring waktu :
Sebagai perbandingan, menurut VeriSign, ada sekitar 2,7 juta zona DNS, sehingga itu berarti bahwa sedikit lebih dari 1% dari semua zona memiliki setidaknya satu catatan TLSA.
Saya tidak bisa memberikan jawaban resmi, mengapa DANE, tetapi berikut adalah spekulasi saya:
DANE menderita masalah yang sama dengan Daftar Pencabutan Sertifikat (CRL) dan Protokol Status Sertifikat Online (OCSP). Untuk memverifikasi keabsahan sertifikat yang disajikan, pihak ketiga harus dihubungi. Hanno Böck memberikan tinjauan yang baik , mengapa hal ini merupakan masalah besar dalam praktiknya. Itu bermuara pada masalah apa yang harus dilakukan, ketika Anda tidak dapat mencapai pihak ketiga. Vendor browser memilih untuk soft-fail (alias izin) dalam hal ini, yang membuat semuanya agak tidak berguna dan Chrome akhirnya memutuskan untuk menonaktifkan OCSP pada 2012.
DNSSEC
DNS bisa dibilang menawarkan ketersediaan yang jauh lebih baik daripada server CRL dan OCSP CA, tetapi masih membuat verifikasi offline menjadi tidak mungkin. Selain DANE, seharusnya hanya digunakan bersama dengan DNSSEC. Karena DNS normal beroperasi di atas UDP yang tidak diautentikasi, ia cenderung rentan terhadap pemalsuan, serangan MITM, dll. Adopsi DNSSEC jauh lebih baik daripada adopsi DANE, tetapi masih jauh dari mana-mana.
Dan dengan DNSSEC kami mengalami lagi masalah soft-fail. Sejauh pengetahuan saya, tidak ada server utama / sistem operasi klien yang menyediakan resolver DNSSEC yang valid secara default.
Lalu ada juga masalah pencabutan. DNSSEC tidak memiliki mekanisme pencabutan dan mengandalkan kunci berumur pendek sebagai gantinya.
Dukungan Perangkat Lunak
Semua perangkat lunak yang berpartisipasi harus menerapkan dukungan DANE.
Secara teori, Anda mungkin berpikir, bahwa ini akan menjadi tugas perpustakaan crypto dan pengembang aplikasi tidak perlu berbuat banyak, tetapi kenyataannya, perpustakaan kriptografi biasanya hanya menyediakan primitif dan aplikasi harus melakukan banyak konfigurasi dan pengaturan sendiri (dan sayangnya ada banyak cara untuk membuat kesalahan).
Saya tidak tahu, bahwa semua server web utama (mis. Apache atau nginx) misalnya menerapkan DANE atau memiliki rencana untuk melakukannya. Server web sangat penting di sini, karena semakin banyak hal dibangun di atas teknologi web dan oleh karena itu sering kali merupakan yang pertama, di mana berbagai hal diimplementasikan.
Ketika kita melihat CRL, OCSP, dan Stapling OCSP sebagai perbandingan, kita mungkin dapat menyimpulkan bagaimana kisah adopsi DANE akan berjalan. Hanya beberapa aplikasi, yang menggunakan OpenSSL, libnss, GnuTLS, dll. Mendukung fitur-fitur ini. Butuh beberapa saat untuk perangkat lunak besar seperti Apache atau nginx untuk mendukungnya dan merujuk kembali ke artikel Hanno Böck, mereka salah dan implementasi mereka cacat. Proyek perangkat lunak utama lainnya, seperti Postfix atau Dovecot tidak mendukung OCSPdan memiliki fungsionalitas CRL yang sangat terbatas, pada dasarnya menunjuk ke sebuah file dalam sistem file (yang tidak harus dibaca ulang secara teratur, sehingga Anda harus memuat ulang server Anda secara manual, dll). Perlu diingat bahwa ini adalah proyek, yang sering menggunakan TLS. Kemudian Anda dapat mulai melihat hal-hal, di mana TLS jauh kurang umum, seperti PostgreSQL / MySQL misalnya dan mungkin mereka menawarkan CRL terbaik.
Jadi saya bahkan server web modern tidak mengimplementasikannya dan kebanyakan perangkat lunak lain bahkan belum sempat menerapkan OCSP dan CRL, semoga sukses dengan aplikasi atau perangkat perusahaan 5 tahun Anda.
Aplikasi Potensial
Jadi di mana Anda bisa benar-benar menggunakan DANE? Sampai sekarang, tidak di Internet umum. Jika Anda mengontrol server dan klien, mungkin itu pilihan, tetapi dalam kasus ini, Anda sering dapat menggunakan Public-Key Pinning.
Di ruang surat, DANE mendapatkan daya tarik, karena SMTP tidak memiliki jenis enkripsi transportasi terotentikasi untuk waktu yang lama. Server SMTP terkadang menggunakan TLS antara satu sama lain, tetapi tidak memverifikasi bahwa nama-nama dalam sertifikat benar-benar cocok, mereka sekarang mulai memeriksa ini melalui DANE.