Трассировка управляющих пакетов OpenVPN: tls-auth до TLS

Сбой tls-auth обычно описывают как проблему рукопожатия, хотя ею он никогда не был. HMAC проверяется на управляющем пакете до любой обработки TLS, поэтому неверный ключ или направление дают сбой, который выглядит как проблема сертификата и решается двумя уровнями раньше. Если рассматривать конверт как отдельный объект, диагностика становится короткой: прочитайте поля, убедитесь, что проверка срабатывает рано, и сравните три вещи, о которых должны договориться обе стороны.

Читайте конверт в том порядке, в котором он собирается

Управляющий пакет несёт идентификатор сеанса, необязательный HMAC tls-auth, сведения о повторе и подтверждении, а также надёжный идентификатор сообщения, после чего идёт полезная нагрузка типа сообщения. Если сообщение является сообщением рукопожатия, полезной нагрузкой оказывается шифротекст TLS. Вся связь именно такова: материал TLS путешествует внутри сообщения, которое конверт уже защищает. Обратитесь к справочнику по сетевому протоколу OpenVPN, где поля управляющего канала перечислены в этом порядке.

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

Держите эту группировку как понятие. Это не диаграмма порядка байтов, и её недостаточно для вычисления тега, потому что поля, входящие в HMAC, зависят от реализации, версии и режима.

Покажите, что проверка срабатывает до рукопожатия

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

Повысьте подробность демона и наблюдайте за управляющим каналом, а не за устройством tun:

openvpn --config /etc/openvpn/server.conf --verb 6

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

Обработка направления тоже здесь. Когда статический файл ключа используется с tls-auth, две стороны занимают противоположные направления ключа, и протокол использует это разделение, чтобы перехваченный пакет нельзя было отразить обратно его отправителю. Обратное направление оставляет ключ тем же и всё равно проваливает каждый пакет. Меняйте по одной стороне за раз, затем перезапустите оба демона, чтобы пара загрузилась вместе.

Согласуйте ключ, направление и digest на обеих сторонах

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Создавайте общий секрет инструментом, а не редактором, и держите права жёсткими:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

Не путайте tls-auth с tls-crypt. Оба защищают управляющий канал, но tls-crypt ещё и шифрует его и скрывает рукопожатие от наблюдателей, и заменяет разделение направлений собственной обработкой ключей. Профиль с одним не будет работать с партнёром, настроенным на другое, и никакая настройка digest не закрывает этот разрыв.

Воспроизводите тег только из реального формата

Побайтовое воспроизведение — отдельная задача от эксплуатации VPN, и оно работает только с реальными входными данными: реализацией и версией, которые собрали пакет, выбранным digest, направлением и фактическими байтами, включая идентификатор сеанса и массив подтверждений. Текстовое представление списка полей — это не те байты.

Длина тега вытекает из digest, поэтому предположение о фиксированной длине ломается в тот момент, когда кто-то её меняет. Хэшируйте пакет так, как это делает реализация, а не так, как его представляет таблица в записи блога, и сравнивайте со снимком, взятым у того же партнёра, а не с ожиданием, выведенным вручную.

Держите это упражнение подальше от производственных профилей. Ничто в воспроизведении тега не говорит, следует ли развёртыванию включать защиту.

Откатите рассогласование, не снимая защиту

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

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

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