Що робить заздалегідь узгоджений ключ у IPsec, OpenVPN і WireGuard

Слова заздалегідь узгоджений ключ трапляються в документації IPsec, OpenVPN і WireGuard, але позначають три різні об'єкти. Один є секретом автентифікації, другий захищає канал керування, третій додає матеріал у рукостискання, яке вже має ідентичності. Якщо вважати їх взаємозамінними, з'єднання впаде на етапі, якого ніхто не чекав. Прочитайте, що це поле робить у цьому протоколі, перш ніж копіювати в нього значення.

Три протоколи, три значення

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

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

IPsec і OpenVPN використовують це слово по-різному

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

Опції tls-auth і tls-crypt у OpenVPN прикріплюють статичний ключ до каналу керування, додаючи підпис HMAC або шифруючи саме узгодження. Цей ключ не є паролем користувача і не замінює сертифікат клієнта. Розрізняти їх важливо під час оновлення, коли зміна пароля залишає ключ каналу керування недоторканим.

PSK у WireGuard додає, але не ідентифікує

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

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

Перевірте поширення, ротацію та видалення

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

Текст у Base64 — не шифрування. Секрет, що лежить поруч із відкритим сертифікатом у тому самому каталозі, залишається секретом у відкритому вигляді.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

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

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