OpenVPN tls-crypt-v2: что делают ключ клиента и упакованный blob

Вставка профиля tls-crypt-v2 в тикет выглядит безобидно, пока не посчитаешь, что содержит файл. Ключ канала управления клиента стоит рядом с зашифрованной копией того же ключа, а третий объект, ключ упаковки, никогда не покидает принимающий сервер. Эти три отвечают на разные вопросы о хранении, совместном использовании и выводе из эксплуатации. Их разделение снимает большинство споров о политике ещё до начала.

Что на самом деле содержит профиль

Клиентская половина tls-crypt-v2 — это ключ плюс его упакованная копия. Клиент использует открытый ключ для защиты канала управления и передаёт упакованную копию серверу при настройке, так что сервер восстанавливает тот же ключ, не храня копию в открытом виде для каждого клиента. Ключ упаковки делает это восстановление возможным и принадлежит только принимающей стороне. Всё ниже следует из того, где живут эти три объекта.

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

Почему упакованная копия — не вся история

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

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

Где находится крючок проверки в рукопожатии

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

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

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

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

Учётная запись, сертификат и ключ управления выводятся по отдельности

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

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

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

Выпуск и отзыв профиля

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

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

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