【TLS設定不備編】暗号化されていても安心できない理由と守り方｜CTF思考フレームワーク #27

こんにちは、アンペンです。

TLSは「鍵マーク」だけでは判断できない

TLSは、通信を暗号化し、接続先の正当性を確認するための仕組みです。HTTPSでアクセスできると、ブラウザには鍵マークが表示されます。しかし、その裏側では、証明書が正しいか、期限切れでないか、ドメイン名と一致しているか、古いTLSバージョンを許していないか、弱い暗号スイートを使っていないか、いくつもの条件が関係します。

CTFでは、この「鍵マークの裏側」を読む場面があります。証明書のSANに別サブドメインが載っている。古いTLSが有効で製品や設定の古さが分かる。HTTP側にだけ重要な情報が残っている。HTTPSへリダイレクトする前のレスポンスにヒントがある。こうした見方は、単にHTTPSを開くだけでは見落としやすいです。

HTTPSで開けるなら、もう通信は安全と考えていい？

第一歩としては良いですが、それだけでは不足です。証明書の一致、期限、TLSバージョン、HSTS、HTTP側の扱いまで確認します。

観察：証明書から読む

最初に見るのは証明書です。証明書には、発行先のドメイン名、有効期限、発行者、SAN、公開鍵の種類などが含まれます。CTFでは、SANに別のサブドメインが載っていて、そこが次の入口になることがあります。実務では、証明書に出してはいけない内部名や検証環境名が含まれていないかを確認します。

openssl s_client -connect example.com:443 -servername example.com
openssl x509 -in cert.pem -noout -text
curl -Iv https://example.com/

ブラウザの証明書ビューでも確認できますが、コマンドで見ると記録しやすくなります。特にCTFのWriteupでは、どのSANを見て次に進んだのか、証明書の期限や発行者から何を考えたのかを残すと、答えに至る流れが分かりやすくなります。

仮説：証明書やリダイレクトにヒントが残る

TLS設定不備を見るときの仮説は、大きく分けて三つあります。ひとつ目は、証明書に別名が残っていることです。たとえば admin.example.com や staging.example.com がSANに載っていれば、別入口の候補になります。二つ目は、HTTPからHTTPSへの移行が不完全なことです。HTTP側に古いページ、ヒント、認証前の情報が残っている場合があります。三つ目は、古いTLSや弱い暗号が有効で、システムの古さや設定不備を示していることです。

ただし、見つけた情報はすぐに脆弱性とは言い切れません。SANにサブドメインがあること自体は通常の運用でもあります。HTTPが応答することも、HTTPSへ正しくリダイレクトしていれば問題が小さい場合があります。大切なのは、観察した事実に対して「なぜ危ない可能性があるのか」「何を確認すれば判断できるのか」を言語化することです。

証明書に別のサブドメインがあったら、それは漏えい？

必ずしも漏えいではありません。ただし、開発・管理・内部向けに見える名前なら、次に確認すべき候補になります。

検証：設定を項目ごとに分けて見る

TLS設定の検証では、ひとつの結果だけで判断しないようにします。証明書、プロトコル、暗号スイート、HTTPリダイレクト、HSTS、期限管理を分けて見ます。CTFでは、ここでヒントが見つかることがあります。実務では、各項目をチェックリスト化すると改善につなげやすくなります。

nmap --script ssl-enum-ciphers -p 443 example.com
curl -I http://example.com/
curl -I https://example.com/

失敗しやすい見方：警告がないから安全とは限らない

ブラウザが警告を出さないことと、設定が十分に強いことは同じではありません。ブラウザは、証明書が信頼され、期限切れでなく、ホスト名が一致していれば通常の閲覧を許します。しかし、TLS 1.0が残っている、HSTSがない、HTTP側でCookieが出る、古いサブドメインが証明書に残る、といった運用上の問題は、ブラウザの通常表示だけでは見えにくいです。

逆に、警告が出るから即座に攻略できる、というわけでもありません。自己署名証明書や期限切れ証明書は重要な設定ミスですが、そこから何ができるかは別問題です。CTFでは、警告の内容を読んで、ドメイン名の不一致、証明書の発行先、別名、内部名などの情報を拾います。

守る側：安全なTLS運用にする

守る側では、TLS設定を一度入れて終わりにしないことが重要です。証明書には期限があり、推奨暗号は変わり、ブラウザの要件も変化します。自動更新、設定のテンプレート化、定期スキャン、期限アラートを組み合わせて、運用として保つ必要があります。

まず、TLS 1.0/1.1のような古いプロトコルを無効化し、TLS 1.2/1.3を使います。次に、弱い暗号スイートを避け、PFSを持つ設定へ寄せます。HTTPはHTTPSへ統一し、CookieにはSecure属性を付けます。HSTSは影響範囲を理解したうえで適用します。いきなり全サブドメインへ強い設定を入れると、古いサービスが壊れることもあるため、棚卸しと段階適用が必要です。

また、証明書に載る名前を見直します。開発環境、検証環境、管理画面、内部向けサービス名が外部のCT logに出ると、攻撃者の探索を助けることがあります。名前を隠せば安全という話ではありませんが、不要な情報を減らすことは、防御側の基本です。

証明書の自動更新を入れていれば、TLS対策は十分？

期限切れ対策としては強いですが、プロトコル、暗号スイート、HTTP側、HSTS、証明書に載る名前も確認します。

演習での進め方：ブラウザ表示とコマンド結果をつなげる

TLS設定の演習では、ブラウザで見た状態とコマンドで見た状態を分けて記録すると理解しやすくなります。最初にブラウザでHTTPSページを開き、警告が出るか、通常表示されるか、証明書ビューでどの名前に発行されているかを見ます。その後、curl や openssl で同じ情報を取り直し、Writeupに残せる形にします。

ブラウザは利用者視点の確認です。警告が出る、鍵マークが出る、HTTPからHTTPSへ自動で移動する、といった見え方が分かります。一方で、コマンドは調査者視点の確認です。証明書チェーン、SAN、期限、リダイレクトのステータスコード、HSTSヘッダー、TLSバージョンの対応状況を切り分けられます。

CTFでは、この二つをつなげて考えます。たとえば、ブラウザでは普通に表示されるが、証明書のSANに dev や staging がある。HTTPでアクセスするとHTTPSへ飛ぶが、リダイレクト前に別のヘッダーや古いサーバ名が見える。TLSの対応状況から古い構成が推測できる。こうした観察が、次の仮説になります。

判断の分け方：設定不備と攻略手がかりは同じではない

TLS設定不備を読むときは、「設定として弱い」ことと「CTFで直接使える」ことを分けます。たとえば、HSTSがないことは防御上の改善点ですが、それだけで答えに直結するとは限りません。TLS 1.0が残っていることも、現実のリスクとしては重要ですが、CTFで必ず利用するとは限りません。

一方で、証明書のSANに別サブドメインがある、HTTP側にだけ古いページがある、リダイレクト先が別ホストになっている、といった情報は、次の入口探しに直結しやすいです。つまり、TLSの確認結果は「防御上の問題」と「攻略上の手がかり」に分けて読む必要があります。

この分け方をWriteupに入れると、記事の説得力が上がります。「HSTSがないため通信保護の観点では改善余地がある。ただし今回の攻略では、証明書SANに出ていた dev サブドメインが主な手がかりになった」のように書けば、読者はどの情報がどの役割を持ったのか理解できます。

実務でも同じです。すべての設定不備を同じ危険度で報告すると、対応側は優先順位を付けにくくなります。期限切れ証明書、ホスト名不一致、弱いTLS、HSTS不足、不要なSAN、HTTP側のCookieなどを分け、影響と修正のしやすさを一緒に書くと、改善につながりやすくなります。

CTFのWriteupでは、TLSの何を見たのかを書く

TLS設定不備のWriteupでは、「証明書を見たら分かった」だけでは説明が足りません。どの画面、どのコマンド、どの項目を見たのかを書きます。SANに別ホスト名があったのか。期限切れだったのか。HTTP側にヒントがあったのか。古いTLSが有効だったのか。そこからどんな仮説を立てたのかを残します。

たとえば、「openssl s_client で証明書を確認したところ、SANに dev.example.com が含まれていた。問題文が開発環境を示唆していたため、CTF範囲内で名前解決とHTTP応答を確認した」という流れなら、読者は判断の理由を追えます。

次に読みたい記事

次回は、サーバサイドのSSRF編です。外から見える設定だけでなく、サーバが内側へアクセスしてしまう構造を見ていきます。

サーバサイドSSRF編へ進む →