0x atau 0s? Memahami format PSK dalam ipsec.secrets

Satu klien mengesahkan diri dengan kunci kongsi dan satu lagi menolaknya, walaupun aksara yang anda tampal kelihatan sama pada kedua-dua belah. Ia mungkin aksara yang sama; bezanya ialah peraturan penyahkodan mana yang dikenakan oleh fail ke atasnya. Rentetan dalam tanda petik diambil secara literal, token yang bermula dengan 0x dibaca sebagai perenambelasan, dan token yang bermula dengan 0s dibaca sebagai Base64. Hanya satu daripada tiga ejaan itu bermaksud apa yang anda niatkan, jadi pembetulannya biasanya satu penukaran dan bukan kata laluan yang lebih baik.

Gejala menunjuk kepada pengekodan, bukan sifer

Apabila kedua-dua hujung memegang bait yang berbeza, rundingan tetap berjaya dan buktinya gagal selepas itu. Log kemudian melaporkan kegagalan integriti atau HMAC dan bukan ketakserasian algoritma, kerana cadangan telah dipilih dan langkah pengesahan tidak sepadan. Baris itu tidak pernah menyebut bentuk rahsia itu.

Peringkat itulah petunjuknya. Kegagalan yang tiba selepas cadangan dipilih bermakna kedua-dua pihak bersetuju tentang segala-galanya kecuali bahan kunci, manakala «tiada cadangan dipilih» tergolong dalam dasar atau set sifer. Semakan integriti yang gagal sedangkan kata laluan kelihatan betul ialah wajah yang kelihatan bagi ketakserasian pengekodan.

Satu rahsia, tiga cara fail boleh membacanya

Untuk nilai empat bait key1, perenambelasan dan Base64 ialah dua pengekodan semula bagi bait yang sama, dan hanya aksara di hadapan memberitahu penghurai yang mana satu sedang dipegangnya. Kredensial swanctl mengikut konvensyen yang sama, jadi nilai yang dipindahkan antara dua antara muka hanya mengekalkan maknanya jika awalannya bergerak bersamanya.

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

Dua butiran dalam blok itu mengambil masa paling banyak. Digit perenambelasan menerima kedua-dua huruf besar dan kecil, jadi 0x6b657931 dan 0x6B657931 ialah nilai yang sama, tetapi bilangan aksara yang ganjil dibaca salah secara senyap dan bukan ditolak, yang menggeser setiap bait selepas potongan. Pelapik Base64 ialah sebahagian daripada nilai, jadi rentetan yang ditampal tanpa tanda = di hujungnya dinyahkod menjadi bait yang berbeza dan bukannya gagal dengan kuat.

Profil yang telah menyahkod nilai itu sekali sudah menukarnya, jadi menyahkod sekali lagi menghasilkan bait yang berbeza dan kegagalan pengesahan yang terbaca seperti kata laluan yang salah. Tanda petik ialah arah yang selamat untuk apa-apa yang kabur, kerana kandungannya literal walaupun ia bermula dengan penanda pengekodan.

Dari mana teks Base64 datang

Eksport profil dan portal vendor sering menyerahkan kunci yang sudah dikodkan, biasanya dalam medan data yang tidak pernah dimaksudkan untuk ditaip dengan tangan. Sama ada buka nilai itu dan simpan teks yang dinyahkod dalam tanda petik, atau biarkan ia dikodkan dengan penanda di hadapan. Melakukan separuh daripada setiap satu itulah yang merosakkannya. Kedua-dua jalan hanya berkesan jika seluruh nilai terselamat daripada salinan.

Kedua-dua arah ialah satu arahan setiap satu, dan ia wajar disimpan dalam tiket sebagai operasi tepat yang menghasilkan nilai tersimpan itu. Jalankannya dalam susunan ini:

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

Menampal teks yang dikodkan seolah-olah teks biasa ialah kesilapan yang mahal. Fail menge-hash aksara tepat seperti yang ditulis, kunci terbitan keluar kira-kira satu pertiga lebih panjang daripada yang dikira oleh rakan, dan setiap percubaan gagal dengan cara yang sama tanpa amaran, kerana penghurai mengikut peraturan yang diberikan kepadanya.

Sahkan bait mana yang sebenarnya digunakan oleh setiap rakan

Baca dahulu pandangan daemon tentang sambungan dan kemudian hasil pengesahan, daripada meneka punca daripada rentetan ralat. Membandingkan panjang tersimpan ialah semakan kewajaran yang pantas, kerana teks yang dikodkan lebih panjang daripada bait yang diwakilinya. Kemudian sahkan baris identiti mana yang sepadan, kerana rahsia yang betul yang difailkan di bawah rakan yang salah gagal sama seperti yang salah. Susunan baris yang menentukannya: padanan pertama menang, jadi baris %any yang lebar berhampiran atas secara senyap menggantikan baris khusus yang baru anda sunting.

Muat semula dan bukan mulakan semula apabila fail itu betul. ipsec rereadsecrets menyegarkan salinan daemon IKE, dan persediaan swanctl memuatkan kredensial melalui arahannya sendiri. Permulaan semula menggugurkan setiap persatuan yang terbentuk dan memusnahkan perbandingan yang anda cuba lakukan.

Tiada satu pun daripada semakan ini memerlukan rahsia itu didedahkan. Panjang, pemilih identiti dan kedudukan baris menerangkan kebanyakan kegagalan seperti ini sebelum sesiapa memerlukan dump perenambelasan.

Ubah fail tanpa menyembunyikan hasilnya

Hadkan fail itu kepada akaun daemon, dan jauhkan rahsia hidup daripada tiket, sembang dan tangkapan skrin, kerana kunci yang ditampal ialah kebocoran dan bukan diagnostik. Ia juga hidup lebih lama daripada insiden yang menghasilkannya.

Uji daripada klien yang konfigurasinya anda kawal, sahkan pengesahan berjaya, dan kemudian sahkan terowong membawa trafik. Muat semula yang membaiki jabat tangan sementara penghalaan kekal rosak ialah masalah lain, dan ia menjadi kelihatan sebaik sahaja rahsia itu berhenti bergerak.