OpenVPN EC против ED: почему эти имена не лестница силы

Поместите ec, ed, ecdh, ecdsa, auth и список шифров TLS рядом друг с другом в одном профиле, и файл начинает выглядеть как шестипозиционный регулятор силы. Но это не так. Каждое имя отвечает на другой вопрос, и два профиля, различающиеся одним из них, не обязательно сильнее или слабее друг друга. Сортировка имён по выполняемой работе занимает около пяти минут и предотвращает большинство плохих правок, которые люди делают в работающей конфигурации.

Приведённая ниже сортировка начинается с самой путаницы, а затем движется наружу, к тем частям профиля, которые действительно определяют, что защищает ваш трафик. Каждый раздел по очереди берёт одно неверное прочтение и показывает, к чему имя на самом деле привязано.

Две буквы, два разных вопроса

Пару, вызывающую больше всего споров, составляют EC и ED, и спор обычно исходит из того, что это конкурирующие ответы на один вопрос. Они даже не на одной оси. EC описывает семейство математики: криптографию на эллиптических кривых, где стойкость происходит от сложности дискретного логарифма на кривой, а не в большом конечном поле.

ED описывает форму кривой внутри этого семейства. Кривые Twisted Edwards — это представление, выбранное ради скорости и устойчивости к нескольким ошибкам реализации, а Ed25519 — имя, которое обычно имеют в виду. Кривая не конкурент криптографии на эллиптических кривых; это один из способов записать эллиптическую кривую. Чтение ED как «более нового, более сильного EC» — первый неверный поворот, и всё после него обычно неверно в том же направлении.

Подпись и обмен — разные задачи

Как только вопрос семейства решён, оставшиеся имена делятся на два столбца, которые никогда не подменяют друг друга. Один столбец подписывает, другой договаривается об общем секрете.

И EdDSA, и ECDSA подписывают, но это разные схемы с разными форматами ключей, поэтому сертификат, выпущенный для одной, нельзя использовать как другую. EdDSA определена для небольшого набора кривых; P-256 в него не входит, поэтому сертификат P-256 проверяется через ECDSA и никогда через Ed25519.

В столбце обмена нет эквивалента под названием EdDH. Эфемерное соглашение на ключе Curve25519 — это X25519, и это ECDH с определённой кривой, точно так же, как с P-256. Ed25519 строго означает схему подписи, хотя имя свободно используют и для обмена, потому что две кривые связаны: форма Edwards для подписи и форма Montgomery для X25519 описывают одну и ту же базовую группу.

Почему в профиле EC нет файла dh

Файл dh содержит заранее сгенерированные параметры для Diffie-Hellman в конечном поле, и эти параметры существуют потому, что большое простое число и генератор должны откуда-то взяться. Обмену на эллиптической кривой они не нужны: названная кривая и есть набор параметров, и обе стороны уже его знают. Это вся причина, по которой профиль EC может опустить директиву.

Две ситуации всё ещё создают строку dh в профиле, который в остальном выглядит современным. Первая — второй слушатель или более старый партнёр, который действительно согласует группы конечного поля. Вторая — оставшийся текст, скопированный из шаблона эпохи RSA и так и не удалённый. Профиль, который называет кривую для обмена и всё ещё загружает dh-файл на 2048 бит, не становится безопаснее от того, что это сделал; он несёт неиспользуемый артефакт.

TLS 1.3 убрал обмен ключами из имени

Сравните TLS_AES_256_GCM_SHA384 с TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, и более короткое имя выглядит как понижение. Это переименование, и причина структурная: TLS 1.3 убрал статический RSA и обмен ключами Diffie-Hellman в конечном поле, поэтому эфемерный обмен на эллиптической кривой остался единственным вариантом без PSK. Называть его в каждом наборе означало бы повторять один и тот же факт дюжину раз.

Тип сертификата исчез из имени по связанной причине. В 1.3 сертификат аутентифицирует подпись рукопожатия, а не соглашение о ключах, поэтому он больше не выбирает набор. Именно поэтому в конфигурации есть отдельный список шифров для 1.3: наборы переименовали и переорганизовали, а не ослабили.

Одно следствие стоит сказать прямо. ECDHE — это алгоритм обмена ключами и никогда не шифр. Набор, описанный как «эллиптический», говорит что-то о том, как две стороны пришли к общему ключу, и ничего о том, что затем шифрует полезную нагрузку.

auth аутентифицирует пакеты, а не полезную нагрузку

Директива auth выбирает дайджест HMAC, который аутентифицирует пакеты, и её историческое значение по умолчанию — SHA1. При шифре данных, который не является AEAD, OpenVPN вычисляет дайджест по шифротексту и добавляет его, то есть схема «зашифруй, затем MAC», которая делает манипуляции с заполнением непрактичными.

Миф здесь в том, что повышение auth до SHA512 укрепляет туннель. Это не повышает стойкость шифрования, и если согласованный шифр данных — режим AEAD, например AES-256-GCM, дайджест к пакетам данных вообще не применяется. Тег GCM уже их аутентифицирует, а значение auth остаётся для HMAC канала управления и для любого ещё используемого шифра без AEAD.

Так что директива важна, но важна в более узком месте, чем предполагает её положение в файле. Проверка того, какой шифр был фактически согласован, говорит вам, применяется ли она вообще.

Читайте профиль по столбцу, а не по рангу

Три вопроса чисто разделяют уровни, и на каждый отвечает своя часть согласованной сессии. Какой шифр защищает полезную нагрузку? Какой тег или дайджест ручается за каждый пакет и требует ли используемый шифр его вообще? Чей сертификат закрыл рукопожатие и дополнительно ли защищён канал управления с помощью tls-auth или tls-crypt?

Ничто в метке EC или ED не решает ни одного из этих трёх, и имя набора само по себе тоже не решает ни одного из них. Согласованный результат — единственное доказательство, поэтому читайте его, а не выводите стойкость из лексикона:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Первая команда сообщает, какую схему подписи на самом деле использует ваш сертификат, и это единственный надёжный способ узнать, работаете ли вы с ECDSA или с Ed25519. Вторая показывает строку канала управления, которую клиент записал для сессии, включая версию TLS и набор, на котором он остановился. Если правку профиля нельзя обосновать одним из этих двух выводов, это, вероятно, изменение имени, а не свойства.