OpenVPN tanpa CA: cara peer-fingerprint memverifikasi peer

Penerapan kecil meraih sidik jari karena otoritas sertifikat tampak seperti infrastruktur yang tidak ada waktu untuk menjalankannya. Naluri itu masuk akal, tetapi jalan pintas yang orang ambil sebagai gantinya—menyalin satu rahasia kanal data ke kedua ujung—tidak. Penyiapan peer-fingerprint menjaga struktur TLS tetap utuh: tiap sisi tetap memegang kunci privat dan sertifikatnya sendiri, dan tiap sisi tetap memverifikasi yang lain. Yang berubah adalah tempat verifikasi dipancangkan: dari penerbit tepercaya ke daftar pendek digest yang dipatok. Karena digest mencakup seluruh sertifikat, bukan nama, pembaruan menjadi operasi yang benar-benar memakan waktu.

Apa yang sebenarnya dijanjikan sidik jari

Sidik jari sertifikat adalah digest dari seluruh sertifikat yang dikodekan DER, bukan kunci publiknya dan bukan nama subjeknya. Karena itu dua sertifikat dengan nama identik dan kunci sama tetapi tanggal berlaku berbeda memiliki sidik jari berbeda. Itulah yang membuat pemakuan presisi, dan itu juga yang membuat pembaruan mengganggu. Pemakuan tidak bisa berarti memercayai sebuah kunci secara umum, karena ia menamai satu artefak pada satu momen dalam hidupnya. Siapa pun boleh mengetahui digest itu, dan mengetahuinya tidak membuktikan apa pun dengan sendirinya.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Kepemilikan kunci privat yang cocok adalah yang membuktikan bahwa peer memegang sertifikat itu, dan digest adalah cara pihak lain memutuskan apakah ia memang mengharapkan sertifikat itu. Pemisahan itulah alasan desain ini bukan pengaturan rahasia bersama yang lama: kunci bersama mengautentikasi siapa pun yang mengetahui byte yang sama, sedangkan pemakuan mengautentikasi satu sertifikat. Perangkat berbeda mendapat entrinya sendiri, bukan salinan rahasia yang sama, yang merupakan perbedaan kecil dalam berkas dan besar dalam jangkauan kerusakan.

Petanya timbal balik, bukan simetris

Tiap titik akhir membutuhkan dua hal: kunci privatnya bersama sertifikat, dan pernyataan tentang sertifikat peer mana yang akan diterimanya. Di klien, pernyataan itu adalah digest sertifikat server; di server, itu daftar digest klien yang terdaftar. Contoh resmi untuk penyiapan kecil untuk Community 2.6 memperlihatkan tata letaknya dengan peer-fingerprint, dan layak dibaca sebelum memilih model kepercayaan ini untuk penerapan nyata. Kedua arah bukan satu daftar yang dibalik, dan keduanya tidak gagal pada saat yang sama.

Menambah perangkat mengedit daftar izin di server, tanpa menyalin materi privat klien yang ada dan tanpa memindahkan kunci server ke mana pun. Kedua arah juga gagal secara independen, yang berguna saat diagnosis: sisi yang menutup handshake adalah sisi yang harapannya tidak terpenuhi. Jika klien menolak server, digest tidak cocok dengan sertifikat yang disajikan. Jika server menolak klien, digest klien itu tidak ada di daftar, atau klien menyajikan sertifikat selain yang didaftarkan.

Pendaftaran: bagaimana perangkat baru bergabung

Hasilkan kunci dan sertifikat perangkat baru di tempat kunci privat akan tinggal, lalu pindahkan hanya artefak publik ke pihak yang perlu mematoknya. Pindahkan digest yang diharapkan melalui kanal yang sudah Anda percayai, dan bandingkan sertifikat lengkap alih-alih nama yang tampak familier. Digest yang disalin dari unduhan tak terverifikasi yang sama dengan sertifikat hanya membuktikan kedua berkas cocok satu sama lain. Itu pemeriksaan konsistensi, bukan pemeriksaan identitas, dan itulah cara paling senyap desain ini dilemahkan.

Di server, menambahkan digest adalah perubahan konfigurasi yang melewati manajer biasa dan diikuti dengan penyambungan ulang. Pastikan perangkat baru tersambung dan perangkat yang digest-nya dihapus tidak lagi tersambung. Uji yang hanya mencakup kasus positif membiarkan daftar izin tak terverifikasi, dan itulah tepatnya keadaan Anda enam bulan dari sekarang.

Pembaruan adalah momen mahal

Setiap sertifikat kedaluwarsa, dan sertifikat baru punya digest baru bahkan ketika kunci dan namanya tetap sama. Di bawah penerbit, pembaruan transparan bagi peer yang memercayai penerbit itu; di bawah pemakuan, itu peristiwa pendaftaran bagi setiap peer yang mematok sertifikat.

Rencanakan urutannya sebelum tanggal kedaluwarsa, bukan sesudahnya. Bagikan digest baru ke pihak yang memverifikasinya, terapkan perubahan, dan baru setelah itu tukar sertifikat di titik akhir. Urutan itu tidak meninggalkan jendela tempat kedua sisi berbeda pendapat tentang sertifikat mana yang berlaku. Jaga juga daftarnya sendiri dalam tinjauan, karena daftar yang dipatok menumpuk entri untuk perangkat yang dihentikan berbulan-bulan lalu. Setiap entri usang adalah identitas yang masih mengautentikasi jika kuncinya bertahan, jadi menghapus satu adalah tindakan keamanan, bukan kerumahtanggaan.

Apa yang tidak diputuskan peta kepercayaan

Autentikasi adalah satu lapisan, dan peta yang dipatok tidak mengatakan apa pun tentang kumpulan alamat, rute yang didorong, MTU jalur, atau kebijakan firewall. Semua itu tetap konfigurasi terpisah dengan mode kegagalan terpisah. Terowongan yang terautentikasi dan tidak melewatkan lalu lintas adalah penyelidikan berbeda dari yang tidak pernah muncul.

Peta juga tidak berskala tanpa batas, dan PKI berbasis penerbit adalah tempat penerapan yang lebih besar berakhir. Preferensi itu soal operasi, bukan kriptografi, karena menambah dan menghentikan identitas lewat satu otoritas lebih murah daripada mengedit daftar di tiap peer saat armada tumbuh. Ketika implementasi klien tidak mendukung opsi itu, jawabannya adalah model kepercayaan kompatibel yang didokumentasikan klien tersebut, atau pengganti yang didukung. Membungkam peringatan verifikasi tidak menambahkan dukungan itu, dan seluruh nilai desain ini adalah verifikasi tetap terjadi.