Почему 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В выводе читайте выбранные алгоритмы, а не предложенный список. Если ответ слабее, чем предполагала политика, исправление относится к конфигурации предложения на одной из сторон, а несоответствие в современных реализациях обычно выглядит как неудачные переговоры, а не как тихое понижение.
Затем вспомните, чего набор не покрывает. Маршруты, разрешения приложений, журналирование и хранение отдельные решения со своим обзором, и совместимая криптографическая компоновка ничего о них не говорит. Разговор о шифре стоит того, но отвечает на более узкий вопрос, чем тот, который большинство людей действительно задаёт.
Держите словарь точным, и аргумент станет короче. Набор это совокупность ролей на уровне, шифр один компонент, а согласованный результат единственное, что описывает соединение, которое у вас действительно есть. Всё остальное в сравнении украшение.