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 и набора, на който се е спрял. Ако една промяна в профила не може да бъде оправдана с един от тези два изхода, тя вероятно е промяна на име, а не на свойство.