OpenVPN: EC і ED — чому ці назви не є шкалою міцності

Поставте ec, ed, ecdh, ecdsa, auth і список TLS-шифрів поруч в одному профілі — і файл починає виглядати як шкала міцності з шістьма поділками. Це не так. Кожна назва відповідає на інше питання, і два профілі, що різняться лише однією з них, не обов’язково сильніші чи слабші один за одного. Упорядкувати назви за їхнім призначенням займає близько п’яти хвилин і запобігає більшості поганих правок, які люди роблять у робочій конфігурації.

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

Дві літери, два різні питання

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

ED описує форму кривої всередині цієї родини. Скручені криві Едвардса — це подання, вибране заради швидкості та стійкості до кількох помилок реалізації, і Ed25519 — це назва, яку люди зазвичай мають на увазі. Крива не є конкурентом еліптичній криптографії; це один зі способів записати еліптичну криву. Читати ED як «новіший, сильніший EC» — це перший хибний поворот, і все подальше зазвичай хибне в тому ж напрямку.

Підписування й обмін ключами — різні роботи

Щойно питання родини з’ясовано, решта назв розпадається на два стовпці, які ніколи не замінюють один одного. Один стовпець підписує, інший домовляється про спільний секрет.

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

У стовпці обміну немає відповідника під назвою EdDH. Ефемерна домовленість на ключі Curve25519 — це X25519, і це ECDH з певною кривою, точно як і з P-256. Ed25519 строго означає схему підпису, хоча назву вільно вживають і для обміну, бо дві криві споріднені: форма Едвардса для підписування і форма Монтгомері для X25519 описують ту саму базову групу.

Чому в профілі EC немає файлу dh

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

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

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 і набором, на якому він зупинився. Якщо правку профілю не можна обґрунтувати одним із цих двох виводів, це, ймовірно, зміна назви, а не властивості.