リリースバイナリのインストール

このツールの実行に Go は必要ありません。最新の GitHub リリース からお使いのプラットフォーム用のアーカイブをダウンロードしてください:

アーカイブを展開し、rapid-reset-check --version を実行してください。Windows では、実行ファイル名は rapid-reset-check.exe です。

各リリースには SHA256SUMS が含まれています。Linux では、同じディレクトリからダウンロードしたアーカイブを次のコマンドで検証できます:

macOS では、shasum -a 256 <archive> の出力を SHA256SUMS 内の対応する行と比較してください。公開されたパブリックリリースのアーカイブには GitHub のアーティファクト証明も付与され、GitHub CLI で確認できます:

ソースからのビルド

• Go 1.22 以降

Node.js、cURL、nghttp2、WHOIS のインストールは必要ありません。

ソースからのビルドは --version で dev と表示します。リリースビルドはリリースタグからバージョンを取得します。

クイックスタート

所有している、または評価を許可されたエンドポイントのみをスキャンしてください。

1 つ以上のパブリックエンドポイントをスキャン:

ホスト名のみの入力はポート 443 の HTTPS に正規化されます。オーソリティのみの HTTPS URL も受け付けられます:

リポジトリの JSON ターゲットリストをスキャン:

自動化のために標準入力を使用:

すべての制限と出力オプションについては ./rapid-reset-check --help を実行してください。

入力

--input は元の JSON 配列形式を受け付けます:

オブジェクト形式の {"urls": [...]} と {"targets": [...]} もサポートされています。位置引数のターゲットと --input は意図的に排他的です。重複する正規化済みエンドポイントは 1 回だけスキャンされ、1 回の実行は入力ターゲット 4,096 件に制限されます。

対象となるのは HTTPS エンドポイントのみです。資格情報、ルート以外のパス、クエリ、フラグメント、未対応のスキーム、不正なポート、曖昧なホスト名は、黙って書き換えられるのではなく拒否されます。

評価

レポートには、試行した各解決済みアドレス、ネゴシエーションされた ALPN、TLS バージョンと暗号スイート、限定された証明書の識別情報/有効性データ、タイミング、ポリシー判定、省略されたアドレス数、明示的な完全性フラグ、およびサマリーが含まれます。レスポンスボディ、レスポンスヘッダー、Cookie、生の証明書は収集しません。

安全なデフォルト設定

• TLS 証明書とホスト名は検証されます。プライベート CA を追加するには --ca-file を使用してください。安全でない検証モードはありません。
• ループバック、プライベート、リンクローカル、マルチキャスト、未指定、CGNAT、ドキュメント、ベンチマーク、およびその他の予約済みアドレスはデフォルトでブロックされます。--allow-private は、評価を許可された内部エンドポイントにのみ使用してください。
• DNS 結果は各接続に固定 (ピン) され、元のホスト名は SNI と証明書検証のために保持されます。
• 接続の並行処理数、アドレスごとのタイムアウト、ターゲットごとのアドレス数には上限があります。
• このスキャナは HTTP リクエストを一切送信しないため、自動リトライやリダイレクトの追跡は行いません。評価が必要な各 HTTPS オーソリティを個別に指定してください。

オプションの例:

認可されたプライベート PKI エンドポイントの場合:

終了コード 0 は、すべてのターゲットが完全な ALPN 観測を生成したことを意味します。終了コード 1 は、少なくとも 1 つのターゲットが無効、ポリシーによるブロック、または判定不能であったことを意味します。この場合もレポートは書き出されます。CLI の使用方法と設定のエラーは 2 を返します。h2 の観測は、それ自体では終了コードを変更しません。これは脆弱性の判定ではなく棚卸しのシグナルだからです。

結果の解釈と対応

h2_observed_review_required の結果ごとに:

1. 外部から見える TLS 終端装置と、その背後にあるすべての HTTP/2 対応プロキシ、ロードバランサー、ゲートウェイ、オリジンサーバーを特定します。
2. 各製品とバージョンを、そのベンダーの CVE-2023-44487 アドバイザリと照合します。
3. 最新のパッチと、ベンダーのリセット/レート制限に関するガイダンスを適用します。
4. エッジ DDoS 対策がオリジンを保護しており、代替ホスト名、アドレス、またはポートを通じて迂回できないことを確認します。
5. 信頼できるインベントリまたはテレメトリから設定とパッチ状態を検証します。このスキャナの ALPN 結果を是正措置の証拠として使用しないでください。

制限事項

結果は、ホスト名、DNS 応答、ネットワークパス、TLS エンドポイント、スキャン時刻に固有です。CDN、エニーキャスト、スプリットホライズン DNS、ロードバランシング、代替ポート、未テストのアドレスでは異なる結果になる可能性があります。このスキャナは以下を行いません:

• サーバーが脆弱、パッチ適用済み、緩和済み、または安全であるかを判定すること;
• Rapid Reset の挙動をテストしたり、リセットフレームを送信したりすること;
• 平文 HTTP/2 (h2c)、QUIC/HTTP/3、リダイレクト、エッジの背後に隠されたオリジン、非 HTTPS サービスを検査すること;
• 偽装可能な Server ヘッダーや CDN フィンガープリントからパッチ状態を推測すること;
• 設定レビュー、資産インベントリ、ベンダーガイダンス、隔離環境での認可された負荷テストを置き換えること。

開発

テストスイートはローカルの TLS フィクスチャを使用し、パブリックサービスをスキャンしません。

自動リリース

Release Please は、Conventional Commit メッセージからリリースバージョンと vX.Y.Z タグを管理します。通常の開発ではタグの作成やプッシュは必要ありません:

1. main にマージされたコミットにより、Release Please がバージョンとチェンジログの変更を含むリリース PR を開くか更新します。
2. そのリリース PR をマージすると、バージョンタグとドラフトの GitHub リリースが作成されます。
3. 同じワークフローが、タグ付けされたソースをテストし、6 つすべてのアーカイブをクロスコンパイルし、チェックサムと来歴 (provenance) を作成し、アセットをアップロードして、ドラフトを公開します。

パッチ変更には fix:、マイナー変更には feat: を使用し、メジャー変更には破壊的変更マーカー (!) または BREAKING CHANGE: フッターを使用してください。メンテナーは、Release Please が PR を管理できるように、Settings > Actions > General > Workflow permissions > Allow GitHub Actions to create and approve pull requests を一度有効にする必要があります。

Release Please がタグを作成した後にアセットの公開が失敗した場合、リリースはドラフトのまま残ります。失敗を修正した後、その既存の vX.Y.Z タグを指定して Release ワークフローを手動で再実行してください。代替タグを作成したりプッシュしたりしないでください。