Один старый пир навязывает TLS 1.0: ограничьте исключение, а не хост

Появляется одно старое устройство, не может подключиться, и самое быстрое на вид исправление — ослабить весь хост, пока соединение не заработает. Этот обмен невидим в моменте и постоянен на практике, потому что никто не убирает порог, который наконец работает. Давление создают две совершенно разные неисправности, и только одна из них вообще про шифры. Сначала классифицируйте неисправность, затем поместите исключение туда, откуда оно не сможет распространиться.

Разделите сбой на два, прежде чем менять директиву

Строка журнала сервера об отсутствии общего шифра или о неподдерживаемой версии протокола приходит из канала управления: две стороны не смогли договориться, как защищать сам переговорный процесс. Строка клиента о том, что ни один способ проверки сертификата сервера не включён, приходит совсем из другого места, потому что этот клиент вообще не проверяет, кто ответил. Смена шифра данных ничего не даёт во втором случае, а добавление проверки роли ничего не даёт в первом.

Берите самую раннюю неудачную строку с каждой стороны, а не последнюю перед отключением, потому что последняя обычно лишь следствие. Затем установите, какой файл клиент действительно открыл: импортированный профиль часто существует дважды под разными отображаемыми именами, а правка копии, которую никто не читает, создаёт убедительное отсутствие изменений. Работающий процесс сохраняет настройки, с которыми запустился, поэтому сохранённый файл — не загруженный файл. Команды ниже показывают переговоры клиента рядом с представлением сервера о той же попытке.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Второй слушатель — честное место для более слабого порога

Когда устройство останавливается на TLS 1.0 с каналом данных до 2.5, сервер должен предложить более низкий порог канала управления и шифр данных, который узнаёт старый клиент. Директива fallback существует именно для такого пира, а список шифров удерживает современных клиентов на современных наборах. Обе директивы принадлежат слушателю, а не пользователю или соединению, и никакая опция отдельного клиента потом их не сужает. Поэтому одно старое устройство на основном порту — это решение о каждом пире, который делит этот порт.

Где платформа позволяет, запускайте старый слушатель отдельным экземпляром на отдельном порту, разрешайте этот порт только с адреса устройства и оставьте основной сервис в покое. Запишите, зачем существует второй слушатель, в файле, который несёт его конфигурацию, иначе будущая уборка прочтёт его как остатки. Разделение имеет смысл только если более слабый порог заканчивается там, где заканчивается устройство.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Что на самом деле ломает старый сертификат провайдера

Ошибка проверки — это отсутствующая привязка роли: без неё клиент примет любой сертификат, выстроенный в цепочку к доверенному CA, независимо от того, выдан ли он для сервера. Сначала привяжите сертификат к роли сервера и рассматривайте привязку как требование, а не как ручку настройки. Только профиль, который всё ещё терпит неудачу после этого шага, имеет настоящую проблему с сертификатом.

Старый сертификат провайдера, размер ключа или алгоритм подписи которого больше не соответствует политике OpenSSL по умолчанию, — это случай ограниченного изменения уровня безопасности на канале управления. Понижение уровня там не выключает проверку, и его никогда нельзя сочетать с пустым CA, отключённой проверкой или непроверенным именем хоста. Держите строку внутри одного профиля, которому она нужна; экспорт ослабленной конфигурации OpenSSL глобально передал бы то же ослабление каждой программе на машине.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Читайте согласованные значения, а не баннер

При verbosity 4 обе стороны печатают версию TLS и шифр канала управления, о которых договорились, и шифр данных сеанса. Читайте эти строки, а не баннер инициализации, который сообщает об успехе, а не о его условиях. Затем снова подключите современный клиент к основному слушателю и подтвердите, что он по-прежнему попадает на современный набор, потому что исключение, утёкшее в общую конфигурацию, проявляется здесь первым. Скопированные значения становятся базой для следующего обзора.

Проверьте старое устройство отдельно: оно должно подключаться и должно быть единственным сеансом в журналах, показывающим более слабые параметры. Если второй пир тоже согласует старый набор, исключение шире задуманного, и разделение слушателей на самом деле не состоялось. Запишите оба наблюдения, а не только вывод.

Каждому исключению нужен владелец и дата

Исключение без условия удаления тихо становится умолчанием, поэтому поместите устройство, владельца, причину и дату исчезновения рядом с конфигурацией, которую оно оправдывает. Без этой строки более слабый порог переживёт оборудование, которому он был нужен.

Заменить клиент или запросить у провайдера актуальный профиль — вот результат, к которому нужно стремиться; исключение — это отсрочка, а не проект. Когда устройство выводят из эксплуатации, удалите слушатель и профиль одним и тем же изменением, чтобы ни одна половина не продолжала работать. Ничто из этого не делает старые параметры безопасными, оно лишь не даёт пределу одного устройства стать базой для всех.