Може ли 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 ради свој посао.