Может ли сертификат 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 выполняет свою работу.