OpenVPN tls-ciphersuites lawan tls-version-min: apa yang dikuatkuasakan setiap satu

Tiga fakta berbeza digabungkan menjadi satu baris dalam kebanyakan perbincangan OpenVPN TLS: apa yang boleh dilakukan oleh binaan klien anda, apa yang dibenarkan oleh profil dan apa yang sebenarnya dirundingkan oleh sesi. Senarai suit TLS 1.3 yang pendek hanya menjawab separuh soalan tengah, dan ia tidak menyatakan apa-apa tentang had bawah versi protokol. Lalui semakan di bawah mengikut urutan dan berhenti pada yang pertama yang tidak bertahan, kerana setiap semakan seterusnya menganggap yang terdahulu sudah diselesaikan.

Semak binaan sebelum membaca sebarang senarai

Arahan konfigurasi tidak boleh menambah sokongan protokol kepada binari yang tidak memilikinya. Mulakan dengan sepanduk versi, yang menamakan pustaka kripto yang dikompil:

openvpn --version

Binaan 2.6 yang dipautkan dengan OpenSSL menerima kedua-dua tls-cipher dan tls-ciphersuites. Binaan dengan mbed TLS langsung tidak mempunyai pemilihan suit TLS 1.3, dan manual 2.6 menandakan tls-ciphersuites sebagai pilihan OpenSSL. Jika pelayan dibina semula dengan backend lain, profil yang sama boleh mengubah tingkah lakunya tanpa satu baris konfigurasi pun berubah.

Selagi anda di sini, jalankan openvpn --show-tls dan simpan outputnya. Itulah inventori yang akan anda bandingkan kemudian, dan murah untuk menangkapnya sebelum sesiapa mula menyunting profil.

Tulis sepanduk dan senarai itu dalam tiket perubahan, bukan dalam tetingkap sembang. Apabila dua orang bertengkar sama ada klien boleh menawarkan suit dalam enam minggu, output yang ditangkap menyelesaikannya dalam satu baris.

Asingkan had versi daripada senarai sifer

Dalam manual 2.6 ini tiga kawalan, bukan satu:

• tls-cipher menetapkan dasar sifer untuk TLS 1.2 dan lebih awal, dan dihantar ke senarai sifer OpenSSL;
• tls-ciphersuites memilih suit TLS 1.3;
• tls-version-min dan tls-version-max mengehadkan versi protokol yang boleh digunakan oleh sambungan.

Jadi senarai suit TLS 1.3 yang dipangkas dengan teliti tidak membuktikan apa-apa tentang versi lama yang masih dibenarkan. Jika keperluannya ialah «TLS 1.3 sahaja», had bawah versi yang menanggungnya, dan senarai suit hanya menyempitkan pilihan dalam had itu:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Pasangan itu melakukan dua kerja. Memadam salah satu baris membiarkan yang lain menguatkuasakan kurang daripada yang anda sangka, dan itulah kegagalan yang seluruh semakan ini wujud untuk menangkapnya.

Saluran data ialah kawalan keempat. data-ciphers merundingkan sifer simetri di dalam terowong, dan hasilnya tidak menyatakan apa-apa tentang versi TLS saluran kawalan. Melihat AES-256-GCM dalam ringkasan sesi bukan bukti tentang TLS 1.3 dalam mana-mana arah.

Baca show-tls sebagai inventori setempat

--show-tls menyenaraikan suit yang disokong oleh pustaka kripto yang dipautkan dengan binari ini, mengikut susunan keutamaan. Ia bukan laporan daripada gerbang. Manual menyatakan dengan jelas bahawa senarai itu datang daripada pustaka setempat, yang bermaksud komputer riba dengan OpenSSL 3.x dan penghala dengan binaan lebih lama akan mencetak senarai berbeza semasa bercakap dengan pelayan yang sama.

Katakan klien menyokong suit A, B dan C dan satu sesi memilih B. Itu tidak menetapkan apa-apa tentang sama ada pelayan membenarkan A atau C, mahupun sama ada B ialah satu-satunya pilihan yang dibenarkan. Asingkan ketiga-tiga baris, dan kebanyakan urutan TLS yang mengelirukan akan selesai sendiri.

Inventori itu masih wajar disimpan. Apabila sesi gagal, membandingkan senarai pustaka dengan senarai profil memberitahu anda sama ada klien mempunyai sebarang peluang untuk menawarkan apa yang pelayan mahu. Ia juga menunjukkan sama ada perubahan backend secara senyap telah membuang TLS_CHACHA20_POLY1305_SHA256 daripada kumpulan yang diharapkan oleh klien lama — jenis regresi yang muncul sebagai segelintir pengguna yang tidak dapat menyambung manakala semua orang lain tidak perasan apa-apa.

Tanya gerbang sesuatu yang ia boleh jawab

Jika anda mentadbir perkhidmatan itu, periksa konfigurasi berkesan instans yang sedang berjalan dan bukan fail pada cakera. OpenVPN mungkin dimulakan dengan laluan --config yang berbeza, mungkin menarik include, dan mungkin tidak dimulakan semula sejak suntingan. Dasar daemon yang berjalan itulah yang ditemui oleh klien.

Jika anda tidak mentadbirnya, minta pengendali keperluan klien yang disokong atau ujian penerimaan berskop. Percubaan yang ditolak bukan secara automatik suit yang ditolak: had bawah versi, semakan identiti sijil seperti remote-cert-tls, atau ketidakpadanan antara tls-auth dan tls-crypt boleh menamatkan pertukaran sebelum pemilihan suit menjadi penting. Baca ralat pelayan sebelum menukar senarai klien, kerana «handshake failed» merangkumi empat sebab berbeza dan hanya satu daripadanya ialah ketidakpadanan sifer.

Menghalakan openssl s_client ke port VPN juga tidak menghasilkan semula soalan itu. Saluran kawalan berjalan di dalam rangka OpenVPN sendiri, jadi probe TLS mentah menguji protokol lain pada port yang menjangka sesuatu yang lain. Sebarang kesimpulan daripadanya adalah tentang probe, bukan tentang terowong.

Rekodkan dua hasil dan asingkan keduanya

Sesi dibenarkan yang baharu menghasilkan satu baris saluran kawalan yang menamakan versi protokol dan sifer yang dipilih, dan satu baris saluran data berasingan yang menamakan sifer terowong. Tangkap kedua-duanya dengan versi klien dan nama profil, dan catat instans pelayan mana yang menjawab:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Kemudian baca kedua-dua baris itu daripada fail itu dan bukan daripada ingatan. Pasangan itulah bukti; nama suit semata-mata ialah keutamaan, dan had versi ialah kenyataan berasingan tentang apa yang ditolak oleh pelayan.

Lakukan semakan dalam urutan ini. Sahkan binaan dan backend dengan --version. Tangkap --show-tls sebelum mengubah apa-apa. Nyatakan had bawah versi yang diperlukan secara berasingan daripada senarai suit. Sahkan dasar berkesan instans yang berjalan dengan pemiliknya. Perhatikan satu sesi dibenarkan dan, jika pelan membenarkan, satu percubaan versi lama yang ditolak. Rekodkan hasil saluran kawalan dan saluran data sebagai penemuan berasingan.

Jika klien yang diperlukan tidak dapat memenuhi minimum baharu, ambil keputusan migrasi atau pengecualian itu secara eksplisit dan bukannya secara senyap menurunkan peraturan penerimaan yang tidak berkaitan supaya pelancaran kelihatan selesai.