Saya hanya ingin tahu. Kami menggunakan banyak sertifikat SSL. Saat ini, kami hampir secara eksklusif menggunakan letsencrypt (terima kasih!). Intinya sertifikat ini adalah, bahwa bukti kepemilikan nama domain pada sertifikat berasal dari kekuatan untuk memanipulasi catatan DNS atau situs web di bawah domain ini. Bukti DNS berasal dari menambahkan beberapa kunci (diberikan oleh letsencrypt) sebagai catatan TXT ke DNS.

Jadi, JIKA itu bukti yang cukup untuk dapat mengubah catatan DNS untuk domain, mengapa tidak menggunakan sertifikat yang ditandatangani sendiri dengan sidik jari dalam DNS?

Saya akan mengatakan ini memberikan jumlah kepercayaan yang persis sama dengan prosedur berbasis DNS dari allowencrypt (dan CA lainnya):

1. Buat CA yang ditandatangani sendiri (cukup ikuti langkah-langkah berbagai cara)
2. Buat sertifikat untuk beberapa domain
3. Tanda tangani sertifikat dari langkah 2 dengan CA dari langkah 1. Sekarang Anda memiliki sertifikat dasar, ditandatangani oleh CA yang tidak tepercaya
4. Tambahkan catatan TXT (atau khusus) ke DNS dari masing-masing domain, dengan menyatakan: kami menandatangani sertifikat domain ini dengan CA ini. Suka: 'CA = -paling jari CA-'
5. Browser mengunduh sertifikat dan memverifikasinya dengan membandingkan sidik jari CA / sertifikat CA dengan data dalam DNS untuk domain yang diberikan.

Ini akan memungkinkan untuk membuat sertifikat yang ditandatangani sendiri tepercaya tanpa campur tangan pihak ketiga, dengan tingkat kepercayaan yang sama dengan sertifikat SSL dasar lainnya. Selama Anda memiliki akses ke DNS, sertifikat Anda valid. Seseorang bahkan dapat menambahkan beberapa DNSSEC seperti enkripsi, dari membuat hash dari CA ditambah catatan SOA, untuk memastikan kepercayaan menghilang pada perubahan dalam catatan DNS.

Apakah ini sudah dipertimbangkan sebelumnya?

Jelmer

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.

Berbagai jenis prosedur validasi sertifikat

Dengan sertifikat bertanda CA reguler, ada beberapa tingkat validasi sertifikat:

• Validasi Domain (DV)
  Hanya kepemilikan nama domain yang divalidasi, hanya nama domain yang ditampilkan sebagai "Subjek" dalam sertifikat
• Validasi Organisasi (OV)
  Nama domain dan nama pemilik divalidasi, nama domain dan nama pemilik ditampilkan sebagai "Subjek" dalam sertifikat
• Extended Validation (EV) Validasi yang
  lebih ketat dari entitas pemilik, nama domain, dan nama pemilik ditampilkan sebagai "Subjek" dalam sertifikat, bilah hijau dengan nama pemilik

Proses yang Anda jelaskan, dan usulkan penggantian, hanya berlaku untuk level terendah, Validasi Domain (DV).

DV adalah tingkat di mana validasi relatif mudah untuk diotomatisasi, seperti apa yang telah dilakukan LetsEncrypt, dan memberikan tingkat kepercayaan yang sama dengan apa yang dapat diberikan DNS jika digunakan sebagai satu-satunya sumber untuk anchor-trust (implikasi UI, sert dipercaya tetapi mengandung data tambahan yang sama sekali tidak divalidasi).

Otentikasi Berbasis DNS dari Entitas yang Ditentukan (DANE)

DANE dibangun di atas DNSSEC (karena keaslian data DNS sangat penting) untuk menerbitkan informasi anchor-trust untuk klien TLS dalam DNS.

Ia menggunakan TLSAtipe RR dan dapat digunakan untuk mengidentifikasi sertifikat atau kunci publik ( pemilih ) dari entitas akhir atau CA, dengan atau tanpa juga memerlukan validasi rantai sertifikat reguler untuk berhasil ( penggunaan sertifikat ) dan bagaimana sertifikat tersebut / data kunci direpresentasikan dalam catatan ( tipe pencocokan ).

Nama TLSApemilik catatan memiliki awalan yang menunjukkan port dan protokol (misalnya _443._tcp) dan RData menunjukkan cert usage, selectordan matching typemode selain data cert / key yang cocok. Lihat bagian 2.1 dari RFC6698 untuk spesifikasi parameter ini.

Sebuah TLSArecord dapat misalnya terlihat seperti ini:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

Dengan mode penggunaan 2atau 3(menunjukkan penggunaan jangkar kepercayaan TLSA saja), klien yang menyadari DANE akan menerima sertifikat yang tidak ditandatangani oleh CA yang dipercaya secara umum tetapi yang cocok dengan TLSAcatatan.
Ini secara konseptual sama dengan apa yang Anda usulkan dalam pertanyaan Anda.

Tangkapan? Klien yang menyadari DANE saat ini kurang lebih tidak ada, satu masalah adalah bahwa DNSSEC sendiri tidak banyak digunakan (terutama validasi pada mesin klien) seperti apa yang mungkin diperlukan untuk lepas landas DANE. Kemungkinan sedikit masalah ayam-dan-telur, mengingat DANE adalah salah satu kasus penggunaan baru yang berpotensi besar yang mengandalkan data DNS yang diautentikasi.

Ada plugin browser yang menambahkan validasi DNSSEC dan DANE , selain itu tidak ada banyak yang mendekati arus utama pada saat ini. Dan, sebagai sebuah plugin dan bukannya didukung secara native, ia berfungsi lebih sebagai pembuktian konsep daripada hal lainnya dalam hal penggunaan umum.

Itu bisa dilakukan. Itu sudah dipertimbangkan. Itu masih bisa terjadi, tetapi belum banyak gerakan.