Paket OpenVPN mana yang dilindungi digest auth?
Opsi auth mencakup lebih sedikit daripada yang disiratkan profil. Telusuri kanal, kasus AEAD, dan perlindungan kanal kontrol sebelum Anda menetapkan kebijakan digest.
Sebagian besar perdebatan tentang digest OpenVPN dimulai dari paket yang salah. Membaca auth SHA256 sebagai “terima hanya peer yang menawarkan SHA256” adalah hal pertama yang harus dilupakan. Opsi ini menamai digest untuk paket tertentu, dan paket mana yang dimaksud bergantung pada kanal dan pada apakah kanal itu AEAD. Kerjakan empat pertanyaan di bawah secara berurutan; masing-masing mempersempit apa arti pengaturan itu dalam penerapan Anda.
Namai kanal yang hendak dilindungi pengaturan itu
OpenVPN memiliki kanal kontrol yang membawa lalu lintas jabat tangan TLS dan kanal data yang membawa muatan terowongan. Digest auth berperan pada keduanya, tetapi tidak sama, dan profil jarang membuat perbedaannya terlihat. Tuliskan mana dari keduanya yang ingin Anda batasi sebelum menyentuh berkas konfigurasi.
Tabel di bawah adalah versi singkat tentang bagaimana opsi yang sama mendarat di setiap konteks.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Periksa apakah kanal data itu AEAD sebelum Anda mengandalkannya
Jika cipher data yang dinegosiasikan adalah AES-GCM atau CHACHA20-POLY1305, kanal data mengautentikasi dirinya sendiri dan digest terpisah tidak melakukan pekerjaan yang mungkin Anda bayangkan. Keduanya adalah konstruksi AEAD, jadi integritas dihasilkan oleh operasi yang sama yang mengenkripsi muatan. Itu bukan penurunan mutu, tetapi berarti kebijakan yang dibenarkan sebagai “setiap paket data adalah HMAC-SHA256” secara faktual salah pada terowongan itu. Konfirmasikan nilai yang dinegosiasikan di log server atau keluaran status klien sebelum menulis ulang kebijakan.
Periksa cipher yang benar-benar dinegosiasikan alih-alih daftar di profil, karena negosiasi bisa mendarat pada anggota lain dari himpunan. data-ciphers AES-256-GCM:AES-128-GCM adalah daftar negosiasi, dan kedua entrinya AEAD, jadi tidak satu pun dari keduanya memakai digest auth untuk perlindungan muatan.
Perlakukan perlindungan kanal kontrol sebagai keputusan tersendiri
tls-auth menambahkan HMAC ke paket kanal kontrol dan mengambil digest-nya dari pengaturan auth, itulah sebabnya terowongan AEAD masih dapat memiliki digest yang bermakna terkonfigurasi. tls-crypt adalah susunan lain dengan perlindungan tetapnya sendiri, jadi jangan mengasumsikan ia mewarisi setiap sifat tls-auth. Baca dokumentasi untuk mekanisme yang Anda pilih alih-alih memindahkan asumsi di antara keduanya.
Kedua peer juga harus sepakat tentang susunan dan arah kunci. Digest yang cocok tetapi berkas kunci yang dipakai pada arah yang salah menghasilkan jabat tangan yang gagal karena alasan yang tidak dapat dijelaskan oleh pengaturan digest.
Jaga auth terpisah dari negosiasi cipher dan sertifikat
Tiga pengaturan terus dicampuradukkan: digest auth, daftar cipher data, dan algoritme tanda tangan sertifikat. Mengubah yang pertama tidak menerbitkan ulang sertifikat, tidak memilih digest tanda tangannya, dan tidak membuat metode pengguna-kata sandi. Definisi opsi protokol di sumber OpenVPN 2.6 menjelaskan masing-masing di bagiannya sendiri, yang merupakan pengingat berguna bahwa itu adalah tombol yang independen.
Ketika peer menolak terhubung setelah perubahan digest, penyebabnya biasanya ketidakcocokan pada salah satu dari dua pengaturan lainnya. Baca kedua ujungnya sebelum mengubah salah satunya.
Tuliskan kebijakannya dan bandingkan dengan konfigurasi yang berjalan
Pernyataan tingkat armada harus menyebutkan mode kanal data yang diizinkan dan perlindungan kanal kontrol yang dipilih secara eksplisit, dalam kalimat yang sama. Kalimat itu dapat diuji; “kami memakai SHA256” tidak. Lalu bandingkan dengan profil server dan klien yang efektif, bukan dengan templat di repositori.
Akhiri dengan mencatat apa yang sebenarnya dinegosiasikan setiap terowongan dan mekanisme mana yang mengautentikasi paketnya. Baris auth yang terlihat di profil hanyalah bukti niat konfigurasi, dan niat adalah bagian termurah dari pemeriksaan.