Чому AES-256 не описує набір шифрування VPN
Набір виконує чотири ролі: масове шифрування, цілісність, встановлення ключів і автентифікація партнера. Назва шифру покриває лише одну з них, на одному рівні.
Запитайте, яке шифрування використовує VPN, і відповідь зазвичай приходить одним словом: AES-256, або ChaCha20, або можливо WireGuard. Ця відповідь називає один компонент одного рівня, тоді як те, що справді захищає з єднання, це набір алгоритмів, які виконують чотири різні ролі. Плутати компонент із компонуванням це найпоширеніша помилка в таких розмовах, і вона породжує порівняння, які неможливо розв язати.
Чотири завдання в одному з єднанні
Масове шифрування перетворює відкритий текст на шифротекст для каналу даних, і його ключ виводиться, а не передається. Захист цілісності виявляє зміну, і це окреме завдання, навіть якщо одна конструкція робить і те, і інше. Встановлення ключів створює спільний матеріал трафіку, а автентифікація партнера вирішує, хто на іншому кінці. Якщо бракує бодай одного, з єднання небезпечне, яким би міцним не був залишок.
Деякі схеми об єднують дві ролі в одну. AES-GCM і ChaCha20-Poly1305 це автентифіковані конструкції шифрування, тому конфіденційність і цілісність приходять разом; AES-CBC ні, йому потрібен окремий код автентифікації повідомлення з власним ключем. Тому читання пропозиції як мішка незалежних чисел неправильно читає ті, що задумані парами.
Ролі лежать і на різних рівнях, тому те саме слово в двох продуктах може означати різне. Блоковий шифр усередині ESP і блоковий шифр усередині TLS це той самий примітив у різних переговорах з різними вимогами. Тому цитування примітиву без його режиму й рівня може бути гірше, ніж не цитувати нічого.
Чому назва шифру майже нічого не каже
Поставтеся до фрази AES-256 серйозно на мить: вона позначає блоковий шифр і розмір ключа. Вона нічого не каже про режим роботи, про те, чи забезпечена цілісність, як установлено ключі або як автентифіковано партнера. Два продукти можуть обидва рекламувати AES-256 і відрізнятися в усьому іншому, включно з одним у неавтентифікованому режимі та іншим у режимі AEAD із сучасним обміном ключами.
TLS 1.3 вніс це розділення в стандарт, що є корисною поправкою для всіх, хто вчив старший словник. Його набори шифрів називають лише AEAD і хеш, тоді як групи обміну ключами й алгоритми підпису узгоджуються як окремі параметри. Тому назва набору TLS 1.3 незрівнянна з назвою набору TLS 1.2 на рівних умовах, хоча обидві з являються в тому самому полі файлу конфігурації. Аудитор, який порівнює два рядки безпосередньо, робить висновок, якого протокол не підтримує. Прочитайте також узгоджену групу й параметри підпису, інакше порівняння неповне.
WireGuard обирає зворотний шлях і майже повністю прибирає переговори: протокол задає фіксований набір алгоритмів, тому дві реалізації або працюють разом, або ні. Це законний вибір проєктування, і він також означає, що питання, який набір узгоджує WireGuard, не має відповіді, вартої порівняння. Якщо ви його аудитуєте, прочитайте специфікацію один раз і потім аудитуйте керування ключами навколо неї, а не переговори.
Рівень визначає словник
Розгортання IPsec узгоджує двічі: пропозицію IKE для каналу керування й перетворення ESP для даних, і обидві можуть законно різнитися. Читати першу й припускати, що вона описує другу, це часте джерело плутанини під час аудиту, бо файл конфігурації згадує обидві, а цікава друга.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Назва, доступна в одній бібліотеці, не реалізується автоматично для іншого шляху даних. Тому твердження, що наш продукт підтримує AES-256, слабше, ніж звучить, і тому проблему сумісності зазвичай вирішують пошуком підтримуваного перетину, а не вмиканням кожного старого алгоритму з обох боків.
Специфікація TLS 1.3 це найясніший опублікований приклад цього розділення, бо вона визначає набір як пару й переносить решту в його власні переговори. Коли ця форма знайома, пропозиція IPsec і єдиний фіксований набір WireGuard читаються як варіанти тієї самої ідеї.
Прочитайте узгоджений результат, потім зупиніться
Налаштована пропозиція не є доказом того, що вибрали два партнери. Жива сесія несе відповідь, і будь-яка поширена реалізація може повідомити її без перехоплення пакетів.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showУ виводі читайте вибрані алгоритми, а не запропонований список. Якщо відповідь слабша, ніж передбачала політика, виправлення належить до конфігурації пропозиції на одному з боків, а невідповідність у сучасних реалізаціях зазвичай виглядає як невдалі переговори, а не як тихе зниження.
Потім згадайте, чого набір не покриває. Маршрути, дозволи застосунків, журналювання й зберігання це окремі рішення з власним оглядом, і сумісне криптографічне компонування нічого про них не каже. Розмова про шифр варта того, але відповідає на вужче питання, ніж те, яке більшість людей насправді ставить.
Тримайте словник точним, і аргумент стане коротшим. Набір це сукупність ролей на рівні, шифр один компонент, а узгоджений результат єдине, що описує з єднання, яке ви справді маєте. Усе інше в порівнянні це оздоба.