0x или 0s? Разчитане на формата PSK в ipsec.secrets

Един клиент се удостоверява със споделения ключ, а друг го отхвърля, при все че символите, които сте поставили, изглеждат еднакви от двете страни. Вероятно това са същите символи; разликата е кое правило за декодиране прилага файлът към тях. Низ в кавички се приема буквално, токен, започващ с 0x, се чете като шестнадесетичен, а токен, започващ с 0s, се чете като Base64. Само едно от тези три изписвания означава това, което сте имали предвид, затова поправката обикновено е преобразуване, а не по-добра парола.

Симптомът сочи към кодирането, не към шифрите

Когато двете страни държат различни байтове, договарянето все още успява, а доказателството се проваля след него. Тогава журналът отчита отказ на целостта или на HMAC, а не несъответствие на алгоритъма, защото предложение е било избрано, а стъпката по удостоверяване не е съвпаднала. Този ред никога не споменава формата на тайната.

Етапът е подсказката. Отказ, който идва след избрано предложение, означава, че двете страни са се разбрали за всичко освен за ключов материал, докато „няма избрано предложение“ принадлежи на политиката или на наборите от шифри. Проверка на целостта, която се проваля, докато паролата изглежда вярна, е видимото лице на несъответствие в кодирането.

Една тайна, три начина, по които файлът може да я прочете

За стойността от четири байта key1 шестнадесетичното и Base64 са две прекодирания на едни и същи байтове и само водещите символи казват на анализатора кое от двете държи. Данните за достъп на swanctl следват същата конвенция, затова стойност, преместена между двата интерфейса, запазва смисъла си само когато префиксът ѝ пътува с нея.

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

Две подробности в този блок струват най-много време. Шестнадесетичните цифри приемат и двата регистъра, така че 0x6b657931 и 0x6B657931 са една и съща стойност, но нечетен брой символи се прочитат тихо погрешно, вместо да бъдат отхвърлени, което измества всеки байт след разреза. Подплънката на Base64 принадлежи на стойността, затова низ, поставен без завършващите си знаци =, се декодира в различни байтове, вместо да се провали шумно.

Профил, който веднъж е декодирал стойността, вече я е преобразувал, затова повторното декодиране дава различни байтове и отказ при удостоверяването, който се чете като грешна парола. Кавичките са безопасната посока за всичко двусмислено, защото съдържанието е буквално дори когато започва с маркер за кодиране.

Откъде идва текстът Base64

Експортът на профили и порталите на доставчици често подават ключа вече кодиран, обикновено в поле с данни, което никога не е било предназначено за ръчно въвеждане. Или разопаковайте тази стойност и запазете декодирания текст в кавички, или я оставете кодирана с маркера отпред. Правенето на половината от едното и половината от другото е това, което чупи. И двата пътя работят само ако цялата стойност оцелее при копирането.

И двете посоки са по една команда и си струва да останат в тикета като точната операция, създала запазената стойност. Изпълнете ги в този ред:

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

Поставянето на кодиран текст като обикновен е скъпата грешка. Файлът хешира символите точно както са записани, производният ключ излиза приблизително с една трета по-дълъг от този, който партньорът е изчислил, и всеки опит се проваля по същия начин без предупреждение, защото анализаторът е следвал даденото му правило.

Потвърдете кои байтове всъщност използва всеки партньор

Прочетете първо представата на демона за връзката, а после резултата от удостоверяването, вместо да гадаете причина от текста на грешката. Сравняването на запазената дължина е бърза проверка за разумност, защото кодираният текст е по-дълъг от байтовете, които представя. След това потвърдете кой ред на идентичност е съвпаднал, защото правилна тайна, подредена под грешен партньор, се проваля по същия начин като грешна. Редът на редовете решава това: първото съвпадение печели, затова широк ред %any близо до върха тихо заменя конкретния ред, който току-що редактирахте.

Презаредете, вместо да рестартирате, след като файлът е верен. ipsec rereadsecrets обновява копието на демона IKE, а инсталация със swanctl зарежда данните за достъп чрез собствената си команда. Рестартът изхвърля всяка установена асоциация и унищожава сравнението, което сте се опитвали да направите.

Нито една от тези проверки не изисква разкриване на тайната. Дължина, селектор на идентичност и позиция на ред обясняват повечето откази от този вид, преди някой да се нуждае от шестнадесетичен дамп.

Променете файла, без да скривате резултата

Ограничете файла до акаунта на демона и дръжте живите тайни извън тикети, чат и екранни снимки, защото поставен ключ е изтичане, а не диагностика. Той също така надживява инцидента, който го е създал.

Тествайте от клиент, чиято конфигурация контролирате, потвърдете, че удостоверяването успява, и след това потвърдете, че тунелът пренася трафик. Презареждане, което поправя ръкостискането, докато маршрутизацията остава счупена, е друг проблем и става видимо веднага щом тайната спре да се движи.