Artikel ini adalah Bagian 3 dari tiga seri saya tentang enkripsi SSL/TLS. Bagian 1 mencakup dasar-dasar konsep enkripsi yang terkenal. Bagian 2 memberikan pengenalan singkat tentang OpenSSL dan PKI. Bagian ini membahas masalah kelemahan PKI dan memperkenalkan dua tindakan pencegahan.
Pertama, saya ingin memperkenalkan istilah mengandalkan pihak . Pihak yang mengandalkan adalah browser web, klien email, aplikasi obrolan, dll., yang mencoba memvalidasi sertifikat x.509. Sebagian besar waktu, pihak yang mengandalkan mencapainya dengan memeriksa apakah CA dalam jangkar kepercayaannya menandatangani sertifikat.
[ Anda mungkin juga menyukai: Cara mengelola beberapa pasangan kunci SSH ]
Wisata:Lindungi kunci pribadi Anda
Seperti yang mungkin Anda ketahui dari Bagian 1, kunci pribadi adalah kunci yang harus Anda lindungi. Ini dimulai dengan pembuatan, yang seharusnya terjadi pada mesin yang dapat dipercaya.
Sekarang Anda mungkin bertanya:"Apa itu mesin yang dapat dipercaya?"
Nah, layanan online yang dijalankan oleh orang yang tidak Anda kenal tentu tidak bisa dipercaya. Anda tidak boleh membuat kunci pribadi Anda menggunakan beberapa layanan web di browser Anda karena Anda tidak tahu apakah penyedia layanan menyimpan salinan kunci yang dibuat. Untuk mencegah hal itu terjadi, Anda dapat menggunakan mesin offline sebagai gantinya.
Simpan kunci pribadi Anda hanya di tempat yang Anda butuhkan dan simpan dengan aman. Direktori pada beberapa server FTP anonim tentu bukan tempat yang aman. Berbagi jaringan di mana hanya pengguna yang memiliki hak istimewa yang memiliki akses atau pengelola kata sandi yang memungkinkan untuk menyimpan lampiran tentu saja merupakan tempat yang lebih baik untuk meletakkannya.
Jika Anda secara tidak sengaja menyalin kunci pribadi Anda yang tidak terlindungi ke beberapa jaringan berbagi atau repo Git publik, jatuhkan saja dan buat yang baru. Anda tidak dapat memastikan bahwa itu tidak dikompromikan. Bahkan jika Anda segera menghapusnya, Anda tidak dapat memastikan bahwa semacam mekanisme snapshot belum menyimpannya.
Kelemahan PKI
Apa PKI itu dan cara kerjanya telah dibahas di Bagian 2 seri ini. Jika Anda tidak tahu, baca bagian itu terlebih dahulu.
Singkatnya, seluruh alasan kami menangani kekacauan sertifikat ini adalah karena kami ingin membantu pihak yang mengandalkan untuk memastikan bahwa ia berkomunikasi dengan server yang benar dan bukan penipuan. Jadi kami mendapatkan sertifikat yang ditandatangani oleh beberapa CA yang dipercaya oleh pihak kepercayaan, dan kami semua senang, bukan?
Ya, kami bisa melakukannya jika tidak ada cacat desain yang serius di PKI.
Ada beberapa ratus CA yang memiliki kepercayaan dari pihak kepercayaan kami di Internet. Beberapa CA ini bahkan memiliki Sub CA yang mampu menandatangani sertifikat dan mendapat kepercayaan dari pihak yang mengandalkan. Dan semua CA ini dapat mengeluarkan sertifikat untuk nama domain apa pun yang valid.
Jadi, secara umum, CA mana pun dapat menerbitkan sertifikat untuk domain Anda, dan Anda bahkan tidak akan mengetahuinya. Sertifikat ini dapat digunakan untuk serangan man-in-the-middle di domain Anda karena pihak yang mengandalkan akan mempercayai sertifikat ini karena ditandatangani oleh CA tepercaya.
Dan ini bukan ancaman teoretis. Pada bulan Maret 2015, beberapa sertifikat tidak sah yang dikeluarkan oleh CNNIC digunakan untuk mendekripsi lalu lintas yang melewati Great Firewall. Pada tahun 2012, sebuah perusahaan keamanan mengakui bahwa mereka telah mengeluarkan setidaknya satu sertifikat kepada perusahaan swasta yang menggunakannya untuk memata-matai karyawan mereka. Dan pada tahun 2011, sebuah perusahaan otoritas sertifikat mengalami peretasan yang menghancurkan di mana beberapa sertifikat penandatanganan mereka dicuri.
Kemungkinan penanggulangan
Tiga contoh di atas menunjukkan kepada Anda apa yang salah dengan PKI pada intinya. Desainnya cacat. Jadi bagaimana cara memperbaikinya? Berikut adalah dua teknik yang dapat membantu mengurangi masalah.
Otorisasi Otoritas Sertifikat (CAA)
Dari abstrak Catatan Sumber Daya Otoritas Sertifikasi DNS (CAA) di RFC 8659:"Rekam Sumber Daya DNS Otoritas Sertifikasi (CAA) memungkinkan pemegang nama domain DNS untuk menentukan satu atau lebih Otoritas Sertifikasi (CA) yang berwenang untuk mengeluarkan sertifikat untuk itu nama domain. Catatan Sumber Daya CAA memungkinkan CA publik menerapkan kontrol tambahan untuk mengurangi risiko kesalahan penerbitan sertifikat yang tidak diinginkan."
Yah, aku tidak bisa menjelaskannya lebih baik. CAA memungkinkan pemegang nama domain untuk menentukan CA mana yang diizinkan untuk menerbitkan sertifikat untuk domain kami, dan CA itu sendiri berjanji kepada kami untuk menghormati catatan CAA kami. RFC 8659 mendefinisikan tiga properti berikut:
- issue berisi sebagai nilai domain CA, yang diotorisasi oleh catatan CAA untuk menerbitkan sertifikat untuk domain tertentu.
- issuewild pada dasarnya sama dengan issue tetapi untuk sertifikat wildcard. Jika tidak ada issuewild yang disetel, nilai dari issue yang akan digunakan.
- iodef berisi informasi kontak yang akan digunakan jika ada masalah terkait kebijakan CAA.
Mari kita lihat contoh record berikut:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]" Baris pertama dari contoh di atas berarti bahwa hanya CA Let's Encrypt yang diizinkan untuk menerbitkan sertifikat untuk semua host di bawah domain example.com. CA lainnya TIDAK HARUS mengeluarkan sertifikat untuk domain ini. Baris kedua memberi Anda alamat email yang dapat Anda hubungi jika ada masalah.
Karena DNS diatur secara hierarkis, data CAA di atas berlaku untuk web.example.com serta host.web.example.com dan host.sub.web.example.com. Mari kita lihat contoh lain:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
sub.web.example.com IN CAA 0 issue "example-pki.org" Di sini hanya CA example-pki.org yang diizinkan untuk mengeluarkan sertifikat untuk, mis., Host.sub.web.example.com. Catatan di baris ketiga menimpa kebijakan dari example.com. Saya pikir Anda punya ide.
Tentu saja, catatan sumber daya CAA tidak akan mencegah CA yang tidak patuh menerbitkan sertifikat untuk domain yang tidak memiliki izinnya. Namun, mereka berisiko dikeluarkan dari trust anchor yang tertanam, yang dalam banyak kasus berarti akan gulung tikar.
Dan masih ada kemungkinan bahwa CA yang berwenang dapat salah menerbitkan sertifikat kepada seseorang yang tidak berwenang untuk menggunakannya. Pilih beberapa CA kepercayaan Anda dan pilih dengan bijak.
Seperti yang Anda lihat, CAA tidak memberikan keamanan 100%, tetapi mudah diterapkan dan mengurangi risiko kesalahan penerbitan sertifikat.
Transparansi Sertifikat (CT)
Transparansi Sertifikat adalah "...protokol eksperimental untuk mencatat secara publik keberadaan sertifikat Transport Layer Security (TLS) saat diterbitkan atau diamati, dengan cara yang memungkinkan siapa pun untuk mengaudit aktivitas otoritas sertifikat (CA) dan memperhatikan penerbitan tersangka sertifikat serta untuk mengaudit log sertifikat itu sendiri. Tujuannya adalah bahwa pada akhirnya, klien akan menolak untuk menghormati sertifikat yang tidak muncul dalam log, secara efektif memaksa CA untuk menambahkan semua sertifikat yang diterbitkan ke log." (Abstrak RFC 6962)
CT menawarkan bentuk akuntansi untuk sertifikat TLS dan memungkinkan Anda memeriksa sertifikat yang diterbitkan CA untuk nama domain Anda. Untuk melakukannya, Anda dapat menggunakan layanan seperti Cert Spotter oleh sslmate, yang juga tersedia sebagai versi lokal. Saya dulu menjalankan versi lokal di server pribadi virtual saya, tetapi karena pertumbuhan log selama dua tahun terakhir, tampaknya mustahil untuk merayapi log dari awal hingga akhir. Pekerjaan itu berjalan selama berminggu-minggu dan tidak selesai; itu dibatalkan ketika saya perlu me-restart host saya untuk menyelesaikan pembaruan.
Saat ini tidak ada CA yang dipaksa untuk menambahkan sertifikat yang diterbitkan ke log CT, tetapi pertumbuhan log menunjukkan bahwa banyak dari mereka sudah menambahkan sertifikat mereka. Menurut pendapat saya, hanya masalah waktu sampai browser utama mulai hanya mempercayai sertifikat dengan entri log CT dan menjadikannya wajib.
[ Dapatkan ebook gratis ini:Mengelola kluster Kubernetes Anda untuk boneka. ]
Menutup
Rancangan asli PKI cacat dan tidak dapat dipercaya lagi. Dengan RFC 8659 dan RFC 6962, dua metode ditawarkan untuk mendapatkan kembali kepercayaan dan membantu pemegang nama domain melacak siapa yang mengeluarkan sertifikat untuk domain mereka.
Jadi mulai sekarang, ingatlah untuk melindungi kunci pribadi Anda, menyetel catatan sumber daya CAA untuk domain Anda, dan mulai memantau log CT.