Чи може сертифікат 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 виконує свою роботу.