サイトを危険にさらす SSL/TLS の設定ミス

多くの訪問者にとって HTTPS は二択です——鍵マークが「ある」か「ない」か。しかし攻撃者にとって TLS はスペクトルです。証明書が有効で信頼されていても、その背後の設定がダウングレード攻撃を許したり、サブドメイン間で漏洩したり、来月の失効時に静かに壊れたりします。本記事では「HTTPS かどうか」の先に診断が何を見るかを解説します。

まもなく失効する証明書

失効は最も多く、最も避けられる TLS インシデントです。証明書の有効期間が短くなるなか、手動更新はもはや現実的ではありません。発行と更新を自動化し（ACME／Let's Encrypt、またはプラットフォームのマネージド証明書）、失効日ではなく十分前に警告しましょう。診断は残り日数を示すので、短命な証明書に驚かされずに済みます。

不完全な証明書チェーン

リーフ証明書は送るが中間証明書を省くサーバーは、あなたのブラウザでは動きます——すでに中間証明書をキャッシュしているからです——が、他人では失敗します。典型的な「自分の環境では動く」TLS バグです。常に完全なチェーンを提供しましょう。

openssl s_client -connect example.com:443 -servername example.com -showcerts

出力に証明書が 1 つしか表示されないなら、チェーンは不完全です。

いまだ有効な弱いプロトコルと暗号

TLS 1.0 と 1.1 は非推奨で、無効化すべきです。エクスポート級や RC4 の暗号も同様です。現代の指針：

• TLS 1.2 と TLS 1.3 のみをサポートする。
• 前方秘匿性のあるスイート（ECDHE）を優先する。
• RC4、3DES、EXPORT と付くものはすべて無効化する。
• 失効確認を速めるため OCSP ステープリングを有効にする。

HTTPS ページ上の混在コンテンツ

HTTPS ページが http:// でスクリプト・スタイルシート・画像を読み込むと、安全なはずのページに攻撃者の足場を与えます——しかもブラウザはアクティブな部分をいずれにせよブロックし、UI を壊します。すべての絶対 http:// 参照を見つけて直すか、ブラウザに自動アップグレードさせましょう。

Content-Security-Policy: upgrade-insecure-requests

HTTP から HTTPS へのリダイレクトがない

http://yoursite.com がリダイレクトせずコンテンツを返すなら、最初のアクセスはすべて平文リクエストです。すべての HTTP を 301/308 で HTTPS にリダイレクトし、HSTS で強制してブラウザが二度と HTTP を試さないようにしましょう（セキュリティヘッダーガイドの誤り#1 を参照）。

広げすぎたワイルドカード証明書

無関係なサービス全体に 1 枚の *.example.com 証明書を使うと、盗まれた秘密鍵 1 本がそのすべてを侵害します。便利ですが影響範囲を広げます。証明書の適用範囲は、実際に共有が必要なサービスに限定しましょう。

一度きりでなく、継続して確認する

TLS 設定はずれていきます。新しいサブドメイン、ロードバランサーの入れ替え、更新のし忘れ。ヘッダーに使うのと同じリズムに TLS チェックを組み込みましょう——ウェブサイトのセキュリティ診断レポートの読み方が、これらの指摘を週次計画に変える方法を扱い、料金ページが定期実行に必要な診断回数の上限を示します。