HTTPS 設定監査

サイトのレスポンスヘッダーを貼り付けてください。あわせて、お持ちであれば証明書、ページソースの断片、ホスト名も入力すると、このページは HTTPS 側の設定を報告します。HSTS が設定され、その期間はどれだけか、コンテンツセキュリティポリシーが安全でないリクエストをアップグレードするか、Cookie に Secure と SameSite が付いているか、サーバーバナーがバージョンを漏らしているか、プロキシヘッダーはアプリケーションが実際に見たリクエストについて何を語るか。証明書も同じレポートの中で監査され、ページソースからは平文 http:// のサブリソースが数え上げられ、ハンドシェイクを見られるコマンドが自分で実行できるよう一覧されます。すべてはブラウザー内で動作し、このページ自身は一切リクエストを行いません。
1. レスポンスヘッダー
ステータス行を含む、レスポンスヘッダーブロック全体です。最も簡単な入手方法は、ターミナルで curl -sI https://example.com/ を実行するか、ブラウザーの開発者ツールのネットワークタブにあるヘッダーパネルの内容を先頭からコピーすることです。余分なヘッダーは読み取られたうえで無視され、報告されるのは HTTPS に関係するものだけです。
2. 証明書またはチェーン（任意）
ここを入力すると、同じレポートに証明書の完全な監査も載るため、設定と証明書を一緒に読めます。PEM、裸の base64 または 16 進数の本文、PKCS#7 の .p7b はいずれも使えます。証明書単体をより深く調べるには、証明書チェッカーを使用してください。
3. ページソースの断片（任意）
ページソース（または URL を含むタグだけ）を貼り付けると、平文の http:// アドレスがすべて一覧表示されます。HTTPS で届いたページ自体に問題がなくても、HTTP で読み込まれるサブリソースは鍵マークを壊し、経路上で書き換えられ得るからです。サイト自身のホストへのアドレスは別途示されます。相対 URL で直せるのはまさにそれらだからです。
4. ホスト名（任意）
ここにホスト名を入れると、監査はブラウザーと同じ方法でサブジェクト代替名をチェックします。ワイルドカードの規則も含まれ、平文の http:// アドレスがホスト名と照合されます。
まだ監査していません
サンプルは意図的に不完全にしてあり、レポートのすべての部分に何かが入るようになっています。HSTS とコンテンツセキュリティポリシーのあるヘッダーブロック（ただし preload なし、1 つの Cookie は SameSite なし）、2 枚の証明書チェーン、平文 http:// でスクリプトを読み込むページ断片と、同じようにサイト自身のホストを指す画像です。サンプルでは F が出ます。下の所見を読んで、それぞれが何を意味するかを確認してください。
チェックされること。ヘッダーブロックからは、HSTS とその max-age、includeSubDomains、preload。安全でないリクエストをアップグレードするコンテンツセキュリティポリシー。すべての Set-Cookie の Secure、HttpOnly、SameSite フラグ。製品名とバージョンを名乗るサーバーバナー。そして、アプリケーションがリクエストを HTTPS として見たかを伝える転送ヘッダー。証明書ブロックからは、チェーンの各リンクが本当に次に署名したかまで含む証明書の完全な監査。ページソースからは、平文 http:// のサブリソース。この 3 つは別々に報告されたうえで、まとめて要約されます。壊れた鍵マークは通常、この 3 つのうちの 1 つが原因で、他の 2 つではないためです。セキュリティレスポンスヘッダーの完全な OWASP リスト（X-Content-Type-Options、フレーム保護、Referrer-Policy、Permissions-Policy、COOP、COEP、CORP と段階評価）については、同じヘッダーブロックをセキュリティヘッダーチェックページに貼り付けてください。2 つのページは、TLS 層とヘッダー層で役割を分担しています。

見られないこと。このページは TLS 接続を一切開きません。ブラウザーはハンドシェイクをページに公開しないため、プロトコルバージョン、暗号スイート、鍵交換グループ、OCSP ステープリング、セッション再開、0-RTT、稼働中のサーバーが実際に送る証明書チェーン、そして HTTP から HTTPS へのリダイレクトがオリジンで行われるかプロキシで行われるかは、どんなウェブページにも報告できません。また、ヘッダーを収集するために第三者のサイトへアクセスすることもできず、証明書が信頼されているかも言えません。それはページが読めないルートストアに依存するためです。このページの下部にあるコマンドはそれらを見られます。あなた自身のマシンで実行するためのものです。

ヘッダーブロックの入手方法。ターミナルでは、curl -sI https://example.com/ がまさにこのページが求めるものを出力します。ブラウザーでは、開発者ツールを開いてネットワークタブでページを再読み込みし、ドキュメントのリクエストを選択してレスポンスヘッダー領域全体をコピーするか、コピー → レスポンスヘッダーをコピーを使ってください。リダイレクトのチェックには、curl -sI http://example.com/ も実行して両方のブロックを貼り付けてください。ページはそれらを順番に報告します。
監査レポート
まだ監査していません。上にヘッダーブロックを貼り付けて監査を実行を押すと完全なレポートが出ます。証明書、ページソースの断片、ホスト名は任意で、それぞれが独自のセクションを追加します。
到達可能性プローブ — このページで唯一ネットワークを使う部分
ページは TLS 接続を開けませんが、通常のリクエストを試すことはできます。サイトがクロスオリジン読み取りを許可すれば、応答が最終的に到達した URL から http:// が https:// へリダイレクトされたかが分かります。この方法で証明できるのはそれだけです。リクエストが失敗した場合、ホストがダウンしているのか、自分の接続がダウンしているのか、サイトが単にクロスオリジン読み取りを許可していないのかを、このページは区別できません。最後のが最も一般的なケースです。ほとんどのサイトは Access-Control-Allow-Origin を送らないためです。http:// の URL はどのリダイレクトより先に応答されるため、これがブラウザーが平文接続で試みる唯一のことです。ボタンを押すまで、ブラウザーから何も送信されません。
ハンドシェイクを見られるコマンド
curl -sI https://example.com/ # the header block this page reads curl -sI http://example.com/ # is plain HTTP answered, or redirected? curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName nmap --script ssl-enum-ciphers -p 443 example.com testssl.sh example.com # or: docker run --rm -ti drwetter/testssl.sh example.com
これらは、あなたが管理するマシンで、テストが許されているホストに対して実行するためのものです。-showcerts の出力は証明書チェッカーにそのまま貼り付けられ、ヘッダー出力はこのページに戻して貼り付けられます。
証明書は公開文書です。公開信頼された証明書はすべて Certificate Transparency ログに公開されるため、内部名や誤記の名前であっても、中にあるホスト名は誰でも検索できます。証明書は発行者が選んだ失効チェックのアドレスも運んでおり、それが内部ホストを明かすこともあります。CDN が配る証明書がオリジンサーバーについて何も語らないのはこのためです。中の名前は CDN のものだからです。監査で予期しないホスト名が出てきたら、それは公開されているものとみなし、それが守っているものを交換してください。

プライバシー：ヘッダーブロック、証明書、ページソースはローカルで読まれ、決してアップロードされません。到達可能性プローブのボタンを押さない限り、いかなる種類のリクエストも行われません。自分の証明書を作るには自己署名証明書ジェネレーターを、秘密鍵が証明書に属するかを確認するには証明書 & 鍵マッチャーを使用してください。