Kunci IPsec yang dibagikan sebelumnya: byte di balik string yang Anda ketik

Dua administrator membandingkan rahasia di layar, sepakat bahwa keduanya cocok, dan terowongan tetap gagal autentikasi. String yang mereka bandingkan bukanlah nilai yang dimasukkan salah satu ujung ke derivasi kunci. Di antara karakter yang Anda lihat dan byte yang di-hash protokol terdapat tipe bidang, pengodean teks, editor, dan papan klip, dan salah satu dari keempatnya dapat mengubah masukan tanpa mengubah tampilannya. Bandingkan byte-nya dan ketidakcocokan biasanya muncul dalam hitungan detik.

Apa yang dilakukan gateway dengan string itu

Kunci yang dibagikan sebelumnya tidak dikirim melalui jaringan lalu dibandingkan. Setiap ujung memasukkan salinan lokalnya ke derivasi kunci untuk pertukaran IKE, dan muatan autentikasi yang dihasilkan terverifikasi atau tidak. Desain itu berarti kedua salinan harus identik secara byte, bukan sekadar mirip secara visual, dan juga berarti kegagalan dilaporkan pada tahap autentikasi, bukan sebagai pesan kata sandi salah.

Jadi pertanyaan yang berguna bukanlah «apakah ini terlihat sama» melainkan «urutan byte persis apa yang di-hash setiap implementasi».

Dari mana byte tambahan berasal

Baris baru di akhir adalah penyebab klasik, dan ia tersembunyi di depan mata karena sebagian besar editor menambahkannya secara tak terlihat saat file disimpan. Spasi di awal atau akhir yang ditempel dari jendela obrolan melakukan hal yang sama, begitu juga tanda kutip tipografis yang diganti dengan kutip lurus oleh pengolah kata. Tidak satu pun dari itu mengubah perbandingan visual yang dilakukan manusia.

Bandingkan dengan alat yang menampilkan byte, bukan glif. printf '%s' "$PSK" | xxd | tail -2 mencetak ekor nilai dalam heksadesimal, tempat 0a atau 20 yang tersesat terlihat jelas. Lakukan di kedua ujung dan bandingkan kedua hasil cetak berdampingan. Lakukan pada materi uji yang dihasilkan, bukan pada rahasia produksi yang kemudian Anda tinggalkan di riwayat shell.

Terkode bukan berarti terenkripsi

Ekspor konfigurasi sering membawa rahasia dalam pengodean dasar, kadang dengan pemisah baris setiap enam puluh atau tujuh puluh enam karakter dan kadang dengan pengisi. Jika satu ujung mengharapkan byte yang telah didekode dan Anda menempelkan teks terkode, Anda tidak mengirim kata sandi yang berbeda, Anda mengirim kata sandi yang jauh lebih panjang yang terbuat dari karakter yang dapat dicetak. Base64 tidak memberikan kerahasiaan sama sekali, dan itulah sebabnya rahasia terkode tidak boleh ditempelkan ke forum untuk meminta pendapat kedua.

Kamus IPSec Apple adalah contoh berguna bahwa tipe itu penting: kamus itu mendokumentasikan SharedSecret sebagai data untuk metode autentikasi rahasia bersama pada muatan L2TP dan Cisco IPsec. Itu adalah properti tertentu dalam muatan tertentu, bukan bidang teks umum yang dapat Anda gunakan ulang untuk protokol lain yang kebetulan meminta rahasia.

Batas yang diklaim milik satu kombinasi

Laporan lama tentang batas tiga puluh dua karakter pada satu klien Apple adalah laporan nyata tentang satu versi klien, protokol, dan bentuk profil. Itu bukan batas universal untuk setiap platform Apple, setiap penyedia, dan setiap protokol. Periksa versi, tipe muatan, dan persyaratan gateway bersama-sama, lalu uji pada susunan yang disetujui alih-alih menyimpulkan dari utas. Tuliskan kombinasi yang diuji ke catatan perubahan, karena jika tidak orang berikutnya akan mengutip utas yang sama dengan keyakinan yang lebih besar daripada yang pantas.

Jika suatu batas benar-benar berlaku, jawabannya adalah desain kredensial yang didukung yang sesuai dengannya, bukan versi pendek dari rahasia yang kuat. Memotong kunci produksi untuk memenuhi batas yang diduga mengurangi kekuatannya secara permanen dan menghasilkan sistem yang dokumentasinya tidak lagi cocok dengan keamanannya.

Perbaiki representasinya, bukan kekuatannya

Saat autentikasi gagal setelah representasi dikonfirmasi, baca kebijakan efektif pada tahap autentikasi: metode mana yang dinegosiasikan, identitas rekan mana yang diharapkan, dan apakah gateway cocok dengan koneksi yang Anda pikirkan. Dugaan yang makin lemah bukanlah diagnosis, melainkan penurunan bertahap dengan tiket dukungan terlampir.

Jika kredensial yang diperlukan tidak dapat memenuhi standar organisasi, ubah desainnya menjadi yang bisa. Rahasia bersama dengan entropi yang cukup, dibuat sekali, disimpan di bidang terkelola, dan tidak pernah dipublikasikan, adalah jawaban yang sangat baik; versi yang lebih pendek bukan.