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 завантажує облікові дані своєю власною командою. Перезапуск скидає кожну встановлену асоціацію та руйнує порівняння, яке ви намагалися зробити.

Жодна з цих перевірок не вимагає розкриття секрету. Довжина, селектор ідентичності та позиція рядка пояснюють більшість таких збоїв, перш ніж комусь знадобиться шістнадцятковий дамп.

Змініть файл, не приховуючи результат

Обмежте файл обліковим записом демона й тримайте живі секрети поза заявками, чатами та скріншотами, бо вставлений ключ — це витік, а не діагностика. Він також переживає інцидент, який його породив.

Перевірте з клієнта, конфігурацією якого ви керуєте, переконайтеся, що автентифікація проходить, а потім переконайтеся, що тунель передає трафік. Перезавантаження, яке виправляє рукостискання, поки маршрутизація залишається зламаною, — це інша проблема, і вона стає видимою, щойно секрет перестає рухатися.