dxdt.blog: занимательный интернет-журнал

Недавно, в заметке про TLS-сертификаты для IP-адресов, я упоминал метод проверки права управления узлом через TLS-ALPN, который может использоваться в рамках ACME (протокол автоматического взаимодействия с Удостоверяющим Центром – УЦ). Надо заметить, это самый экзотический способ проверки из сейчас используемых. Вообще, понятно, что для IP-адресов проверять административные права через DNS – не самый разумный вариант, поскольку DNS надстроена над IP-адресным пространством и проверить не получится. В этом случае даже общепринятое название процесса DCV – Domain Control Validation – не подходит, ведь проверки “управления доменом” тут нет, а есть проверка управления узлом. Поэтому-то даже и обратная зона не сгодится: возможность внесения записей в обратную зону означает, что оператор (предположительно!) управляет соответствующим префиксом, но не обязательно управляет интернет-узлами, попадающими в адресное пространство префикса.

Схема TLS-ALPN работает в типовом варианте “запрос – подтверждение”, но выполняется на самом низком уровне TLS. Логика следующая:
проверяющая сторона, – то есть, сервис УЦ, – устанавливает с проверяемым узлом TLS-соединение, указывая в начальном сообщении (ClientHello) специальное значение в расширении ALPN – это запрос;
проверяемый узел в ответном сообщении TLS (Certificates) отправляет в качестве сигнала специально сконструированный TLS-сертификат, содержащий нужные для подтверждения параметры в расширении SAN (это дополнительные имена и IP-адреса) и в специальном расширении acmeIdentifier.

Сами значения согласуются заранее, в ходе подготовительных шагов ACME.

ALPN – Application-Layer Protocol Negotiation – это штатный инструмент TLS, но в данном случае используется уникальный идентификатор, предназначенный именно для этой схемы: “acme-tls/1”. Использование же TLS-сертификата в роли средства доставки специального сигнала – механизм пусть и причудливый, но всё же иногда используемый. Например, я в своём тестовом сервере TLS передаю сигнальный сертификат, который генерируется каждый раз в ходе установления соединения и содержит сведения об IP-клиента и выбранном способе согласования симметричных ключей. (Но в браузере вы этот сертификат увидеть не сможете, хоть он и всегда есть в сессии.)

Конечно, основной особенностью данного метода является то, что он требует достаточно низкоуровневого взаимодействия с TLS-сервером и срабатывает до того, как запросы вообще доберутся до веб-сервера. Собственно, веб-сервер тут вовсе и не участвует в процессе.

Да, в принципе, используя тот момент, что для TLS-ALPN-подтверждения сертификат нужно сгенерировать заранее, и то, что указание ALPN и имени сервера позволяет воспользоваться программным интерфейсом той или иной TLS-библиотеки, возможно прозрачно подставить сигнальный сертификат в TLS-ответ даже в том случае, когда полного контроля над TLS-сессией нет. Но схема от этого не перестаёт быть низкоуровневой и экзотической.

Адрес записки: https://dxdt.blog/2025/02/04/14985/