HTTP/2 sobre TLS se anuncia mediante el identificador ALPN h2 definido por RFC 9113. Google recomienda verificar o parchear todo servidor, proxy y balanceador de carga compatible con HTTP/2 en la ruta de la petición; consulte su guía sobre CVE-2023-44487.

Instalar un binario de lanzamiento

No se necesita Go para ejecutar la herramienta. Descargue el archivo comprimido para su plataforma desde la última versión de GitHub:

Extraiga el archivo y, a continuación, ejecute rapid-reset-check --version. En Windows, el ejecutable se llama rapid-reset-check.exe.

Cada versión incluye SHA256SUMS. En Linux, verifique un archivo descargado desde el mismo directorio con:

En macOS, compare shasum -a 256 <archive> con la línea correspondiente en SHA256SUMS. Los archivos publicados en versiones públicas también reciben una attestation de artefacto de GitHub, que puede comprobarse con la GitHub CLI:

Compilar desde el código fuente

• Go 1.22 o superior

No se requiere instalación de Node.js, cURL, nghttp2 ni WHOIS.

Las compilaciones desde el código fuente muestran dev en --version; las compilaciones de lanzamiento reciben su versión de la etiqueta de la versión.

Inicio rápido

Escaneé únicamente endpoints que usted posee o está autorizado a evaluar.

Escaneé uno o más endpoints públicos:

Los nombres de host simples se normalizan a HTTPS en el puerto 443. También se aceptan URLs HTTPS únicamente con autoridad:

Escaneé la lista de objetivos JSON del repositorio:

Use la entrada estándar para automatización:

Ejecute ./rapid-reset-check --help para ver todos los límites y opciones de salida.

Entrada

--input acepta el formato original de array JSON:

También se admiten las formas de objeto {"urls": [...]} y {"targets": [...]}. Los objetivos posicionales y --input son intencionadamente mutuamente excluyentes. Los endpoints normalizados duplicados se escanean una sola vez, y cada ejecución está limitada a 4.096 objetivos de entrada.

Solo los endpoints HTTPS están dentro del alcance. Las credenciales, rutas no raíz, consultas, fragmentos, esquemas no admitidos, puertos malformados y nombres de host ambiguos se rechazan en lugar de reescribirse silenciosamente.

Evaluaciones

El informe incluye cada dirección resuelta probada, ALPN negociado, versión y cifrado TLS, datos limitados de identidad/validez del certificado, tiempos, decisiones de política, conteos de direcciones omitidas, un indicador explícito de completitud y un resumen. No recopila cuerpos de respuesta, cabeceras de respuesta, cookies ni certificados sin procesar.

Valores predeterminados seguros

• Los certificados TLS y los nombres de host se verifican. Use --ca-file para agregar una CA privada; no existe un modo de verificación inseguro.
• Las direcciones loopback, privadas, link-local, multicast, no especificadas, CGNAT, de documentación, de benchmark y otras direcciones reservadas están bloqueadas por defecto. Use --allow-private solo para endpoints internos que esté autorizado a evaluar.
• Los resultados de DNS se fijan para cada conexión mientras se conserva el nombre de host original para SNI y verificación de certificado.
• La concurrencia de conexiones, los tiempos de espera por dirección y las direcciones por objetivo están acotados.
• El escáner no reintenta automáticamente y no sigue redirecciones porque nunca envía una petición HTTP. Envíe cada autoridad HTTPS que necesite evaluar.

Opciones de ejemplo:

Para un endpoint autorizado con PKI privada:

El código de salida 0 significa que cada objetivo produjo una observación ALPN completa. El código de salida 1 significa que al menos un objetivo fue inválido, bloqueado por política o indeterminado; el informe aún se escribe. Los errores de uso y configuración de CLI devuelven 2. Observar h2 no cambia por sí solo el código de salida porque es una señal de inventario, no un veredicto de vulnerabilidad.

Interpretar y actuar sobre los resultados

Para cada resultado h2_observed_review_required:

1. Identifique el terminador TLS visible externamente y todos los proxies, balanceadores de carga, pasarelas y servidores de origen compatibles con HTTP/2 detrás de él.
2. Compruebe cada producto y versión contra el aviso de CVE-2023-44487 de su proveedor.
3. Aplique los parches actuales y las directrices de reset/límite de velocidad del proveedor.
4. Confirme que los controles anti-DDoS del borde protegen el origin y no pueden omitirse mediante un nombre de host, dirección o puerto alternativos.
5. Valide la configuración y el estado de los parches desde inventario o telemetría de confianza. No use el resultado ALPN de este escáner como evidencia de remediación.

Limitaciones

Los resultados son específicos del nombre de host, las respuestas DNS, la ruta de red, el endpoint TLS y el momento del escaneo. Las CDN, el anycast, el DNS split-horizon, el balanceo de carga, los puertos alternativos y las direcciones no probadas pueden producir resultados diferentes. El escáner no:

• determina si un servidor es vulnerable, está parcheado, mitigado o es seguro;
• prueba el comportamiento de Rapid Reset ni envía ningún frame de reset;
• inspecciona HTTP/2 en claro (h2c), QUIC/HTTP/3, redirecciones, origins ocultos detrás de un borde ni servicios no HTTPS;
• infiere el estado de los parches a partir de cabeceras Server falsificables ni huellas de CDN;
• reemplaza la revisión de configuración, el inventario de activos, las directrices del proveedor ni las pruebas de carga autorizadas en un entorno aislado.

Desarrollo

La suite de pruebas utiliza fixtures TLS locales y no escanea servicios públicos.

Lanzamientos automatizados

Release Please gestiona las versiones de lanzamiento y las etiquetas vX.Y.Z a partir de los mensajes de Conventional Commits. El desarrollo normal no requiere crear ni enviar etiquetas:

1. Los commits fusionados en main hacen que Release Please abra o actualice un PR de lanzamiento que contiene los cambios de versión y changelog.
2. Fusionar ese PR de lanzamiento crea la etiqueta de versión y un draft de lanzamiento en GitHub.
3. El mismo flujo de trabajo prueba el código fuente etiquetado, compila de forma cruzada los seis archivos, crea sumas de verificación y procedencia, sube los recursos y publica el draft.

Use fix: para cambios de parche, feat: para cambios menores y un marcador de cambio disruptivo (!) o un pie de página BREAKING CHANGE: para cambios mayores. Los mantenedores deben habilitar Settings > Actions > General > Workflow permissions > Allow GitHub Actions to create and approve pull requests una vez para que Release Please gestione su PR.

Si la publicación de recursos falla después de que Release Please cree una etiqueta, el lanzamiento permanece como draft. Vuelva a ejecutar manualmente el flujo de trabajo Release con esa etiqueta vX.Y.Z existente después de corregir el fallo. No cree ni envíe una etiqueta de reemplazo.