Може ли RSA сертификат да работи со dh none во OpenVPN?

Еве серверска конфигурација која покрај сертификат со RSA наведува dh none, плус мачниот сомнеж дека едното од двете мора да е погрешно. Ништо не е погрешно. Сертификатот потпишува и автентицира; размената на клучеви воспоставува заедничка тајна. Тоа се две различни задачи во истото ракување, и TLS му дозволува на RSA сертификатот да автентицира ракување што користи привремена елиптична крива договор.

Збунетоста обично доаѓа со водич за миграција. Тој вели да се замени датотеката со DH параметри со dh none, читателот забележува дека сертификатот не е сертификат на елиптична крива, и двата факти се третираат како противречност.

Зошто двете поставки изгледаат поврзани

Поранешната OpenVPN конфигурација бараше датотека со DH параметри затоа што Diffie-Hellman во конечно поле бара доменски параметри за кои двете страни се согласуваат. Директивата dh покажуваше кон таа датотека. Кога распоредувањето преминува на ECDH, параметрите доаѓаат од именувана крива наместо тоа, и датотеката повеќе не е потребна, што го изразува dh none.

Сертификатите се посебна оска. Тие носат јавен клуч и потпис што го докажуваат идентитетот на серверот, и тој клуч може да биде RSA или елиптична крива без оглед на тоа како се договара клучот на сесијата. Ракување што користи ECDHE за договор за клуч и RSA за автентикација е вообичаено и широко распространето.

Именувањето го влошува преклопувањето. Елиптичната крива се појавува и во имињата на ECDHE и на ECDSA комплети, па лесно е да се претпостави дека секоја врска што спомнува крива мора да вклучува сертификат на крива. Не е така.

Како правилно да се чита името на TLS 1.2 комплет

Земете ECDHE-RSA-AES256-GCM-SHA384. Првиот токен е семејството за размена на клучеви: привремен Diffie-Hellman на елиптична крива. Вториот е семејството за автентикација: RSA. Останатото ја опишува заштитата на записите и хешот што се користи во ракувањето.

Комплетот ECDHE-ECDSA го користи истото семејство за размена на клучеви со различен метод на автентикација, па бара сертификат на елиптична крива. Комплетот DHE-RSA користи привремен Diffie-Hellman во конечно поле со RSA автентикација, и тој навистина бара DH параметри.

Читајте го името на комплетот од лево кон десно и доделете го секој дел на неговата задача. Откако токените ќе се одделат, прашањето се менува од «дали мојот сертификат одговара на dh none» во «дали мојот сервер дозволува комплет чија размена на клучеви не бара DH датотека».

Што всушност исклучува dh none

dh none му вели на серверот да не вчитува датотека со DH параметри за конечно поле. Тоа не ја исклучува автентикацијата, проверката на сертификати или самиот TLS. Но бара договорената размена на клучеви да не ги бара тие параметри, што во пракса значи ECDHE комплет или TLS 1.3 ракување.

Токму од тоа барање доаѓа дефектот. Ако TLS политиката за шифри на серверот е ограничена на DHE комплети или клиентот нуди само нив, отстранувањето на датотеката со параметри не остава никаков употреблив метод за размена на клучеви и ракувањето не успева. Грешката обично се појавува за време на ракувањето на контролниот канал, пред каква било автентикација на корисникот. Прочитајте ја листата со шифри пред да ја обвините датотеката што недостасува.

На страната на елиптичната крива, кривата ја избира TLS конфигурацијата на серверот, и OpenVPN нуди опција да ја изберете на постари гранки. TLS 1.3 се справува со преговорот за групата внатре во протоколот и воопшто не ја консултира DH датотеката.

dh none сам по себе не е намалување на безбедноста. Јачината на размената тогаш зависи од кривата и комплетот што навистина се договараат, затоа следниот чекор е да се погледне што избрале страните, а не датотеката што недостасува.

Потврдување на преговорот пред уредување

Зголемете ја деталноста на серверот и клиентот и прочитајте ја линијата на контролниот канал што OpenVPN ја печати по поврзувањето. Таа ја наведува TLS верзијата и договорената шифра и го известува типот на клуч на сертификатот на партнерот. Таа единствена линија одговара на прашањето што конфигурациската датотека само го навестува.

Ако покажува TLS 1.2 со ECDHE-RSA комплет и RSA сертификат, комбинацијата е точно она што dh none го очекува, и нема што да се поправи. Ако покажува DHE комплет или неуспех на ракувањето без заедничка шифра, поправката е во политиката за шифри или во можностите на клиентот, не во сертификатот.

Тестирајте го најстариот клиент што имате намера да го поддржувате, бидејќи тековниот клиент може да договори TLS 1.3, додека постариот е ограничен на TLS 1.2 комплети. Ако најстариот клиент нема преклопување, или проширете ги дозволените комплети или надградете ја таа крајна точка.

Не ја исклучувајте проверката на сертификати за да го заобиколите неуспехот на ракувањето. Неуспехот ви кажува дека страните не можеле да се договорат за размена на клучеви, а исклучувањето на проверката ја отстранува гаранцијата за идентитет без да го реши договорот.

Контролна листа: дали сертификатот е RSA, дали е дозволен ECDHE комплет, дали логот го покажува тој комплет и дали најстариот поддржан клиент исто така го договара? Ако сите четири се да, dh none ја врши својата работа.