Генератор ключей Web Bot Auth и HTTP Message Signatures

Традиционные методы идентификации поисковых роботов и AI-агентов основаны на заголовке User-Agent и проверке диапазонов IP-адресов. Заголовок User-Agent легко подделать в любом HTTP-клиенте, а поддержка актуальных списков IP-адресов требует постоянной синхронизации и часто дает сбои при использовании распределенных облачных сетей. В результате веб-мастера вынуждены блокировать подозрительный трафик целиком либо пропускать нежелательных скраперов под видом легитимных поисковых систем.

Инициатива Web Bot Auth решает эту проблему с помощью криптографической аутентификации на базе стандарта IETF RFC 9421 (HTTP Message Signatures). Вместо доверия текстовой строке сервер проверяет криптографическую подпись каждого входящего запроса. Бот подписывает заголовок своим приватным ключом, а целевой веб-сайт сверяет подпись с публичным ключом, опубликованным на официальном домене владельца бота. Данный механизм находится в статусе черновиков IETF, но уже активно внедряется ведущими поисковыми платформами и разработчиками языковых моделей.

Генератор ключей Web Bot Auth создает полноценный набор данных, необходимый для запуска аутентификации бота. В основе лежит асимметричная ключевая пара алгоритма Ed25519, создаваемая средствами Web Crypto прямо в браузере.

Инструмент формирует следующие компоненты:

• Идентификатор ключа (Key ID), рассчитанный как JWK Thumbprint по стандартам RFC 7638 и RFC 8037 с кодированием в Base64URL.
• Файл каталога ключей в формате JSON для размещения по адресу /.well-known/http-message-signatures-directory, содержащий только публичную часть ключа и опциональные метки времени действия nbf и exp.
• Заголовки ответа для каталога с образцом подписи на 24 ч.
• Приватный ключ в форматах JWK и PKCS#8 PEM для безопасного сохранения в хранилище секретов вашего бота.
• Публичный ключ в формате SPKI PEM.
• Пример подписанного запроса к целевому серверу, включающий заголовок Signature-Input с компонентами @authority и signature-agent, тегом web-bot-auth и сроком действия 5 мин, готовую команду curl и точную строку базы подписи (signature base).

Для подтверждения подлинности запросов владельцу бота необходимо опубликовать сгенерированный JSON-файл каталога ключей на своем веб-сервере. Каталог размещается по строго определенному пути: https://example.com/.well-known/http-message-signatures-directory.

При отдаче этого файла веб-сервер должен соблюдать технические требования стандарта:

1. Возвращать заголовок Content-Type: application/http-message-signatures-directory+json.
2. Отвечать по протоколу HTTPS без перенаправлений.
3. Передавать собственный заголовок цифровой подписи ответа, подтверждающий, что каталог отдан именно владельцем домена.

В реальной рабочей среде подпись ответа каталога генерируется сервером динамически с коротким сроком жизни. Если при генерации была выбрана ограниченная валидность ключа (например, на 30 дн., 90 дн. или 365 дн.), JSON будет содержать параметры nbf (not before) и exp (expiration). Это позволяет организовать плановую ротацию ключей без риска отклонения запросов робота принимающей стороной.

Формирование подписи HTTP-сообщения по стандарту RFC 9421 происходит строго детерминированным образом. Принимающая сторона должна собрать абсолютно идентичную строку базы подписи для проверки математической корректности.

Процесс подписи состоит из следующих шагов:

• Определение списка покрываемых компонентов. Для Web Bot Auth обязательными являются служебный компонент @authority (доменное имя и порт целевого ресурса) и заголовок signature-agent (HTTPS-источник бота).
• Формирование метаданных в заголовке Signature-Input. Здесь указываются параметры created (метка времени создания), expires (время истечения подписи, обычно через 5 мин), keyid (идентификатор публичного ключа), alg со значением ed25519 и тег tag="web-bot-auth".
• Сборка базы подписи (signature base). Каждое имя компонента в кавычках с двоеточием и значением помещается на отдельную строку, разделяемую символом перевода строки \n. Последней строкой добавляется служебная запись @signature-params с точным содержимым параметров подписи.
• Вычисление подписи приватным ключом Ed25519 от полученной байтовой строки базы подписи и запись результата в кодировке Base64 в заголовок Signature.

Генератор ключей Web Bot Auth работает исключительно в среде браузера с использованием встроенного API Web Crypto. Сгенерированная ключевая пара Ed25519, включая приватный ключ, никогда не отправляется по сети и не сохраняется на серверах сервиса. При перезагрузке страницы или закрытии вкладки несохраненный приватный ключ уничтожается без возможности восстановления.

После нажатия кнопки генерации необходимо сразу сохранить приватный ключ в формате JWK или PKCS#8 PEM в защищенное хранилище секретов (HashiCorp Vault, AWS Secrets Manager или зашифрованные переменные окружения). Публичный каталог ни при каких обстоятельствах не должен содержать параметр приватного ключа d. В общедоступный файл каталога попадают только открытые параметры алгоритма crv, kty и координата x.

Криптографическая подпись запросов решает задачу идентификации: сервер может однозначно доказать, что запрос отправлен конкретной организацией. Однако аутентификация не отменяет правила доступа к ресурсам сайта.

Для комплексного управления поведением краулеров используются взаимодополняющие протоколы:

• Web Bot Auth подтверждает подлинность агента и исключает маскировку спам-ботов под известные системы.
• Стандарт robots.txt определяет, какие разделы сайта разрешено сканировать роботам. Сформировать корректные директивы для современных краулеров помогает генератор robots.txt для AI, а проверить готовый файл можно через тестер robots.txt.
• Файлы llms.txt предоставляют структурированный контекст для языковых моделей и AI-ассистентов.

Сочетание цифровой подписи запросов и четких инструкций в robots.txt позволяет выстроить прозрачное и безопасное взаимодействие между владельцами контента и автоматизированными агентами.