Mengapa Menggunakan CAA?
A CA selalu menggunakan metode validasi domain untuk memastikan setiap SSL /TLS permintaan sertifikat diotorisasi (biasanya dengan memastikan itu terhubung dengan cara tertentu ke situs tertentu menggunakan domain itu).
Misalnya, CA mungkin menyediakan file verifikasi khusus kepada pemohon. Menempatkan file ini di situs web membuktikan bahwa pemohon juga mengontrol situs tersebut, tetapi tidak dapat menjamin legitimasi kontrol itu. Seorang peretas yang mendapatkan kendali atas situs mungkin menyamar sebagai pemilik yang sah, dan kemudian dapat meminta dan menerima SSL /TLS sertifikat yang lolos pemeriksaan standar CA dan karenanya tampaknya sah. Mereka kemudian dapat berbalik dan menggunakan SSL /TLS sertifikat untuk kerusakan, di situs itu atau di tempat lain.
CAA membantu memblokir jenis eksploitasi ini dengan menentukan CA mana yang diizinkan untuk menerbitkan sertifikat untuk suatu domain (atau bahkan membatasi penerbitan sertifikat sama sekali). Ini membatasi kerusakan yang dapat ditimbulkan oleh pembajak - bahkan jika mereka memiliki kendali atas situs, mereka akan memiliki opsi yang jauh lebih sedikit untuk mencetak SSL / nakalTLS sertifikat.
Cara Kerja CAA
CAA menggunakan DNS
Grafik Domain Name System (DNS) adalah bagian penting dari infrastruktur internet. Pemilik domain apa pun menyimpan catatan DNS (di dalam apa yang disebut file zona) mengarahkan nama domain mereka ke alamat IP tempat situs mereka dihosting, dan memungkinkan kami mengetik google.com ke dalam jendela browser, bukan 216.58.194.46.
Catatan DNS biasanya digunakan sebagai "buku telepon untuk Internet", tetapi DNS juga memungkinkan jenis catatan khusus lainnya yang dapat memberikan informasi lain ke nama domain.
Catatan CAA
CAA menggunakan jenis catatan khusus yang disebut a Catatan Sumber Daya Otorisasi Sertifikasi (Catatan CAA). Ini diterbitkan menggunakan DNS, dan pemilik domain hanya menambahkan catatan CAA bersama catatan DNS lainnya. Catatan CAA termasuk a label dan nilai, dan pasangan nilai tag disebut sebagai a milik. Ada juga bendera menunjukkan seberapa kritis properti ini. Seperti inilah tampilannya:
example.com. CAA 0 masalah "ssl.com"
Di sini, example.com adalah domain dari catatan ini berlaku, dan CAA memberi tahu kami jenis rekaman apa ini. Itu 0 adalah benderanya (nol adalah default - kita akan membicarakannya di bawah). Tagnya adalah isu dan nilai (dalam tanda kutip) adalah ssl.com, yang bersama-sama membentuk properti.
Flags
Bendera hanya memiliki dua negara yang ditetapkan secara ketat saat ini: 0 (tidak kritis) dan 1 (kritis). Bendera kritis memberi tahu CA bahwa itu harus benar-benar memahami tag properti untuk melanjutkan. RFC 6844 membiarkan kemungkinan lain terbuka untuk penggunaan flag yang ditentukan pengguna (kita akan membicarakannya di bawah ini juga).
Tag
RFC 6844 mendefinisikan penggunaan tiga tag umum: isu, keluarkan dan iodef. (Seperti halnya flag, memungkinkan untuk jenis tag kustom potensial lainnya.)
Grafik isu label
Grafik isu tag menentukan yang (jika ada) CA berwenang mengeluarkan sertifikat untuk domain ini. Misalnya, pemilik domain example.com dapat membatasi penerbitan sertifikat untuk satu CA (di sini, SSL.com) dengan menggunakan file zona DNS berikut:
example.com. Masalah CAA 0 "ssl.com"
Pemilik domain dapat memilih untuk mengatur beberapa file zona untuk suatu domain:
example.com. Masalah CAA 0 "ssl.com" example.com. Masalah CAA 0 "comodoca.com"
Catatan di atas membatasi SSL /TLS penerbitan sertifikat untuk example.com ke dua CA (SSL.com dan Comodo.com).
Grafik isu catatan juga memberi wewenang pada CA yang diberi nama untuk mengeluarkan sertifikat untuk setiap subdomain dari domain yang ditentukan. Dengan demikian, catatan yang memungkinkan SSL.com dapat mengizinkan penerbitan sertifikat untuk example.com dan subdomain seperti www.example.com, email.contoh.com dan bahkan subdomain wildcard khusus * .example.com.
Catatan CAA dapat digunakan untuk membatasi penerbitan sertifikat juga - catatan ini memberitahu otoritas sertifikat yang menggunakan CAA itu tidak SSL /TLS sertifikat harus dikeluarkan untuk example.com dan subdomain oleh Apa pun AC:
example.com. Masalah CAA 0 ";"
(Titik koma dalam contoh ini berarti "jangan izinkan apa pun di sini“, Tapi seperti yang akan kita tunjukkan nanti, ini juga digunakan untuk menentukan parameter khusus.)
Perhatikan bahwa tag terbitan standar mengizinkan CA menerbitkan sertifikat untuk karakter pengganti kecuali diubah oleh…
Grafik keluarkan label
Tag ini menetapkan bahwa CA diberi otorisasi untuk menerbitkan sertifikat karakter pengganti untuk domain pemilik (mis * .example.com).
Wildcard adalah jenis khusus dari subdomain catch-all, dan perhatian serta perhatian khusus diberikan saat mengeluarkan sertifikat wildcard. Itu keluarkan tag memungkinkan pemilik domain menentukan apa yang CA dapat mengeluarkan sertifikat untuk wildcard secara terpisah dari domain utama atau subdomain lainnya. keluarkan tag didahulukan dari apa pun isu tag. Mereka menggunakan sintaks yang sama dengan isu menandai. Beberapa contoh:
example.com. Masalah CAA 0 "ssl.com" example.com. CAA 0 Issuewild ";"
Di atas memungkinkan SSL.com untuk menerbitkan sertifikat example.com dan semua subdomain kecuali untuk wildcard * .example.com. (Baik SSL.com maupun CA lainnya tidak diizinkan mengeluarkan sertifikat wildcard untuk example.com.)
example.com. Masalah CAA 0 ";" example.com. CAA 0 Issuewild "ssl.com"
Contoh ini melarang semua CA untuk menerbitkan sertifikat example.com dan subdomainnya, tetapi membuat pengecualian untuk mengizinkan SSL.com mengeluarkan sertifikat wildcard (dan hanya sertifikat wildcard) untuk example.com.
Grafik iodef label
Tag yang didefinisikan ketiga adalah iodef. Tag ini dapat digunakan untuk melaporkan permintaan sertifikat yang tidak valid kepada pemilik domain, dan terlihat seperti ini:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Catatan teratas memberikan informasi CA yang diperlukan untuk mengirim pemberitahuan email ke alamat certissues@example.com. Yang kedua mengarahkan CA untuk mengirim pesan insiden ke layanan web (disiapkan untuk tujuan ini oleh pemilik domain) di certissues.example.com. (Salah satu atau kedua metode ini dapat digunakan, tergantung pada bagaimana CA dan pemilik domain telah mengatur operasi mereka.)
iodef memposting pesan menggunakan format standar yang disebut Objek Deskripsi Deskripsi Format Pertukaran atau IODEF - karena itulah namanya. (IODEF didefinisikan dalam RFC 6546.)
Bendera dan tag yang ditentukan CA
CAA sebagaimana dijelaskan dalam RFC 6844 hanya secara khusus mendefinisikan dua status bendera (0 dan 1) dan tiga tag (isu, keluarkan dan iodef). Namun, itu membuat desain cukup terbuka untuk CA untuk membuat dan menggunakan tag dan bendera khusus untuk menentukan proses penerbitan sertifikat mereka. Contohnya mungkin:
example.com. Masalah CAA 0 "SSL.com; policy = ev"
Catatan ini menggunakan standar isu tag dengan parameter tambahan yang memerintahkan CA untuk menggunakan kebijakan Extended Validation (EV) mereka ketika mengeluarkan sertifikat untuk domain ini.
example.com. CAA 128 pca "PCA = 12345"
Pemilik domain dapat menggunakan catatan ini dengan yang baru, yang didefinisikan CA pc untuk menunjukkan bahwa mereka memiliki Akun Pelanggan Pilihan dan menetapkan nomor akun sebagai parameter. (Bendera dapat berupa nilai khusus hingga 255.) Bergantung pada bagaimana CA mengatur akun, ini dapat memungkinkan metode penagihan tertentu, verifikasi tambahan yang ditentukan akun, atau penanganan khusus lainnya.
Pro dan kontra
Plus…
Ada beberapa alasan bagus untuk menggunakan CAA. Keuntungan utama dan terpenting adalah kemampuan CAA untuk sangat mengurangi risiko kesalahan penerbitan sertifikat. Ini membantu melindungi domain Anda, bisnis Anda, dan identitas online Anda. Calon penyerang yang mungkin menemukan bug di perangkat lunak CA tertentu tidak dapat memanfaatkannya untuk menerbitkan sertifikat SSL untuk domain Anda. Selanjutnya, menggunakan tag iodef memungkinkan Anda mendapatkan laporan jika eksploitasi dicoba.
Desain CAA meningkatkan keamanan tetapi juga dapat memungkinkan alokasi sumber daya yang lebih detail - misalnya, perusahaan dapat menyiapkan catatan untuk mengizinkan (atau membatasi) departemen penjualan dan pemasaran membeli sertifikat SSL untuk sales.example.com dari sumber yang ditentukan.
Selain itu, CAA menawarkan fleksibilitas luar biasa. Untuk pemilik domain, ia menggunakan catatan sumber daya DNS yang berada di bawah kendali mereka sendiri dan dapat diubah sesuai kebutuhan, sehingga tidak terikat pada CA tertentu (dan dapat memiliki lebih dari satu CA yang diotorisasi dengan catatan masalah untuk nama domain tertentu) . Untuk CA, meskipun terpisah dari penggunaan khusus, aturan yang baru diadopsi oleh CA / B Forum (grup yang menetapkan standar untuk CA dan masalah keamanan browser) dapat memungkinkan catatan CAA digunakan untuk tujuan validasi, memberikan alasan lain yang baik untuk menggunakannya.
… Dan minus
Masalah terbesar dengan CAA adalah bahwa hal itu belum diadopsi oleh semua CA. Persyaratan Dasar Forum CA / B (yang dipenuhi oleh semua CA tepercaya) menginstruksikan CA untuk menentukan sejauh mana ia mendukung CAA dalam dokumentasi online mereka. Pada tulisan ini, bagaimanapun, penggunaan CAA hanya direkomendasikan, tidak dibutuhkan. Otoritas sertifikat yang tidak mematuhi CAA masih dapat ditargetkan, dan hingga CAA digunakan secara lebih luas, pembajak kemungkinan akan dapat menemukan CA yang tidak patuh yang bersedia mengeluarkan sertifikat jahat.
Kerugian terkait adalah bahwa bahkan ketika catatan CAA berada, pengguna tidak bisa melaksanakan penggunaannya oleh otoritas sertifikat. CA harus sesuai dengan RFC 6844 agar catatan tersebut dapat ditindaklanjuti, dan CA yang tidak patuh dapat mengabaikan keinginan tersurat pemilik domain seperti yang dinyatakan dalam catatan CAA mereka.
CAA juga harus dikonfigurasi dengan benar oleh pemilik domain dan CA. Let's Encrypt (yang mendukung CAA) baru-baru ini melaporkan masalah kecil dengan basis kode mereka yang sayangnya menyebabkan aturan CAA diabaikan dan enam sertifikat yang diterbitkan salah. Tak satu pun dari ini merupakan pengecualian yang berbahaya (dan pujian kepada tim Let's Encrypt untuk menyelesaikan dan melaporkan masalah dalam beberapa jam setelah ditemukan). Namun, ini menggarisbawahi bahwa otoritas sertifikat yang patuh harus mengimplementasikan CAA tanpa cacat.
Masalah potensial lainnya adalah ketergantungan CAA pada DNS. Kecuali jika pemilik domain mengamankan layanan nama mereka, ini bisa menjadi vektor serangan. RFC 6844 menyarankan penerapan Ekstensi Keamanan Sistem Nama Domain (DNSSEC), yang menggunakan catatan DNS yang ditandatangani secara digital untuk mengotentikasi data dan memerangi ancaman spoofing DNS.
Akhirnya, bahkan dengan CAA di tempat dan diimplementasikan dengan benar, catatan CAA dengan sendirinya tidak dapat sepenuhnya mencegah penerbitan sertifikat palsu. Meskipun CAA adalah alat yang berguna dan penting untuk membatasi opsi penyerang, pembajak dengan akses yang memadai (misalnya, dengan mengontrol DNS atau melalui rekayasa sosial) mungkin dapat merutekannya.
Kesimpulan
Otoritas Otoritas Sertifikasi memiliki potensi luar biasa sebagai bagian dari ekosistem keamanan yang lebih luas, dan adopsi dan implementasi CAA yang luas akan melindungi terhadap salah penerbitan sertifikat. Meskipun sangat disayangkan bahwa tidak semua otoritas sertifikat saat ini mendukung CAA, ada diskusi tentang membuat ini lebih disarankan atau wajib untuk semua CA. Meskipun CAA sendiri tidak akan menghentikan setiap penerbitan sertifikat yang salah, ini adalah langkah yang baik ke arah yang benar, dan SSL.com ingin mendorong Anda untuk mempertimbangkan untuk menggunakan catatan CAA sendiri.
Referensi
- RFC6844: Catatan Sumber Daya Otoritas Sertifikasi DNS (Otoritas Sertifikasi Otoritas DNS)
- RFC5070: Objek Deskripsi Deskripsi Format Pertukaran
- RFC6546: Pengangkutan Pesan Pertahanan Antar-jaringan (RID) Real-time melalui HTTP /TLS
- RFC4033: Perkenalan dan Persyaratan Keamanan DNS
- Surat Suara Forum CA / B 125 - Catatan CAA
- Entri Wikipedia tentang Otoritas Sertifikasi DNS
