Menjejaki paket kawalan OpenVPN: tls-auth sebelum TLS
HMAC tls-auth terletak pada sampul kawalan, bukan di dalam jabat tangan TLS. Padankan kunci, arah dan digest, kemudian sahkan tanpa membuang perlindungan.
Kegagalan tls-auth biasanya dilaporkan sebagai masalah jabat tangan, sedangkan ia tidak pernah begitu. HMAC diperiksa pada paket kawalan sebelum sebarang pemprosesan TLS berlaku, jadi kunci atau arah yang tidak sepadan menghasilkan kegagalan yang kelihatan seperti masalah sijil dan diputuskan dua lapisan lebih awal. Menganggap sampul sebagai objek tersendiri memendekkan diagnosis: baca medan, sahkan pemeriksaan berlaku awal, kemudian bandingkan tiga perkara yang kedua-dua hujung mesti persetujui.
Baca sampul mengikut susunan ia dibina
Paket kawalan membawa pengecam sesi, HMAC tls-auth pilihan, maklumat ulangan dan pengesahan, serta pengecam mesej yang boleh dipercayai, dan selepas itu muatan jenis mesej menyusul. Apabila mesej itu mesej jabat tangan, muatan itu kebetulan teks sifer TLS. Itulah keseluruhan hubungan: bahan TLS bergerak di dalam mesej yang sudah dilindungi sampul. Lihat rujukan protokol rangkaian OpenVPN yang menyenaraikan medan saluran kawalan dalam susunan itu.
Lapisan kebolehpercayaan mudah disalah anggap sebagai kriptografi. Pengesahan, penghantaran semula dan pengecam mesej wujud supaya mesej kawalan tiba sekali dan mengikut susunan melalui pengangkutan yang tidak boleh dipercayai. Ia bukan pengesahan identiti, dan pengecam mesej yang betul tidak membuktikan apa-apa tentang siapa yang menghantar paket itu.
Kekalkan pengelompokan ini sebagai konsep. Ia bukan rajah susunan bait, dan ia tidak mencukupi untuk mengira tag, kerana medan yang masuk ke dalam HMAC bergantung pada pelaksanaan, versi dan mod.
Tunjukkan bahawa pemeriksaan berlaku sebelum jabat tangan
Penerima yang memegang kunci kongsi boleh mengesahkan HMAC dan membuang paket palsu serta-merta, tanpa memperuntukkan keadaan jabat tangan atau melakukan kerja kunci awam. Perlindungan itu meliputi paket jabat tangan awal juga, dan itulah sebabnya kunci yang salah muncul sebagai sambungan gagal dan bukan sebagai ralat pengesahan identiti yang lewat.
Naikkan verbositi daemon dan perhatikan saluran kawalan dan bukan peranti tun:
openvpn --config /etc/openvpn/server.conf --verb 6
Apa yang anda cari ialah kegagalan pengesahan HMAC saluran kawalan yang dilaporkan pada peringkat paket, sebelum sebarang makluman TLS. Makluman TLS dalam log bermaksud sampul telah diterima dan kegagalan bergerak ke dalam, iaitu siasatan lain dengan pembaikan lain.
Pengendalian arah juga ada di sini. Apabila fail kunci statik digunakan dengan tls-auth, kedua-dua hujung mengambil arah kunci yang bertentangan, dan protokol menggunakan pembahagian itu supaya paket yang ditangkap tidak boleh dipantulkan kembali kepada penghantarnya. Membalikkan arah mengekalkan kunci yang sama dan tetap menggagalkan setiap paket. Tukar satu hujung pada satu masa, kemudian mulakan semula kedua-dua daemon supaya pasangan dimuatkan bersama.
Padankan kunci, arah dan digest pada kedua-dua hujung
Tiga nilai mesti bersetuju dan hanya satu daripadanya ialah fail. Kandungan kunci statik mesti sama pada kedua-dua hujung, arah mesti bertentangan, dan digest yang digunakan untuk HMAC mesti sepadan. Periksa konfigurasi sebelum menyentuh bahan kunci, kerana satu arah terbalik menjelaskan lebih banyak kegagalan daripada fail yang rosak:
grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf
Jana rahsia kongsi dengan alat dan bukan dengan editor, dan kekalkan kebenarannya ketat:
openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key
Keluaran lama menerima susunan pilihan yang sedikit berbeza untuk penjanaan kunci, dan profil yang ditulis untuk keluaran itu masih beredar. Fail yang dijana ialah jenis objek yang sama dalam kedua-dua kes, jadi pemeriksaannya ialah sama ada kedua-dua hujung memegang bait yang serupa, bukan ejaan mana yang menghasilkannya.
Jangan kelirukan tls-auth dengan tls-crypt. Kedua-duanya melindungi saluran kawalan, tetapi tls-crypt juga menyulirkannya dan menyembunyikan jabat tangan daripada pemerhati, dan ia menggantikan pembahagian arah dengan pengendalian kuncinya sendiri. Profil yang menggunakan satu tidak akan beroperasi dengan rakan yang dikonfigurasikan untuk yang lain, dan tiada penalaan digest dapat menutup jurang itu.
Hasilkan semula tag hanya daripada format sebenar
Penghasilan semula tepat pada tahap bait ialah tugas berasingan daripada menjalankan VPN, dan ia hanya berfungsi dengan input sebenar: pelaksanaan dan versi yang membina paket, digest yang dipilih, arah, dan bait sebenar termasuk pengecam sesi dan tatasusunan pengesahan. Perwakilan teks bagi senarai medan bukanlah bait itu.
Panjang tag mengikut digest, jadi andaian panjang tetap runtuh pada saat seseorang mengubahnya. Cincang paket seperti yang dilakukan pelaksanaan, bukan seperti yang dipaparkan jadual dalam catatan blog, dan bandingkan dengan tangkapan yang diambil daripada rakan yang sama dan bukan dengan jangkaan yang anda terbitkan secara manual.
Jauhkan latihan itu daripada profil pengeluaran. Tiada apa-apa dalam penghasilan semula tag memberitahu anda sama ada sesuatu penggunaan patut mengaktifkan perlindungan.
Batalkan ketidakpadanan tanpa membuang perlindungan
Ujian yang menggoda ialah memadam tls-auth, melihat sambungan berjaya dan menyimpulkan kunci itu salah. Jawapan itu merugikan anda perlindungan dan tidak mengajar apa-apa tentang nilai mana antara ketiga-tiganya yang tidak sepadan. Sebaliknya, dapatkan konfigurasi sepadan yang diluluskan daripada pihak pelayan dan bandingkan dengannya.
Sediakan perubahan itu supaya boleh dibalikkan. Simpan konfigurasi pelayan dan fail kunci sebelumnya, gunakan pasangan yang diperbetulkan, sahkan bahawa klien menyelesaikan jabat tangan, dan hanya selepas itu buang sandaran. Jika klien gagal selepas perubahan, pulihkan fail sebelumnya dan bukannya mereka-reka varian ketiga semasa gangguan. Pemulihan hendaklah satu arahan yang anda sudah tahu sebelum bermula.
Akhirnya, ingat apa maksud pemeriksaan yang lulus. Ia membuktikan rakan memegang kunci kongsi, bukan bahawa sijil atau akaunnya dibenarkan, dan ia tidak menyebut apa-apa tentang sifer saluran data yang dirundingkan. Kebenaran dan perlindungan data ditubuhkan kemudian, jadi pemeriksaan sampul yang bersih ialah titik permulaan dan bukan keputusan.