Mengapa kunci OpenVPN yang lebih besar tidak menghapus pengatur waktu rekey

Memilih AES-256 atau kunci yang lebih panjang tidak mengatakan apa pun tentang berapa lama kunci itu boleh dipakai. Kekuatan kunci menggambarkan algoritme; kebijakan rekey menentukan kapan sesi menurunkan materi kunci baru. Suatu penerapan bisa memilih cipher terkuat yang tersedia dan tetap salah soal pembaruan, karena kedua keputusan diambil di tempat berbeda. Mencampuradukkannya menghasilkan perubahan cipher yang tidak perlu atau sesi yang diam-diam hidup melewati kebijakannya.

Baca pengaturan rekey sebelum menyentuh cipher, dan baca kedua peer saat melakukannya.

Kekuatan kunci dan masa pakai kunci menjawab pertanyaan berbeda

Cipher dan ukuran kunci membatasi seberapa mahal serangan terhadap lalu lintas yang disadap. Interval rekey membatasi berapa banyak lalu lintas yang dilindungi satu kunci dan berapa lama kunci yang bocor tetap berguna. Keduanya tombol yang independen, dan cipher yang lebih kuat tidak memperpanjang masa pakai aman sebuah sesi. Sebagian besar panduan yang berkata 'pakai AES-256' diam soal pembaruan, karena pembaruan adalah soal kebijakan, bukan pilihan algoritme.

Catat keduanya di catatan penerapan: apa yang melindungi kanal data, dan apa yang memicu penggantian kuncinya.

Rekey punya tiga pemicu, dan kedua peer bisa memicunya

OpenVPN 2.6 mendokumentasikan pemicu terpisah untuk negosiasi ulang berdasarkan byte, paket, dan waktu yang berlalu. Pemicu waktu adalah yang paling sering dibiarkan pada nilai bawaan, artinya terowongan yang sepi tetap melakukan rekey sesuai jadwal. Kedua peer bisa memulai pertukaran, dan peer yang tidak memulainya akan mengikuti. Jadi mengubah pengatur waktu di satu sisi tidak menentukan perilaku sesi; nilai efektifnya adalah milik sisi yang memulai lebih dulu.

Pemicu byte dan paket penting untuk beban berthroughput tinggi atau paket kecil, di mana kebijakan hanya berbasis waktu akan membiarkan satu kunci melindungi jauh lebih banyak data daripada yang dimaksud. Jika penghitung itu tetap dimatikan, katakan begitu secara sengaja di catatan daripada membiarkan nilai bawaan tanpa diperiksa.

Rekey membuka alur autentikasi

Negosiasi ulang adalah jabat tangan TLS baru, yang berarti jalur autentikasi berjalan lagi. Penerapan yang memakai kode sekali pakai, token perangkat keras, atau tantangan RADIUS menemukan hal ini dengan cara yang sulit: koneksi pertama berhasil dan sesi mati satu jam kemudian ketika jabat tangan kedua meminta kode yang sudah terpakai. auth-gen-token ada untuk menjembatani celah itu dengan membiarkan server menerbitkan token berumur pendek untuk negosiasi ulang alih-alih menuntut login interaktif baru.

Perlakukan itu sebagai masalah alur kerja yang harus diselesaikan bersama operator, bukan sebagai bukti bahwa pembaruan harus dimatikan.

Uji pembaruan di bawah beban, bukan dalam sesi satu menit

Uji penerimaan yang menghubungkan, mengirim satu ping, lalu memutus tidak pernah mencapai rekey. Jalankan sesi cukup lama untuk melewati pemicu yang dikonfigurasi, biarkan transfer berjalan sepanjang sesi, dan pantau log kedua peer untuk jabat tangan baru. Lalu uji jalur kegagalan: apa yang dilakukan klien jika negosiasi ulang tidak bisa selesai. Terowongan yang jatuh bersih lebih mudah didiagnosis daripada yang terus mengirim ke sesi mati.

Jangan membaca transfer besar yang berhasil sebagai bukti ambang kriptografis. Itu hanya menunjukkan bahwa jalur dan penghitung bertahan dengan lalu lintas sebanyak itu.

Dokumentasikan kedua pilihan

Catatan itu perlu dua baris: bagaimana paket dilindungi, dan kapan perlindungan itu diganti. Tambahkan kewenangan untuk setiap nilai, karena cipher bisa berasal dari bawaan distribusi sementara pengatur waktu berasal dari kebijakan internal. Operator di masa depan seharusnya tidak perlu menyimpulkan keduanya dari berkas konfigurasi.

Jika kompatibilitas memaksa pengecualian, batasi pada satu versi dan satu tanggal berakhir. Pengecualian yang hidup lebih lama dari alasannya menjadi kebijakan yang tidak ada yang ingat telah memilihnya.