Може ли 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 си върши работата.