0x mı 0s mi? ipsec.secrets içindeki PSK biçimini anlamak

Bir istemci paylaşılan anahtarla kimlik doğrulamayı geçerken diğeri reddediyor, oysa yapıştırdığınız karakterler iki tarafta da aynı görünüyor. Muhtemelen aynı karakterlerdir; fark, dosyanın bunlara hangi çözme kuralını uyguladığıdır. Tırnak içindeki dize birebir alınır, 0x ile başlayan belirteç onaltılık olarak okunur ve 0s ile başlayan belirteç Base64 olarak okunur. Bu üç yazımdan yalnızca biri amaçladığınız anlamı taşır, bu yüzden düzeltme genellikle daha iyi bir parola değil, bir dönüştürmedir.

Belirti şifrelere değil kodlamaya işaret eder

İki uç farklı baytlar tuttuğunda, görüşme yine de başarılı olur ve kanıt ardından başarısız olur. Günlük o zaman algoritma uyuşmazlığı yerine bütünlük veya HMAC hatası bildirir, çünkü bir öneri seçilmiştir ve kimlik doğrulama adımı uyuşmamıştır. O satır gizli anahtarın biçiminden hiç söz etmez.

Aşama ipucudur. Seçilmiş bir öneriden sonra gelen hata, iki tarafın anahtar malzemesi dışında her şeyde anlaştığı anlamına gelir; «hiçbir öneri seçilmedi» ise ilkeye veya şifre takımlarına aittir. Parola doğru görünürken başarısız olan bütünlük denetimi, kodlama uyuşmazlığının görünen yüzüdür.

Tek gizli anahtar, dosyanın onu okuyabileceği üç yol

Dört baytlık değer için key1 onaltılık ve Base64 aynı baytların iki yeniden kodlamasıdır ve yalnızca baştaki karakterler ayrıştırıcıya hangisini tuttuğunu söyler. swanctl kimlik bilgileri de aynı kuralı izler, bu yüzden iki arayüz arasında taşınan bir değer anlamını ancak öneki onunla birlikte giderse korur.

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

O bloktaki iki ayrıntı en çok zamanı alır. Onaltılık rakamlar iki yazımı da kabul eder, yani 0x6b657931 ile 0x6B657931 aynı değerdir, ancak tek sayıda karakter reddedilmek yerine sessizce yanlış okunur ve bu, kesimden sonraki her baytı kaydırır. Base64 dolgusu değerin parçasıdır, bu yüzden sondaki = işaretleri olmadan yapıştırılan dize yüksek sesle başarısız olmak yerine başka baytlara çözülür.

Değeri bir kez çözmüş bir profil onu zaten dönüştürmüştür, bu yüzden yeniden çözmek başka baytlar ve yanlış parola gibi okunan bir kimlik doğrulama hatası üretir. Belirsiz her şey için tırnak güvenli yöndür, çünkü içerik bir kodlama işaretiyle başlasa bile birebirdir.

Base64 metni nereden gelir

Profil dışa aktarımları ve satıcı portalları anahtarı çoğu zaman zaten kodlanmış olarak verir, genellikle elle yazılmak için hiç düşünülmemiş bir veri alanında. Ya o değeri açıp çözülmüş metni tırnak içinde saklayın, ya da işareti öne koyarak kodlanmış bırakın. Her ikisinin yarısını yapmak bozan şeydir. İki yol da ancak tüm değer kopyalamadan sağ çıkarsa çalışır.

İki yön de birer komuttur ve saklanan değeri üreten tam işlem olarak bilette tutulmaya değer. Bunları şu sırayla çalıştırın:

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

Kodlanmış metni düz metinmiş gibi yapıştırmak pahalı hatadır. Dosya karakterleri yazıldığı gibi özetler, türetilen anahtar eşin hesapladığından yaklaşık üçte bir daha uzun çıkar ve her deneme uyarı olmadan aynı şekilde başarısız olur, çünkü ayrıştırıcı kendisine verilen kuralı izlemiştir.

Her eşin gerçekte hangi baytları kullandığını doğrulayın

Hatayı dizesinden neden tahmin etmek yerine önce daemonun bağlantıya bakışını, sonra kimlik doğrulama sonucunu okuyun. Saklanan uzunluğu karşılaştırmak hızlı bir sağduyu denetimidir, çünkü kodlanmış metin temsil ettiği baytlardan daha uzundur. Ardından hangi kimlik satırının eşleştiğini doğrulayın, çünkü yanlış eşin altına konmuş doğru bir gizli anahtar tıpkı yanlış biri gibi başarısız olur. Satır sırası bunu belirler: ilk eşleşme kazanır, bu yüzden üste yakın geniş bir %any satırı, az önce düzenlediğiniz belirli satırı sessizce değiştirir.

Dosya doğru olduğunda yeniden başlatmak yerine yeniden yükleyin. ipsec rereadsecrets IKE daemonunun kopyasını tazeler ve bir swanctl kurulumu kimlik bilgilerini kendi komutuyla yükler. Yeniden başlatma kurulmuş her ilişkiyi düşürür ve yapmaya çalıştığınız karşılaştırmayı yok eder.

Bu denetimlerin hiçbiri gizli anahtarın açığa çıkarılmasını gerektirmez. Bir uzunluk, bir kimlik seçici ve bir satır konumu bu tür hataların çoğunu açıklar; kimsenin onaltılık döküme ihtiyacı olmadan önce.

Dosyayı sonucu saklamadan değiştirin

Dosyayı daemonun hesabıyla sınırlayın ve canlı gizli anahtarları biletlerden, sohbetten ve ekran görüntülerinden uzak tutun, çünkü yapıştırılmış bir anahtar teşhis değil sızıntıdır. Ayrıca onu üreten olaydan daha uzun yaşar.

Yapılandırmasını kontrol ettiğiniz bir istemciden test edin, kimlik doğrulamanın başarılı olduğunu, ardından tünelin trafik taşıdığını doğrulayın. El sıkışmayı düzeltip yönlendirme bozuk kalan bir yeniden yükleme başka bir sorundur ve gizli anahtar hareket etmeyi bıraktığı anda görünür hale gelir.