OpenVPN EC наспроти ED: зошто овие имиња не се скалило на јачина
EC, ED, ECDHE и auth одговараат на различни прашања. Пред да споредите или уредите нешто, подредете го OpenVPN профилот според работата што ја врши секое име.
Ставете ec, ed, ecdh, ecdsa, auth и список на TLS шифри еден до друг во еден профил, и датотеката почнува да изгледа како диск за јачина со шест позиции. Но не е. Секое име одговара на различно прашање, и два профила што се разликуваат во едно од нив не се нужно појаки или послаби еден од друг. Подредувањето на имињата според работата што ја вршат трае околу пет минути и спречува повеќето лоши промени што луѓето ги прават во конфигурација што работи.
Подредувањето подолу почнува од самата збунетост и потоа се движи нанадвор, кон деловите од профилот што навистина одлучуваат што го штити вашиот сообраќај. Секој дел по ред зема едно погрешно читање и покажува за што е името всушност врзано.
Две букви, две различни прашања
Парот што предизвикува најмногу расправија е EC и ED, а расправијата обично претпоставува дека тие се ривалски одговори на едно прашање. Тие не се ни на иста оска. EC опишува семејство математика: криптографија со елиптични криви, каде безбедноста доаѓа од тежината на дискретниот логаритам на крива, а не во големо конечно поле.
ED опишува форма на крива во тоа семејство. Кривите Twisted Edwards се претстава избрана заради брзина и заради отпорност на неколку грешки во имплементацијата, а Ed25519 е името што луѓето обично го мислат. Кривата не е конкурент на криптографијата со елиптични криви; таа е еден начин да се напише елиптична крива. Читањето на ED како „понов, појак EC“ е првиот погрешен свиок, и по него сето останато обично е погрешно во истата насока.
Потпишувањето и размената се одделни работи
Откако ќе се реши прашањето за семејството, останатите имиња се делат на две колони што никогаш не се заменуваат. Едната колона потпишува, другата се договара за заедничка тајна.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
И 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 и пакетот на кој застана. Ако промената на профилот не може да се оправда со еден од овие два излеза, таа веројатно е промена на име, а не на својство.