OpenVPN tanpa sertifikat klien: kebijakan server, bukan profil

Anda menghapus baris sertifikat dan kunci, menyerahkan profil, dan koneksi tetap gagal dengan kesalahan sertifikat. Profil tidak pernah menjadi hal yang menegakkan persyaratan itu. Server yang memutuskan apakah sertifikat klien wajib, dan tidak ada penyuntingan di sisi klien yang menegosiasikannya. Jadi perbaikannya adalah perubahan kebijakan server, yang dilakukan dengan sengaja, dengan semua yang bergantung padanya diperbarui dalam langkah yang sama.

Profil bukan kebijakan

Community OpenVPN 2.6 hadir dengan sertifikat klien yang wajib, karena verify-client-cert secara bawaan bernilai require. Menyetelnya ke none adalah yang menghentikan tuntutan sertifikat dan menyerahkan autentikasi klien ke pengaturan nama pengguna dan kata sandi yang sudah dijalankan server. Panduan lama meraih client-cert-not-required, ejaan lama dari gagasan yang sama, jadi gunakan direktif yang didokumentasikan versi terpasang Anda. Bagaimanapun, perubahan terjadi di server, dan tidak ada profil klien yang dapat melakukannya.

Fragmen di bawah ini adalah seluruh perubahan di sisi server, dan dengan sendirinya bukan konfigurasi autentikasi yang berfungsi. verify-client-cert none menghapus persyaratan sertifikat, sedangkan username-as-common-name menjadikan nama akun sebagai identitas yang dilihat callback berikutnya dan berkas per klien. Tidak ada baris yang memeriksa kata sandi, jadi verifikator tetap harus ada.

verify-client-cert none
username-as-common-name

Verifikator itu adalah plugin atau skrip yang dikendalikan oleh auth-user-pass-verify, dan harus sudah ada sebelum salah satu baris di atas berarti apa pun. Membalik urutannya memberi Anda jendela di mana server tidak meminta sertifikat dan tidak memeriksa akun.

Apa yang masih memverifikasi server

Melepas sertifikat klien bukan berarti melepas TLS. Server menyimpan sertifikat dan kuncinya, dan klien menyimpan kepercayaan CA serta pemeriksaan nama host yang mencegahnya berbicara dengan penipu. Menghapus remote-cert-tls server atau bundel CA karena klien tidak lagi memiliki sertifikat adalah salah baca yang umum dan serius, dan referensi 2.6 menegaskan bahwa kedua arah itu independen. Satu membuktikan server kepada klien; yang lain membuktikan klien kepada server.

Profil juga dapat membawa blok tls-auth atau tls-crypt. Itu adalah kunci kanal kontrol bersama dengan siklus distribusi dan rotasinya sendiri, jadi berkas tanpa baris sertifikat atau kunci tidak otomatis aman untuk diterbitkan. Perlakukan sebagai rahasia sampai Anda membacanya.

Berkas sertifikat yang disalin dari profil yang berfungsi tidak membuktikan apa pun dengan sendirinya; memiliki berarti memegang kunci privat yang cocok dengannya, yang diperiksa oleh penerapan yang diautentikasi sertifikat. Berkas yang berisi sertifikat bukan berkas yang dapat dipakai untuk mengautentikasi.

Apa yang harus dilakukan verifikator

Setelah persyaratan sertifikat dihapus, semuanya bergantung pada verifikator: plugin, atau skrip yang dikendalikan auth-user-pass-verify. Ia harus menolak kredensial yang tidak valid, menolak akun yang dinonaktifkan atau tidak memenuhi syarat, dan gagal tertutup ketika tidak dapat menjangkau backend-nya. username-as-common-name sering diaktifkan bersamanya, dan itu mengubah identitas yang dilihat callback berikutnya dan berkas konfigurasi per klien. Ia tidak memverifikasi kata sandi, dan tidak membuat akun yang tidak memenuhi syarat menjadi memenuhi syarat. Itu tugas terpisah, dan mencampurnya adalah cara sebuah migrasi lolos uji jalur bahagianya dan gagal pada insiden nyatanya yang pertama.

Uji kasus negatif seketat kasus positif. Profil yang menampilkan permintaan kata sandi hanya membuktikan bahwa klien dapat menggambar permintaan, sedangkan server yang menerima kata sandi yang salah membuktikan sesuatu yang jauh lebih buruk. Tambahkan akun yang dinonaktifkan dan kredensial yang kedaluwarsa ke kumpulan uji, bukan hanya kata sandi yang buruk.

Ubah kebijakan, profil, dan pemetaan bersama-sama

Koordinasikan tiga hal: direktif server, profil klien, dan pemetaan identitas per klien. Ubah secara terpisah maka klien gagal sebelum verifikasi, atau terhubung dengan nama yang tidak diharapkan administrator, yang lebih buruk karena tampak seperti keberhasilan. Koneksi yang berhasil dengan identitas yang salah lebih sulit disadari daripada yang gagal.

Pertahankan dua akun uji untuk jalur ini, satu sah dan satu yang diketahui buruk, dan gunakan keduanya setelah setiap perubahan pada verifikator. Akun yang sah membuktikan jalur bahagia dan pemetaan identitas; yang buruk membuktikan bahwa penolakan masih bekerja. Tidak ada uji yang memberi tahu Anda apa pun tentang aturan kelayakan, jadi tambahkan akun yang seharusnya ditolak karena alasan kebijakan jika penerapan memilikinya. Jalankan ketiganya setelah setiap perubahan, karena verifikator yang mulai menerima segalanya tampak persis seperti login yang berfungsi.

Catat metode autentikasi mana yang benar-benar diterima server, bukan yang disarankan profil. Catatan itu menjawab pertanyaan yang terus diajukan orang, yaitu siapa yang dapat terhubung ke layanan ini. Catatan itu juga bertahan melewati administrator berikutnya, yang jika tidak akan menemukannya kembali dari tangkapan paket.