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

Что на самом деле меняет атака понижения

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

Меняется соглашение, а не аутентификация. Если противник может изменить предложение незаметно, стороны всё равно могут завершить рукопожатие и всё равно аутентифицировать друг друга, но с параметрами, которые предпочитает противник. Поэтому интересный вопрос — покрыты ли сами переговоры защитой целостности.

Почему сами переговоры должны быть аутентифицированы

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

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

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

Настроенная совместимость — не атака

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

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

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

Прочитайте сбой, прежде чем называть причину

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

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

Ничто из этого не является доказательством противника. Приписать злой умысел при первом сбое — и есть ошибка, потому что она скрывает детерминированную ошибку, которая провалится снова завтра.

Подтвердите, что именно было выбрано

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

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

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

Похожие статьи