Generador de claves Web Bot Auth para firmar solicitudes HTTP

Los bots y agentes de inteligencia artificial que navegan por la web enfrentan un problema común: los sitios los bloquean porque no pueden distinguirlos de tráfico malicioso. Tradicionalmente, se han usado el User-Agent o listas de IPs para identificarlos, pero estos métodos son fáciles de falsificar. Aquí es donde entra Web Bot Auth, un estándar en desarrollo dentro de los borradores IETF que permite a los bots firmar cada solicitud HTTP con una clave criptográfica.

La idea es simple: en lugar de confiar en señales como el User-Agent o la IP, el sitio verifica la firma digital de la solicitud usando una clave pública que el bot ha publicado previamente en una ruta conocida (/.well-known/http-message-signatures-directory). Si la firma coincide, el sitio sabe que la solicitud proviene de un bot legítimo. Esto reduce los falsos positivos y permite un control más granular sobre qué bots pueden acceder a qué recursos.

Es importante aclarar que Web Bot Auth aún no es un estándar oficial, sino un borrador en discusión. Sin embargo, ya hay implementaciones prácticas, como el generador de robots.txt para crawlers de IA, que facilitan su adopción. La ventaja de usar este sistema es que, al basarse en criptografía, es mucho más difícil de suplantar que los métodos tradicionales.

Para los desarrolladores, esto significa que pueden configurar sus bots para que sean reconocidos sin depender de listas negras o blancas de IPs, que suelen ser frágiles y difíciles de mantener. Además, al firmar cada solicitud, se genera un registro auditable que puede usarse para rastrear el comportamiento del bot, algo útil tanto para los operadores del bot como para los administradores de los sitios.

El Generador de claves Web Bot Auth es una herramienta que crea todo lo necesario para implementar el estándar en un solo paso. Al usarlo, obtienes un conjunto de archivos y datos que te permiten firmar solicitudes HTTP y publicar tu clave pública de manera correcta. Estos son los elementos que genera y su propósito:

1. Identificador de clave (key ID): Es un hash SHA-256 del JWK público, codificado en base64url. Este identificador se usa en cada firma para que el sitio sepa qué clave pública debe usar para verificarla. Por ejemplo, si tu clave pública tiene el key ID NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs, este valor aparecerá en el encabezado Signature-Input de cada solicitud.

1. Directorio de claves en formato JSON: Es un archivo que contiene tu clave pública en formato JWK, junto con metadatos opcionales como la fecha de inicio de validez (nbf) y la fecha de expiración (exp). Este archivo debe publicarse en la ruta /.well-known/http-message-signatures-directory de tu dominio. Los sitios lo consultarán para obtener tu clave pública y verificar tus firmas.

1. Encabezados de respuesta firmados: El generador incluye un ejemplo de cómo debe verse la respuesta del directorio de claves, con los encabezados Signature y Signature-Input firmados. Esto es útil para probar que tu implementación es correcta, ya que la respuesta del directorio también debe estar firmada en un entorno de producción.

1. Clave privada en formatos JWK y PKCS#8 PEM: La clave privada se genera localmente en tu navegador y nunca se envía a ningún servidor. Puedes descargarla en formato JWK (para usarla en aplicaciones web) o en PKCS#8 PEM (para herramientas como curl o servidores). Es crucial guardar esta clave en un lugar seguro, como un gestor de secretos, ya que perderla significa que tendrás que generar una nueva y actualizar el directorio de claves.

1. Clave pública en formato SPKI PEM: Este formato es útil si necesitas integrar la clave pública en sistemas que no soportan JWK, como algunos servidores o bibliotecas de criptografía.

1. Ejemplo de solicitud firmada: El generador proporciona un ejemplo completo de una solicitud HTTP firmada, incluyendo los encabezados Signature y Signature-Input, así como el comando curl equivalente. Esto te sirve como referencia para implementar la firma en tu propio bot. También incluye la signature base, que es el texto exacto que se firma y que debe coincidir byte a byte con lo que espera el servidor.

1. Firma de ejemplo con vencimiento: La solicitud de ejemplo incluye una firma que expira en 5 minuto, lo que demuestra cómo se usa el parámetro expires en el encabezado Signature-Input. Esto es útil para evitar que las firmas sean reutilizadas después de un tiempo determinado.

Todo esto se genera en tu navegador usando Web Crypto, por lo que no hay riesgo de que tu clave privada sea interceptada. Si recargas la página, la clave se pierde y tendrás que generar una nueva.

Para que los sitios puedan verificar las firmas de tu bot, debes publicar el directorio de claves en una ruta específica de tu dominio. Este directorio es un archivo JSON que contiene tu clave pública y, opcionalmente, metadatos como la fecha de inicio (nbf) y expiración (exp) de la clave. Estos son los pasos para publicarlo correctamente:

1. Genera el directorio de claves: Usa el Generador de claves Web Bot Auth para crear el archivo JSON. Asegúrate de que el origin que ingreses sea el dominio HTTPS donde alojarás el directorio, por ejemplo, https://tudominio.com. Este valor se usará como Signature-Agent en las firmas.

1. Sube el archivo a la ruta correcta: El archivo JSON debe estar disponible en /.well-known/http-message-signatures-directory. Por ejemplo, si tu dominio es tudominio.com, el archivo debe estar en https://tudominio.com/.well-known/http-message-signatures-directory. Asegúrate de que el servidor esté configurado para servir este archivo con el tipo MIME application/json.

1. Configura los encabezados de respuesta: La respuesta del directorio debe incluir los encabezados Signature y Signature-Input, que deben estar firmados con la misma clave privada que usas para firmar las solicitudes del bot. El generador te proporciona un ejemplo de cómo deben verse estos encabezados, pero en producción debes firmarlos dinámicamente cada vez que se solicite el directorio. Esto evita que alguien pueda modificar el archivo JSON sin que el sitio lo detecte.

1. Define la validez de la clave: Puedes optar por no establecer una fecha de expiración (exp) o definir una validez de 30 día, 90 día o 365 día. Si usas una clave con expiración, debes rotarla antes de que caduque y actualizar el directorio. Esto es una buena práctica de seguridad, ya que limita el tiempo en que una clave comprometida puede ser usada. Sin embargo, requiere más mantenimiento, por lo que debes evaluar qué opción se adapta mejor a tu caso.

1. Prueba el acceso al directorio: Una vez publicado, verifica que el archivo sea accesible y que los encabezados de firma sean correctos. Puedes usar herramientas como curl para hacer una solicitud y revisar la respuesta:

curl -i https://tudominio.com/.well-known/http-message-signatures-directory

Asegúrate de que el código de respuesta sea 200 OK y que los encabezados Signature y Signature-Input estén presentes.

1. Actualiza el directorio cuando cambies la clave: Si generas una nueva clave privada, debes actualizar el directorio con la nueva clave pública. Esto es especialmente importante si la clave anterior ha expirado o si sospechas que ha sido comprometida. Recuerda que, al rotar la clave, los sitios dejarán de aceptar firmas hechas con la clave antigua.

Publicar el directorio de claves es un paso esencial para que tu bot sea reconocido. Sin él, los sitios no tendrán forma de verificar tus firmas y podrían bloquear tus solicitudes.

Firmar una solicitud HTTP con Web Bot Auth implica seguir el estándar RFC 9421 (HTTP Message Signatures), que define cómo construir la firma a partir de componentes específicos de la solicitud. El proceso puede parecer complejo al principio, pero el Generador de claves Web Bot Auth te proporciona un ejemplo completo que puedes usar como referencia. Estos son los pasos clave:

1. Componentes cubiertos: La firma debe incluir ciertos componentes de la solicitud, como el método HTTP, la ruta, el encabezado Host y otros. En el caso de Web Bot Auth, los componentes típicos son: - @method: El método HTTP (por ejemplo, GET o POST). - @target-uri: La URI completa de la solicitud. - @authority: El valor del encabezado Host (por ejemplo, ejemplo.com). - signature-agent: El origin que alojó el directorio de claves (por ejemplo, https://tudominio.com). - Otros encabezados opcionales, como Content-Type o Date.

2. *Parámetros del encabezado Signature-Input**: Este encabezado define cómo se construyó la firma y qué componentes se incluyeron. Los parámetros más importantes son: - created: La marca de tiempo en la que se creó la firma, en formato Unix (segundos desde 1970). - expires: La marca de tiempo en la que la firma expira. Por ejemplo, si la firma debe ser válida por 5 minuto, este valor será created + 300. - keyid: El identificador de la clave pública, que es el key ID* generado por el Generador de claves Web Bot Auth. - alg: El algoritmo de firma, que en este caso es ed25519. - nonce: Un valor único para cada firma, que evita ataques de repetición. - tag: Un identificador opcional para el tipo de firma. En Web Bot Auth, se usa web-bot-auth.

Un ejemplo de Signature-Input podría verse así:

Signature-Input: sig1=("@method" "@target-uri" "@authority" "signature-agent");created=1712345678;expires=1712346278;keyid="NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs";alg="ed25519";nonce="abc123";tag="web-bot-auth"

1. *Construcción de la signature base**: La signature base* es el texto exacto que se firma. Se construye concatenando los componentes cubiertos, cada uno en una línea separada, con el formato "nombre-del-componente": valor. Por ejemplo:

"@method": GET
"@target-uri": https://ejemplo.com/ruta
"@authority": ejemplo.com
"signature-agent": https://tudominio.com

El Generador de claves Web Bot Auth te proporciona la signature base exacta que debes usar, lo que es útil para depurar si tus firmas son rechazadas.

1. Generación de la firma: Usando la clave privada, firmas la signature base con el algoritmo ed25519. El resultado es un valor binario que se codifica en base64url y se incluye en el encabezado Signature. Por ejemplo:

Signature: sig1=:base64url-de-la-firma:

1. Inclusión en la solicitud: Finalmente, agregas los encabezados Signature y Signature-Input a tu solicitud HTTP. Un ejemplo completo de una solicitud firmada con curl podría verse así:

curl -X GET https://ejemplo.com/ruta \
  -H "Signature: sig1=:base64url-de-la-firma:" \
  -H "Signature-Input: sig1=(\"@method\" \"@target-uri\" \"@authority\" \"signature-agent\");created=1712345678;expires=1712346278;keyid=\"NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs\";alg=\"ed25519\";nonce=\"abc123\";tag=\"web-bot-auth\""

Si la firma es correcta, el sitio podrá verificarla usando tu clave pública, que está disponible en el directorio de claves. Si hay un error, lo más probable es que la signature base no coincida con lo que espera el servidor, por lo que es importante revisar cada componente con cuidado.

La clave privada es el elemento más crítico en el sistema Web Bot Auth, ya que cualquier persona que la obtenga podrá firmar solicitudes en nombre de tu bot. Por eso, es esencial protegerla desde el momento en que se genera. El Generador de claves Web Bot Auth crea la clave directamente en tu navegador usando Web Crypto, lo que significa que nunca sale de tu dispositivo. Sin embargo, esto también implica que si cierras la página o recargas, la clave se perderá. Estos son los pasos para mantenerla segura:

1. Descarga la clave inmediatamente: Tan pronto como el generador cree la clave, descárgala en formato JWK o PKCS#8 PEM. El formato JWK es útil si planeas usarla en aplicaciones web, mientras que PKCS#8 PEM es más compatible con herramientas como curl o servidores. Guarda el archivo en un lugar seguro, como un gestor de secretos o un almacenamiento cifrado.

1. Nunca publiques la clave privada: La clave privada contiene el parámetro d en formato JWK, que es el secreto que permite firmar solicitudes. Bajo ninguna circunstancia debes compartir este valor o publicarlo en un repositorio público. Si alguien más lo obtiene, podrá suplantar a tu bot y acceder a recursos que deberían estar restringidos.

1. Usa un gestor de secretos: Herramientas como AWS Secrets Manager, Hashicorp Vault o incluso gestores locales como KeePass o 1Password son ideales para almacenar claves privadas. Estos sistemas cifran los secretos y permiten acceder a ellos solo cuando sea necesario, reduciendo el riesgo de exposición.

1. Limita el acceso a la clave: Si trabajas en equipo, asegúrate de que solo las personas autorizadas tengan acceso a la clave privada. Usa permisos granulares en tu gestor de secretos para restringir quién puede leer o usar la clave. Además, evita enviar la clave por correo electrónico o mensajería no cifrada.

1. Rota la clave periódicamente: Si has configurado una validez para la clave (por ejemplo, 90 día), asegúrate de generar una nueva clave antes de que expire y actualizar el directorio de claves. Esto limita el tiempo en que una clave comprometida puede ser usada. Si no has establecido una expiración, considera rotar la clave cada cierto tiempo como medida de seguridad adicional.

1. No confíes en el almacenamiento del navegador: El Generador de claves Web Bot Auth no guarda la clave en ningún servidor, pero tampoco la almacena en tu navegador de forma permanente. Si recargas la página, la clave se perderá. Por eso, es crucial descargarla y guardarla en un lugar seguro antes de cerrar la pestaña.

1. Prueba la clave antes de usarla en producción: Antes de implementar la clave en un entorno real, verifica que puedas firmar solicitudes correctamente y que los sitios puedan verificarlas. Usa el ejemplo de solicitud firmada que proporciona el generador para hacer pruebas en un entorno de desarrollo.

Proteger la clave privada es tan importante como generarla correctamente. Si la pierdes o es comprometida, tendrás que generar una nueva y actualizar el directorio de claves, lo que puede interrumpir el funcionamiento de tu bot hasta que los sitios actualicen su información.

Durante años, los sitios web han confiado en el encabezado User-Agent y en listas de IPs para identificar bots y agentes de inteligencia artificial. Sin embargo, estos métodos tienen limitaciones importantes que Web Bot Auth busca resolver. Aquí te explicamos las diferencias clave y por qué la firma criptográfica es una alternativa más robusta:

1. User-Agent: fácil de falsificar: El User-Agent es un encabezado HTTP que indica el navegador o cliente que realiza la solicitud. Por ejemplo, un bot podría enviar User-Agent: Googlebot para hacerse pasar por el rastreador de Google. Aunque algunos sitios verifican que el User-Agent coincida con una IP conocida de Google, este método es frágil, ya que las IPs pueden cambiar o ser compartidas. Además, cualquier persona puede modificar el User-Agent de su solicitud, lo que lo convierte en una señal poco confiable.

1. Verificación por IP: costosa y poco escalable: Algunos sitios mantienen listas blancas de IPs para permitir el acceso de bots legítimos. Sin embargo, esto requiere un mantenimiento constante, ya que las IPs pueden cambiar o ser reasignadas. Además, en un mundo donde muchos bots operan desde la nube (por ejemplo, en servicios como AWS o Google Cloud), las IPs pueden ser compartidas por múltiples clientes, lo que dificulta su identificación. Esto también puede generar falsos positivos, bloqueando tráfico legítimo o permitiendo el acceso a bots maliciosos.

3. Web Bot Auth: criptografía en lugar de señales frágiles: En lugar de depender de User-Agent o IPs, Web Bot Auth usa firmas digitales para probar la identidad del bot. Cada solicitud incluye una firma generada con una clave privada, que el sitio verifica usando la clave pública publicada en el directorio de claves. Esto tiene varias ventajas: - No es falsificable: A diferencia del User-Agent, una firma criptográfica no puede ser generada sin la clave privada. - No depende de IPs: El bot puede operar desde cualquier ubicación, siempre que tenga acceso a su clave privada. - Auditable: Cada firma incluye un nonce y una marca de tiempo, lo que permite rastrear las solicitudes y detectar intentos de repetición.

1. Complementariedad con otros controles: Aunque Web Bot Auth identifica al bot, no define qué recursos puede acceder. Para eso, siguen siendo útiles archivos como robots.txt o llms.txt, que especifican las reglas de acceso. Por ejemplo, puedes usar el generador de robots.txt para crawlers de IA para definir qué rutas puede rastrear tu bot, mientras que Web Bot Auth garantiza que el sitio reconozca su identidad.

1. Desafíos de implementación: Aunque Web Bot Auth es más seguro, también es más complejo de implementar que enviar un User-Agent o configurar una lista de IPs. Requiere generar y gestionar claves criptográficas, firmar cada solicitud y publicar el directorio de claves. Sin embargo, herramientas como el Generador de claves Web Bot Auth simplifican este proceso, proporcionando todo lo necesario en un solo paso.

En resumen, Web Bot Auth no reemplaza por completo a los métodos tradicionales, pero ofrece una capa adicional de seguridad y confiabilidad. Si tu bot necesita acceder a recursos sensibles o quieres evitar ser bloqueado por error, la firma criptográfica es la mejor opción. Para casos más simples, como rastrear contenido público, el User-Agent y las listas de IPs pueden seguir siendo suficientes.

Estas son las dudas más comunes que surgen al usar el Generador de claves Web Bot Auth y al implementar el estándar en general:

¿Cómo configuro Web Bot Auth para mi bot? Primero, usa el generador para crear una clave privada y el directorio de claves. Publica el directorio en /.well-known/http-message-signatures-directory de tu dominio y configura tu bot para firmar cada solicitud con la clave privada. El generador te proporciona un ejemplo completo de cómo debe verse una solicitud firmada.

¿Es gratis el Generador de claves Web Bot Auth? ¿Necesito registrarme? Sí, el generador es completamente gratuito y no requiere registro. Todo el proceso se realiza en tu navegador, sin que la clave privada se envíe a ningún servidor.

*¿Qué es el key ID y cómo se calcula? El key ID es un identificador único para tu clave pública, calculado como el hash SHA-256 del JWK público, codificado en base64url. Este valor se usa en el encabezado Signature-Input para que el sitio sepa qué clave pública debe usar para verificar la firma. Por ejemplo, si tu JWK público es {"kty":"OKP","crv":"Ed25519","x":"..."}, el key ID* será el hash de este JSON.

¿Por qué se usa el algoritmo Ed25519? Ed25519 es el algoritmo recomendado en los borradores de Web Bot Auth porque ofrece un buen equilibrio entre seguridad y rendimiento. Las claves son pequeñas (32 bytes para la clave privada y 32 bytes para la pública) y las firmas son rápidas de generar y verificar. Además, Ed25519 produce firmas deterministas, lo que significa que firmar el mismo mensaje dos veces generará la misma firma, algo útil para depuración.

*¿Qué es la signature base y por qué es importante? La signature base es el texto exacto que se firma con la clave privada. Se construye concatenando los componentes cubiertos de la solicitud, como @method, @target-uri y @authority, cada uno en una línea separada. Si la signature base no coincide byte a byte con lo que espera el servidor, la firma será rechazada. El generador te proporciona la signature base* exacta que debes usar, lo que es útil para depurar errores.

¿Se envía mi clave privada a algún servidor? No. La clave privada se genera localmente en tu navegador usando Web Crypto y nunca se transmite a ningún servidor. Si recargas la página, la clave se pierde y tendrás que generar una nueva.

Recargué la página y la clave desapareció. ¿Qué hago? Esto es intencional. El generador no almacena la clave en ningún lugar, por lo que si cierras la página, la clave se pierde. Debes generar una nueva clave y volver a publicar el directorio de claves en tu servidor.

*Mi navegador no puede generar claves o rechaza el origin. ¿Qué pasa? Para generar claves Ed25519, necesitas un navegador moderno como Chrome, Firefox o Safari. Además, el origin debe ser una URL HTTPS sin ruta (por ejemplo, https://tudominio.com). Si usas un navegador antiguo o un origin* inválido, el generador no funcionará.

¿Debo elegir una validez para la clave o dejarla sin expiración? Depende de tu caso. Si eliges una validez (por ejemplo, 90 día), deberás rotar la clave antes de que expire, lo que requiere más mantenimiento pero mejora la seguridad. Si dejas la clave sin expiración, no tendrás que rotarla, pero una clave comprometida podría ser usada indefinidamente. Evalúa qué opción se adapta mejor a tus necesidades.

*¿Cómo se compara Web Bot Auth con la verificación por User-Agent o IP? Web Bot Auth usa criptografía para probar la identidad del bot, lo que es mucho más seguro que depender de señales como el User-Agent o listas de IPs, que son fáciles de falsificar o frágiles. Sin embargo, implementar firmas requiere más esfuerzo que enviar un User-Agent* o configurar una lista de IPs. Para más detalles, consulta el artículo sobre diferencias entre Web Bot Auth y métodos tradicionales.