SSTP и SSL 3.0: ярлык против согласованной версии

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

Два ответа на один и тот же вопрос

Аргумент от ярлыка легко сформулировать: SSTP описан как защищённый протокол туннелирования через сокеты, историческое название говорит SSL, следовательно соединение должно быть SSL 3.0. Он держится потому, что название действительно происходит из этой линии, и потому, что большинство тех, кто его повторяет, никогда не смотрели на рукопожатие. Он держится ещё и потому, что вывод звучит осторожно, будто предположить худшее — безопасный выбор. Предполагать худшее и измерять фактическую версию — разные занятия, и только одно из них что-то меняет.

Аргумент от доказательства задаёт более узкий вопрос. О какой версии протокола договорились этот клиент и этот сервер, на этой конечной точке, в этот момент? Ответ приходит от службы, которая завершает TLS, а не со страницы маркетинга и не из браузера, который попал на похоже названный сайт.

Эти два аргумента различаются тем, что они могут доказать. Ярлык не отличает старое развёртывание от исправленного, а рукопожатие не скажет, чем занимается посторонняя служба на том же узле. Пользуйтесь вторым и перестаньте пользоваться первым.

Прочитайте версию, которую служба действительно выбирает

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

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

Отделите поле записи от согласования

Старомодно выглядящий номер версии в одном поле — не тот же факт, что сеанс SSL 3.0. RFC 7568 рассматривает версию уровня записей и согласованный протокол как разные вопросы, и именно из этого различения берутся уверенные неверные ответы. Прочитайте согласованный протокол, затем шифр, и только потом делайте вывод о сеансе.

Тот же документ недвусмыслен относительно самого протокола: SSL 3.0 нельзя использовать, а согласование или откат к нему запрещены. Причина — сломанная конструкция CBC, которую использовала атака POODLE, и это свойство протокола, а не конфигурация одного приложения.

Поэтому «эту нагрузку, вероятно, трудно эксплуатировать» не является аргументом за то, чтобы оставить SSL 3.0 включённым. Требование — удалить протокол, а не выиграть спор об одной демонстрации.

Выведите SSL 3.0 из эксплуатации с политикой, которую можно обосновать

В Windows параметры протоколов Schannel находятся в разделе Protocols и читаются отдельно для роли клиента и роли сервера, поэтому изменение, исправляющее одно направление, может оставить другое нетронутым. Текущие параметры и требования к перезапуску документированы Microsoft, а сторонняя библиотека TLS на том же узле полностью их игнорирует.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

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

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

Принимайте изменение на новых подключениях

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

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

Запишите результат как служба, бэкенд, разрешённая политика и наблюдаемая версия. Такая запись точно отвечает на вопрос безопасности, чего не делает ни аргумент от ярлыка, ни аргумент от неудобства.