Заздалегідь спільний ключ IPsec: байти за введеним рядком

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

Що шлюз робить із рядком

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

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

Звідки беруться зайві байти

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

Порівнюйте інструментом, який показує байти, а не гліфи. printf '%s' "$PSK" | xxd | tail -2 друкує кінець значення в шістнадцятковому вигляді, де випадковий 0a або 20 очевидний. Зробіть це на обох кінцях і порівняйте два дампи поруч. Робіть це на згенерованому тестовому матеріалі, а не на виробничому секреті, який потім залишите в історії оболонки.

Кодоване — не зашифроване

Експорт конфігурації часто несе секрет у базовому кодуванні, іноді з переводами рядка кожні шістдесят або сімдесят шість символів, а іноді з доповненням. Якщо одна сторона очікує декодовані байти, а ви вставляєте кодований текст, ви надіслали не інший пароль, а набагато довший, складений із друкованих символів. Base64 не забезпечує жодної конфіденційності, і саме тому кодований секрет ніколи не можна вставляти на форум для другого погляду.

Словник IPSec від Apple — корисний приклад того, що тип має значення: він документує SharedSecret як дані для методу автентифікації спільним секретом у корисних навантаженнях L2TP і Cisco IPsec. Це конкретна властивість у конкретному навантаженні, а не загальне текстове поле, яке можна повторно використати для іншого протоколу, що випадково просить секрет.

Заявлена межа належить одній комбінації

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

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

Виправляйте подання, а не силу

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

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