Mengapa openssl rand tidak bisa membuat kunci yang diinginkan tls-crypt

OpenSSL sudah terpasang, host memiliki entropi, dan membuat kunci dengannya terasa seperti jalan pintas yang jelas. Outputnya akan acak dan rahasia dan sama sekali tidak bisa dipakai, dan kegagalannya muncul sebagai galat kanal kendali alih-alih sesuatu yang menyebut format kunci. Pengalihan perhatian itulah bagian yang mahal, karena membuat orang memeriksa cipher mereka. Yang dibaca VPN adalah struktur file tertentu, bukan blok byte sembarangan, dan salah satu varian fitur itu sama sekali tidak bisa dibuat di luar server.

Apa yang sebenarnya harus ada pada file di disk

File kunci statis OpenVPN adalah teks. Berkas ini diawali baris komentar yang menyatakan apa isinya, membawa data heks dalam baris berlebar tetap, dan berjumlah total 256 byte materi kunci. OpenVPN membacanya sebagai rahasia bersama kanal kendali, bukan sebagai sertifikat, bukan sebagai frasa sandi, dan bukan sebagai sesuatu yang akan dikenali pustaka TLS.

Jenis objek yang sama melayani kedua fitur kanal kendali. Dengan tls-auth, setiap peer juga membutuhkan arah agar paket satu pihak tidak bisa dipantulkan kembali kepadanya. Dengan tls-crypt, satu rahasia bersama mengenkripsi dan mengautentikasi kanal kendali di kedua arah, yang menyembunyikan handshake sekaligus melindunginya.

Tidak ada yang rahasia dari semua itu, dan formatnya bukan intinya. Intinya, file harus sama persis dengan yang diharapkan pembacanya: tajuk, lebar baris, baris baru di akhir, dan panjang total. File yang meleset satu baris akan dimuat sebagai sampah atau langsung gagal. Membandingkan dua peer byte demi byte karena itu adalah uji pertama yang sah, dan lebih cepat daripada membaca salah satu dari dua file konfigurasi.

Cara yang didukung untuk membuatnya

Buat kunci statis biasa dengan alat yang akan memakainya, lalu rujuk dari kedua ujung:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

Ejaan opsi berubah seiring waktu: pemasangan lama dari era 2.4 memakai bentuk dengan tanda terpisah sebelum nama file, sedangkan build saat ini menerima bentuk yang lebih pendek. Bagaimanapun, file yang dihasilkan adalah jenis objek yang sama, jadi pemeriksaannya adalah apakah kedua peer memegang byte yang identik.

Generasi kedua menambahkan struktur yang tidak bisa diciptakan generator eksternal mana pun. Kunci server dibuat sekali, dan setiap klien menerima kunci terbungkus yang diturunkan darinya:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

Yang diterima klien bukanlah kunci server itu sendiri yang digandakan. Itu adalah objek terbungkus yang membawa metadata yang hanya bisa dibuka server, dan pembungkusan itulah sebabnya file per perangkat bisa dicabut tanpa menyentuh perangkat lain. Simpan kunci server di server dan perlakukan sebagai akar kepercayaan per perangkat itu.

Di mana byte buatan tangan rusak

Mencetak 256 byte acak sebagai heks di bawah tajuk yang benar secara teori akan menghasilkan file kunci statis yang bisa dimuat. Itu tetap ide buruk. Setiap detail pemformatan menjadi peluang menghasilkan materi yang gagal saat dimuat atau, lebih buruk, membuat dua peer memegang nilai berbeda yang baru terlihat sebagai kegagalan autentikasi.

Tidak ada yang setara yang mungkin dengan varian v2. Kunci klien terbungkus hanya ada sebagai keluaran proses kunci server, dan server menyimpan materi yang diperlukan untuk membukanya. Blob acak akan ditolak atau gagal didekripsi, dan tidak satu pun dari kedua pesan itu menyebut keacakan.

Kompatibilitas versi berada di atas semua ini. Generasi pertama membutuhkan rilis yang mendukungnya di kedua ujung, dan generasi kedua membutuhkan rilis yang lebih baru lagi. Klien yang dibangun sebelum fitur itu ada tidak bisa menyelesaikan handshake dengan server yang hanya menerima materi terbungkus, dan kegagalan yang dilaporkannya menunjuk ke kanal kendali alih-alih ke versi.

Merotasi tanpa mengunci semua orang di luar

Merotasi satu rahasia bersama adalah latihan koordinasi, bukan teknis. Setiap klien harus memegang file pengganti sebelum server menarik yang sebelumnya, dan mesin apa pun yang masih memegang nilai lama gagal pada saat itu terjadi. Jangan memulai rotasi itu di tengah hari kerja.

Dengan tataan v2, rotasi bersifat per perangkat: terbitkan kunci terbungkus baru untuk satu mesin dan pensiunkan yang lama hanya untuk mesin itu. Itulah argumen utama untuk pindah begitu setiap klien berada pada rilis yang mendukungnya.

Izin file termasuk dalam percakapan yang sama. Kunci seharusnya hanya bisa dibaca oleh akun yang menjalankan layanan, dan tidak seharusnya berada di repositori yang sama dengan profil yang dilindunginya. Referensi OpenVPN 2.6 mendokumentasikan bentuk pembuatan dan bagian materi kunci, yang merupakan sumber lebih baik daripada perintah yang disalin dari kiriman forum.