0x atau 0s? Membaca format PSK di ipsec.secrets

Satu klien berhasil diautentikasi dengan kunci bersama dan klien lain menolaknya, padahal karakter yang Anda tempel tampak sama di kedua sisi. Kemungkinan besar karakternya memang sama; bedanya adalah aturan dekode mana yang diterapkan berkas pada karakter itu. String dalam tanda kutip diambil apa adanya, token yang dimulai dengan 0x dibaca sebagai heksadesimal, dan token yang dimulai dengan 0s dibaca sebagai Base64. Hanya satu dari tiga penulisan itu yang berarti apa yang Anda maksud, jadi perbaikannya biasanya berupa konversi, bukan kata sandi yang lebih baik.

Gejalanya menunjuk ke pengodean, bukan ke sandi

Ketika kedua ujung menyimpan byte yang berbeda, negosiasi tetap berhasil dan pembuktiannya gagal setelahnya. Log lalu melaporkan kegagalan integritas atau HMAC alih-alih ketidakcocokan algoritme, karena sebuah proposal telah dipilih dan langkah autentikasi tidak cocok. Baris itu tidak pernah menyebut bentuk rahasianya.

Tahapnya adalah petunjuknya. Kegagalan yang datang setelah proposal dipilih berarti kedua pihak sepakat pada segala hal kecuali materi kunci, sedangkan «tidak ada proposal yang dipilih» termasuk kebijakan atau kumpulan sandi. Pemeriksaan integritas yang gagal padahal kata sandi tampak benar adalah wajah terlihat dari ketidakcocokan pengodean.

Satu rahasia, tiga cara berkas dapat membacanya

Untuk nilai empat byte key1, heksadesimal dan Base64 adalah dua pengodean ulang dari byte yang sama, dan hanya karakter di depan yang memberi tahu pengurai mana yang sedang dipegangnya. Kredensial swanctl mengikuti konvensi yang sama, jadi nilai yang dipindahkan antara kedua antarmuka hanya mempertahankan maknanya bila prefiksnya ikut berpindah.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Dua detail di blok itu memakan waktu paling banyak. Digit heksadesimal menerima kedua bentuk huruf, jadi 0x6b657931 dan 0x6B657931 adalah nilai yang sama, tetapi jumlah karakter ganjil dibaca keliru secara diam-diam alih-alih ditolak, yang menggeser setiap byte setelah titik potong. Padding Base64 adalah bagian dari nilai, jadi string yang ditempel tanpa tanda = di akhirnya akan didekode menjadi byte yang berbeda alih-alih gagal dengan nyaring.

Profil yang sudah mendekode nilai itu sekali telah mengonversinya, jadi mendekode lagi menghasilkan byte berbeda dan kegagalan autentikasi yang terbaca seperti kata sandi salah. Tanda kutip adalah arah yang aman untuk segala hal yang ambigu, karena isinya literal bahkan ketika dimulai dengan penanda pengodean.

Dari mana teks Base64 berasal

Ekspor profil dan portal vendor sering menyerahkan kunci yang sudah terkode, biasanya di bidang data yang tidak pernah dimaksudkan untuk diketik dengan tangan. Entah buka nilai itu dan simpan teks hasil dekode dalam tanda kutip, atau biarkan terkode dengan penanda di depannya. Mengerjakan separuh dari masing-masing itulah yang merusaknya. Kedua jalur hanya berhasil bila seluruh nilai selamat dari penyalinan.

Kedua arah masing-masing satu perintah, dan keduanya layak disimpan di tiket sebagai operasi persis yang menghasilkan nilai tersimpan itu. Jalankan dengan urutan ini:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Menempel teks terkode seolah-olah teks biasa adalah kesalahan yang mahal. Berkas menghitung hash karakter persis seperti yang tertulis, kunci turunan menjadi sekitar sepertiga lebih panjang daripada yang dihitung rekan, dan setiap percobaan gagal dengan cara yang sama tanpa peringatan, karena pengurai mengikuti aturan yang diberikan kepadanya.

Pastikan byte mana yang benar-benar dipakai setiap rekan

Baca dulu pandangan daemon tentang koneksi dan baru kemudian hasil autentikasi, alih-alih menebak penyebab dari string galat. Membandingkan panjang tersimpan adalah pemeriksaan kewajaran yang cepat, karena teks terkode lebih panjang daripada byte yang diwakilinya. Lalu pastikan baris identitas mana yang cocok, karena rahasia benar yang tersimpan di bawah rekan yang salah gagal persis seperti rahasia salah. Urutan baris yang menentukan: kecocokan pertama menang, jadi baris %any yang lebar di dekat atas diam-diam menggantikan baris spesifik yang baru saja Anda sunting.

Muat ulang alih-alih memulai ulang setelah berkasnya benar. ipsec rereadsecrets menyegarkan salinan daemon IKE, dan penyiapan swanctl memuat kredensial lewat perintahnya sendiri. Memulai ulang menjatuhkan setiap asosiasi yang terbentuk dan menghancurkan perbandingan yang hendak Anda buat.

Tidak satu pun dari pemeriksaan ini menuntut rahasianya diungkap. Panjang, pemilih identitas, dan posisi baris menjelaskan sebagian besar kegagalan seperti ini sebelum ada yang memerlukan dump heksadesimal.

Ubah berkas tanpa menyembunyikan hasilnya

Batasi berkas pada akun daemon, dan jauhkan rahasia yang hidup dari tiket, obrolan, dan tangkapan layar, karena kunci yang ditempel adalah kebocoran, bukan diagnostik. Kunci itu juga bertahan lebih lama daripada insiden yang menghasilkannya.

Uji dari klien yang konfigurasinya Anda kendalikan, pastikan autentikasi berhasil, lalu pastikan terowongan membawa lalu lintas. Muat ulang yang memperbaiki handshake sementara perutean tetap rusak adalah masalah lain, dan itu terlihat begitu rahasianya berhenti bergerak.