HTTP/2 sur TLS est annoncé à l'aide de l'identifiant ALPN h2 défini par la RFC 9113. Google recommande de vérifier ou de corriger chaque serveur, proxy et équilibreur de charge compatible HTTP/2 dans le chemin de la requête ; voir ses recommandations sur la CVE-2023-44487.

Installer un binaire de release

Go n'est pas requis pour exécuter l'outil. Téléchargez l'archive pour votre plateforme depuis la dernière release GitHub :

Extrayez l'archive, puis exécutez rapid-reset-check --version. Sur Windows, l'exécutable s'appelle rapid-reset-check.exe.

Chaque release inclut SHA256SUMS. Sous Linux, vérifiez une archive téléchargée depuis le même répertoire avec :

Sous macOS, comparez shasum -a 256 <archive> avec la ligne correspondante dans SHA256SUMS. Les archives publiées d'une release publique reçoivent également une attestation d'artefact GitHub, vérifiable avec la GitHub CLI :

Compiler depuis les sources

• Go 1.22 ou plus récent

Aucune installation de Node.js, cURL, nghttp2 ou WHOIS n'est requise.

Les compilations depuis les sources indiquent dev via --version ; les compilations de release reçoivent leur version du tag de release.

Démarrage rapide

Ne scannez que des points de terminaison dont vous êtes propriétaire ou que vous êtes autorisé à évaluer.

Scannez un ou plusieurs points de terminaison publics :

Les noms d'hôtes nus sont normalisés en HTTPS sur le port 443. Les URL HTTPS ne contenant que l'autorité sont également acceptées :

Scannez la liste de cibles JSON du dépôt :

Utilisez l'entrée standard pour l'automatisation :

Exécutez ./rapid-reset-check --help pour connaître toutes les limites et options de sortie.

Entrée

--input accepte le format original de tableau JSON :

Les formes objet {"urls": [...]} et {"targets": [...]} sont également prises en charge. Les cibles positionnelles et --input sont intentionnellement mutuellement exclusifs. Les points de terminaison normalisés en double sont scannés une seule fois, et chaque exécution est limitée à 4 096 cibles en entrée.

Seuls les points de terminaison HTTPS sont dans le périmètre. Les identifiants, chemins non racines, requêtes, fragments, schémas non pris en charge, ports malformés et noms d'hôtes ambigus sont rejetés plutôt que réécrits silencieusement.

Évaluations

Le rapport inclut chaque adresse résolue testée, l'ALPN négocié, la version et la suite de chiffrement TLS, des données limitées d'identité/validité du certificat, les durées, les décisions de politique, les compteurs d'adresses omises, un indicateur explicite d'exhaustivité et un résumé. Il ne collecte pas les corps de réponse, les en-têtes de réponse, les cookies ni les certificats bruts.

Paramètres sûrs par défaut

• Les certificats TLS et les noms d'hôtes sont vérifiés. Utilisez --ca-file pour ajouter une autorité de certification privée ; il n'existe aucun mode de vérification non sécurisé.
• Les adresses de bouclage, privées, de liaison locale, de multidiffusion, non spécifiées, CGNAT, de documentation, de benchmark et autres adresses réservées sont bloquées par défaut. Utilisez --allow-private uniquement pour les points de terminaison internes que vous êtes autorisé à évaluer.
• Les résultats DNS sont épinglés pour chaque connexion tandis que le nom d'hôte d'origine est conservé pour SNI et la vérification du certificat.
• La concurrence des connexions, les délais d'attente par adresse et les adresses par cible sont limités.
• Le scanner ne réessaie pas automatiquement et ne suit pas les redirections car il n'envoie jamais de requête HTTP. Soumettez chaque autorité HTTPS que vous devez évaluer.

Exemple d'options :

Pour un point de terminaison à PKI privée autorisé :

Le code de sortie 0 signifie que chaque cible a produit une observation ALPN complète. Le code de sortie 1 signifie qu'au moins une cible était invalide, bloquée par la politique ou indéterminée ; le rapport est tout de même écrit. Les erreurs d'utilisation et de configuration de la CLI retournent 2. Observer h2 ne change pas en soi le code de sortie car il s'agit d'un signal d'inventaire, pas d'un verdict de vulnérabilité.

Interpréter les résultats et agir

Pour chaque résultat h2_observed_review_required :

1. Identifiez le terminateur TLS visible de l'extérieur et tous les proxys, équilibreurs de charge, passerelles et serveurs d'origine compatibles HTTP/2 qui se trouvent derrière lui.
2. Vérifiez chaque produit et version par rapport à l'avis de son fournisseur concernant la CVE-2023-44487.
3. Appliquez les correctifs actuels et les recommandations du fournisseur en matière de réinitialisation/limitation de débit.
4. Confirmez que les contrôles anti-DDoS périphériques protègent l'origine et ne peuvent pas être contournés via un nom d'hôte, une adresse ou un port alternatif.
5. Validez la configuration et l'état des correctifs à partir d'un inventaire ou d'une télémétrie de confiance. N'utilisez pas le résultat ALPN de ce scanner comme preuve de remédiation.

Limites

Les résultats sont spécifiques au nom d'hôte, aux réponses DNS, au chemin réseau, au point de terminaison TLS et au moment du scan. Les CDN, l'anycast, le DNS à horizon partagé, l'équilibrage de charge, les ports alternatifs et les adresses non testées peuvent produire des résultats différents. Le scanner ne peut pas :

• déterminer si un serveur est vulnérable, corrigé, atténué ou sûr ;
• tester le comportement Rapid Reset ou envoyer des trames de réinitialisation ;
• inspecter le HTTP/2 en clair (h2c), QUIC/HTTP/3, les redirections, les origines cachées derrière un edge, ou les services non-HTTPS ;
• déduire l'état des correctifs à partir d'en-têtes Server usurpables ou d'empreintes CDN ;
• remplacer la revue de configuration, l'inventaire des actifs, les recommandations des fournisseurs ou les tests de charge autorisés dans un environnement isolé.

Développement

La suite de tests utilise des fixtures TLS locales et ne scanne pas de services publics.

Releases automatisées

Release Please gère les versions de release et les tags vX.Y.Z à partir des messages de Conventional Commit. Le développement normal ne nécessite pas de créer ou de pousser des tags :

1. Les commits fusionnés dans main amènent Release Please à ouvrir ou mettre à jour une PR de release contenant la version et les modifications du journal des changements.
2. La fusion de cette PR de release crée le tag de version et un brouillon de release GitHub.
3. Le même workflow teste la source taguée, effectue la compilation croisée des six archives, crée les sommes de contrôle et la provenance, téléverse les assets et publie le brouillon.

Utilisez fix: pour les changements correctifs, feat: pour les changements mineurs, et un marqueur de rupture (!) ou un pied de page BREAKING CHANGE: pour les changements majeurs. Les mainteneurs doivent activer une fois Settings > Actions > General > Workflow permissions > Allow GitHub Actions to create and approve pull requests pour permettre à Release Please de gérer sa PR.

Si la publication des assets échoue après que Release Please a créé un tag, la release reste un brouillon. Relancez manuellement le workflow Release avec ce tag vX.Y.Z existant après avoir corrigé le problème. Ne créez pas et ne poussez pas de tag de remplacement.