Melacak paket kontrol OpenVPN: tls-auth sebelum TLS

Kegagalan tls-auth biasanya dilaporkan sebagai masalah jabat tangan, padahal tidak pernah demikian. HMAC diperiksa pada paket kontrol sebelum pemrosesan TLS apa pun terjadi, sehingga kunci atau arah yang tidak cocok menghasilkan kegagalan yang tampak seperti masalah sertifikat dan diputuskan dua lapisan lebih awal. Memperlakukan amplop sebagai objek tersendiri mempersingkat diagnosis: baca bidangnya, pastikan pemeriksaan berjalan lebih awal, lalu bandingkan tiga hal yang harus disepakati kedua ujung.

Baca amplop sesuai urutan pembentukannya

Paket kontrol membawa pengenal sesi, HMAC tls-auth opsional, informasi pengulangan dan pengakuan, serta pengenal pesan yang andal, lalu muatan jenis pesan menyusul. Saat pesan berupa pesan jabat tangan, muatannya kebetulan adalah ciphertext TLS. Itulah seluruh hubungannya: materi TLS berjalan di dalam pesan yang sudah dilindungi amplop. Lihat referensi protokol jaringan OpenVPN yang mencantumkan bidang kanal kontrol dalam urutan tersebut.

Lapisan keandalan mudah disalahartikan sebagai kriptografi. Pengakuan, pengiriman ulang, dan pengenal pesan ada agar pesan kontrol tiba sekali dan berurutan melalui transportasi yang tidak andal. Itu bukan autentikasi, dan pengenal pesan yang benar tidak membuktikan apa pun tentang siapa yang mengirim paket.

Pertahankan pengelompokan ini sebagai konsep. Ini bukan diagram urutan byte, dan tidak cukup untuk menghitung tag, karena bidang yang masuk ke HMAC bergantung pada implementasi, versi, dan mode.

Tunjukkan bahwa pemeriksaan berjalan sebelum jabat tangan

Penerima yang memegang kunci bersama dapat memverifikasi HMAC dan langsung membuang paket palsu, tanpa mengalokasikan status jabat tangan atau melakukan kerja kunci publik. Proteksi juga mencakup paket jabat tangan awal, dan itulah sebabnya kunci yang salah muncul sebagai koneksi gagal alih-alih kesalahan autentikasi yang terlambat.

Naikkan verbositas daemon dan amati kanal kontrol alih-alih perangkat tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Yang Anda cari adalah kegagalan verifikasi HMAC kanal kontrol yang dilaporkan pada tingkat paket, sebelum peringatan TLS apa pun. Peringatan TLS di log berarti amplop diterima dan kegagalan berpindah ke dalam, yang merupakan penyelidikan lain dengan perbaikan lain.

Penanganan arah juga ada di sini. Saat berkas kunci statis dipakai dengan tls-auth, kedua ujung mengambil arah kunci yang berlawanan, dan protokol memakai pembagian itu agar paket yang tertangkap tidak dapat dipantulkan kembali ke pengirimnya. Membalik arah tetap membuat kunci sama dan tetap menggagalkan setiap paket. Ubah satu ujung setiap kali, lalu mulai ulang kedua daemon agar pasangan dimuat bersama.

Cocokkan kunci, arah, dan digest di kedua ujung

Tiga nilai harus sepakat dan hanya satu di antaranya adalah berkas. Isi kunci statis harus identik di kedua ujung, arahnya harus berlawanan, dan digest yang dipakai untuk HMAC harus cocok. Periksa konfigurasi sebelum menyentuh materi kunci, karena satu arah yang terbalik menjelaskan lebih banyak kegagalan daripada berkas yang rusak:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Buat rahasia bersama dengan alat, bukan dengan editor, dan jaga izinnya ketat:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Rilis lama menerima urutan opsi yang sedikit berbeda untuk pembuatan kunci, dan profil yang ditulis untuk rilis tersebut masih beredar. Berkas yang dihasilkan adalah jenis objek yang sama pada kedua kasus, jadi pemeriksaannya adalah apakah kedua ujung memegang byte yang identik, bukan ejaan mana yang menghasilkannya.

Jangan mencampur tls-auth dengan tls-crypt. Keduanya melindungi kanal kontrol, tetapi tls-crypt juga mengenkripsinya dan menyembunyikan jabat tangan dari pengamat, dan mengganti pembagian arah dengan penanganan kunci sendiri. Profil yang memakai salah satu tidak akan berinteroperasi dengan peer yang dikonfigurasi untuk yang lain, dan tidak ada penyetelan digest yang menutup celah itu.

Reproduksi tag hanya dari format yang sebenarnya

Reproduksi persis per byte adalah tugas terpisah dari menjalankan VPN, dan hanya berhasil dengan masukan yang sebenarnya: implementasi dan versi yang membangun paket, digest yang dipilih, arah, dan byte sebenarnya termasuk pengenal sesi dan larik pengakuan. Penjabaran tekstual dari daftar bidang bukanlah byte tersebut.

Panjang tag mengikuti digest, jadi asumsi panjang tetap runtuh begitu seseorang mengubahnya. Hash paket seperti yang dilakukan implementasi, bukan seperti yang disajikan tabel dalam pos blog, dan bandingkan dengan tangkapan dari peer yang sama alih-alih dengan perkiraan yang Anda turunkan sendiri.

Jauhkan latihan itu dari profil produksi. Tidak ada apa pun dalam mereproduksi tag yang memberi tahu Anda apakah suatu penerapan harus mengaktifkan proteksi.

Batalkan ketidakcocokan tanpa melepas proteksi

Uji yang menggoda adalah menghapus tls-auth, melihat koneksi berhasil, dan menyimpulkan kuncinya salah. Jawaban itu menghabiskan proteksi Anda dan tidak mengajarkan apa pun tentang nilai mana dari ketiganya yang tidak cocok. Sebagai gantinya, ambil konfigurasi yang cocok dan disetujui dari sisi server lalu bandingkan dengannya.

Siapkan perubahan agar dapat dibalik. Simpan konfigurasi server dan berkas kunci sebelumnya, terapkan pasangan yang telah diperbaiki, verifikasi bahwa klien menyelesaikan jabat tangan, dan baru setelah itu hapus cadangannya. Jika klien gagal setelah perubahan, pulihkan berkas sebelumnya alih-alih mengarang varian ketiga saat gangguan. Pemulihan harus berupa satu perintah yang sudah Anda kenal sebelum memulai.

Terakhir, ingat arti pemeriksaan yang lolos. Itu membuktikan peer memegang kunci bersama, bukan bahwa sertifikat atau akunnya diotorisasi, dan itu tidak mengatakan apa pun tentang cipher kanal data yang dinegosiasikan. Otorisasi dan perlindungan data dibangun kemudian, jadi pemeriksaan amplop yang bersih adalah titik awal, bukan putusan.