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