HTTP/2 over TLS is advertised using the h2 ALPN identifier defined by RFC 9113. Google recommends verifying or patching every HTTP/2-capable server, proxy, and load balancer in the request path; see its CVE-2023-44487 guidance.

Install a release binary

Go is not required to run the tool. Download the archive for your platform from the latest GitHub release:

Extract the archive, then run rapid-reset-check --version. On Windows, the executable is named rapid-reset-check.exe.

Each release includes SHA256SUMS. On Linux, verify a downloaded archive from the same directory with:

On macOS, compare shasum -a 256 <archive> with the matching line in SHA256SUMS. Published public-release archives also receive a GitHub artifact attestation, which can be checked with the GitHub CLI:

Build from source

• Go 1.22 or newer

No Node.js, cURL, nghttp2, or WHOIS installation is required.

Source builds report dev from --version; release builds receive their version from the release tag.

Quick start

Only scan endpoints you own or are authorized to assess.

Scan one or more public endpoints:

Bare hostnames are normalized to HTTPS on port 443. Authority-only HTTPS URLs are also accepted:

Scan the repository's JSON target list:

Use standard input for automation:

Run ./rapid-reset-check --help for all limits and output options.

Input

--input accepts the original JSON array format:

The object forms {"urls": [...]} and {"targets": [...]} are also supported. Positional targets and --input are intentionally mutually exclusive. Duplicate normalized endpoints are scanned once, and each run is limited to 4,096 input targets.

Only HTTPS endpoints are in scope. Credentials, non-root paths, queries, fragments, unsupported schemes, malformed ports, and ambiguous hostnames are rejected instead of silently rewritten.

Assessments

The report includes each resolved address attempted, negotiated ALPN, TLS version and cipher, limited certificate identity/validity data, timing, policy decisions, omitted-address counts, an explicit completeness flag, and a summary. It does not collect response bodies, response headers, cookies, or raw certificates.

Safe defaults

• TLS certificates and hostnames are verified. Use --ca-file to add a private CA; there is no insecure verification mode.
• Loopback, private, link-local, multicast, unspecified, CGNAT, documentation, benchmark, and other reserved addresses are blocked by default. Use --allow-private only for internal endpoints you are authorized to assess.
• DNS results are pinned for each connection while the original hostname is retained for SNI and certificate verification.
• Connection concurrency, per-address timeouts, and addresses per target are bounded.
• The scanner does not retry automatically and does not follow redirects because it never sends an HTTP request. Submit each HTTPS authority you need to assess.

Example options:

For an authorized private-PKI endpoint:

Exit code 0 means every target produced a complete ALPN observation. Exit code 1 means at least one target was invalid, blocked by policy, or indeterminate; the report is still written. CLI usage and configuration errors return 2. Observing h2 does not by itself change the exit code because it is an inventory signal, not a vulnerability verdict.

Interpreting and acting on results

For every h2_observed_review_required result:

1. Identify the externally visible TLS terminator and all HTTP/2-capable proxies, load balancers, gateways, and origin servers behind it.
2. Check each product and version against its vendor's CVE-2023-44487 advisory.
3. Apply current patches and the vendor's reset/rate-limiting guidance.
4. Confirm that edge DDoS controls protect the origin and cannot be bypassed through an alternate hostname, address, or port.
5. Validate configuration and patch state from trusted inventory or telemetry. Do not use this scanner's ALPN result as evidence of remediation.

Limitations

Results are specific to the hostname, DNS answers, network path, TLS endpoint, and scan time. CDNs, anycast, split-horizon DNS, load balancing, alternate ports, and untested addresses can produce different results. The scanner does not:

• determine whether a server is vulnerable, patched, mitigated, or safe;
• test Rapid Reset behavior or send any reset frames;
• inspect cleartext HTTP/2 (h2c), QUIC/HTTP/3, redirects, origins hidden behind an edge, or non-HTTPS services;
• infer patch status from spoofable Server headers or CDN fingerprints;
• replace configuration review, asset inventory, vendor guidance, or authorized load testing in an isolated environment.

Development

The test suite uses local TLS fixtures and does not scan public services.

Automated releases

Release Please manages release versions and vX.Y.Z tags from Conventional Commit messages. Normal development does not require creating or pushing tags:

1. Commits merged to main cause Release Please to open or update a release PR containing the version and changelog changes.
2. Merging that release PR creates the version tag and a draft GitHub release.
3. The same workflow tests the tagged source, cross-compiles all six archives, creates checksums and provenance, uploads the assets, and publishes the draft.

Use fix: for patch changes, feat: for minor changes, and a breaking-change marker (!) or BREAKING CHANGE: footer for major changes. Maintainers must enable Settings > Actions > General > Workflow permissions > Allow GitHub Actions to create and approve pull requests once for Release Please to manage its PR.

If asset publication fails after Release Please creates a tag, the release remains a draft. Re-run the Release workflow manually with that existing vX.Y.Z tag after fixing the failure. Do not create or push a replacement tag.