SSLストリッピング攻撃とは？HTTPSを無効化する中間者攻撃の手口とHSTSによる対策をわかりやすく解説

「うちのサイトはHTTPSだから安全」──そう思っているなら、SSLストリッピング攻撃について確認していただきたいことがあります。この攻撃は、HTTPSをHTTPに「降格」させることで、暗号化された通信を平文で傍受するものです。ブラウザのアドレスバーから鍵マークが消えるだけで、ユーザーはほとんど気づきません。

この記事では、SSLストリッピング攻撃の仕組みと、最も有効な防御手段であるHSTSの設定手順を現場で使えるレベルで解説します。Webサーバーを管理するエンジニアや、社内サイトのHTTPS化を担当する情シスの方に、特に読んでいただきたい内容です。

SSLストリッピング攻撃とは？

SSLストリッピング（SSL Stripping）は、2009年にセキュリティ研究者のMoxie Marlinspike氏がBlack Hatカンファレンスで発表した攻撃手法です。「ストリッピング」とは「剥ぎ取る」を意味し、HTTPS通信の暗号化レイヤーを剥ぎ取ってHTTPに降格させることが攻撃の核心です。

この攻撃が成立すると、攻撃者はユーザーとWebサーバーの「中間」に割り込みます。ユーザーのブラウザと攻撃者の間はHTTP（平文）で通信し、攻撃者とサーバーの間はHTTPSで接続されます。サーバー側は正常なHTTPS通信と認識するため、ログには何も残りません。

・被害の深刻さ: ログイン情報・クレジットカード番号・セッションCookieなど、あらゆる平文通信が傍受対象になります
・検知の難しさ: アドレスバーに鍵マークが表示されないため、注意深いユーザーでないと気づかないまま操作を続けてしまいます
・現在も有効な脅威: 公衆Wi-Fiなど攻撃者がネットワークに割り込みやすい環境では、今日でも現実的な攻撃手法として通用します

攻撃の仕組み（3ステップで理解する）

SSLストリッピングがどのように機能するか、順を追って確認します。

ステップ1: 中間者の位置に割り込む
攻撃者はARPスプーフィングなどを使い、同一ネットワーク上の被害者の通信を自分のPCに転送させます。公衆Wi-Fiや社内ゲストWi-Fiなど、同じL2ネットワーク上にいれば成立します。

ステップ2: HTTPSをHTTPに書き換える
ユーザーがブラウザに「example.com」と入力すると、最初にHTTPでアクセスしようとします。攻撃者のPCがそのHTTPリクエストを受け取り、代わりにサーバーへHTTPS接続します。サーバーのレスポンスをHTTPS経由で受け取り、ユーザーにはHTTPで返します。

ステップ3: 平文通信を傍受する
ユーザーのブラウザはHTTPで通信していると認識するため、フォームの入力内容もパスワードも暗号化されずに流れます。攻撃者はこれをすべて平文で読み取ることができます。

具体的な防御手順

SSLストリッピングに対して最も効果的な防御は、HSTS（HTTP Strict Transport Security）の導入です。HSTSは「このサイトは今後HTTPS以外では接続を受け付けない」とブラウザに宣言するHTTPレスポンスヘッダーです。一度HSTSを受け取ったブラウザは、指定期間内はHTTPへの接続を自動的にHTTPSへ切り替えます。

1. HSTSヘッダーをサーバーに設定する

NginxおよびApacheの設定例を示します。必ずHTTPS（port 443）のサーバーブロックまたはVirtualHostブロックに追加してください。

Nginxの場合

# server ブロック内（HTTPS設定済み）に追加
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apacheの場合

# VirtualHost（HTTPS）ブロック内に追加
# mod_headers が必要: sudo a2enmod headers
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

各パラメータの意味は次のとおりです。

設定後、HSTSヘッダーが正しく出力されているか確認します。

# curlでHTTPSヘッダーを確認
curl -I https://example.com | grep -i strict

# 出力例
# strict-transport-security: max-age=31536000; includeSubDomains; preload

セキュリティヘッダー全体の設定方法については、当サイトの記事「HTTPSだけでは足りない｜セキュリティヘッダー完全ガイド（CSP・HSTS・X-Frame-Options）設定と確認方法」も参考にしてください。

2. HSTSプリロードリストに登録する

HSTSには一つ重要な弱点があります。ブラウザが初めてそのサイトにHSTSヘッダー付きでアクセスするまでの「初回接続」は保護されません。初回訪問時だけはSSLストリッピングが理論上成立しうるのです。

この弱点を解消するのがHSTSプリロードリストです。Chromiumプロジェクトが管理するこのリストにドメインを登録しておくと、Chrome・Firefox・Safari・Edgeはブラウザ自体にそのドメインを「HTTPS必須」として組み込みます。インストール時点から初回接続でもHTTPS強制が効くため、SSLストリッピングの完全な防御につながります。

・登録要件: max-age=31536000以上、includeSubDomainsとpreloadを両方含むHSTSヘッダーが必要です
・全サブドメインのHTTPS対応が必須: プリロード登録後はすべてのサブドメインでHTTPSが必須となります。HTTPしか対応していないサブドメインが残っていると、そのサブドメインへのアクセスが完全に不可能になります。登録前に全サブドメインの対応状況を必ず確認してください
・申請方法: hstspreload.org から登録申請を行います（無料）
・反映まで: Chromeへの反映に数週間程度かかります。削除はさらに時間がかかるため、慎重に判断してください

3. HTTPをHTTPSへ自動リダイレクトする

HSTSを設定しても、HTTP（port 80）でのアクセスを正しくリダイレクトする設定が必要です。

Nginxの場合

# HTTP（port 80）のserverブロック
server {
    listen 80;
    server_name example.com www.example.com;
    # 301リダイレクトでHTTPSへ転送
    return 301 https://$host$request_uri;
}

Apacheの場合

# HTTP（port 80）のVirtualHostブロック

    ServerName example.com
    Redirect permanent / https://example.com/

TLSのバージョン設定も合わせて見直すと安心です。TLS 1.0/1.1はブラウザから廃止済みですが、サーバー側での無効化は別途確認が必要です。詳細は当サイトの記事「TLS 1.3移行完全ガイド｜古いSSL/TLSを廃止して暗号スイートを安全化するApache・Nginx設定の実践手順」で解説しています。

中小企業でも今日からできること

「Webサーバーを直接操作できるエンジニアがいない」という環境でも、取れる対策があります。

・WordPressの場合: 管理画面「設定 → 一般」でサイトURLを「https://」から始まるものに変更し、「Really Simple SSL」などのプラグインを使うとHSTSヘッダーの出力設定をGUI操作で行えます
・レンタルサーバーの場合: エックスサーバーやさくらインターネットなどの主要レンタルサーバーは、コントロールパネルのSSL設定からHTTPS強制やHSTSの有効化ができます。各社のサポートドキュメントを確認してください
・クラウド（AWS）の場合: ALBのリスナールールでHTTP→HTTPSリダイレクトを設定し、CloudFrontでHTTPS Only（Viewer Protocol Policy）を選択します
・動作確認: Qualys SSL Labs（ssllabs.com/ssltest/）でドメインをテストすると「HSTS: Yes（preloaded）」など、HSTSの設定状況を無料で確認できます

また、Linuxサーバーでの実際の設定手順については、姉妹サイトLinuxMaster.JPでNginx・Apacheの詳細設定を解説しています。

よくある誤解と注意点

【誤解1】HTTPSにすれば攻撃は防げる

「サイトをHTTPS化した」だけでは不十分です。HSTSを設定していなければ、特に初回アクセス時にSSLストリッピングが成立しうる状況は残ります。HTTPSは「通信経路を暗号化する仕組み」ですが、「ユーザーが必ずHTTPSで接続するよう強制する」仕組みはHSTSが担います。両者は役割が異なります。

【誤解2】プリロード登録は気軽に取り消せる

一度HSTSプリロードリストに登録すると、削除には数か月かかることがあります。その間、すべてのサブドメインでHTTPSが強制されます。「とりあえず登録してみよう」という判断は危険です。登録前にすべてのサブドメインのHTTPS対応を確認し、長期的に維持できる体制かどうかを確認してから申請してください。

【誤解3】社内ネットワークなら安全

SSLストリッピングは公衆Wi-Fiのような環境で成立しやすいですが、内部不正やゲストWi-Fiからの侵入があれば社内LANでも同様の攻撃は可能です。「社内ネットワークだから安全」という前提は、ゼロトラストの観点からすでに時代遅れです。

【注意】HSTSはWebブラウザへの宣言であり、サーバー側の設定変更を保証しない

HSTSはあくまで「ブラウザにHTTPS強制を指示する」ヘッダーです。設定ミスのあるサーバーやHTTPで動いているAPIエンドポイントを自動的に修正する機能はありません。HSTSを設定するとともに、サービス全体のHTTPS対応状況を棚卸しすることが重要です。

本記事のまとめ

SSLストリッピングは「HTTPS＝絶対安全」という思い込みを突いてくる攻撃です。対策はシンプルです。HSTSヘッダーを設定し、全サブドメインのHTTPS対応を確認したうえでプリロードリストへの登録を検討する──この手順を踏むだけで、ほとんどのSSLストリッピングリスクは排除できます。「後でやろう」と先送りにせず、今日の業務の中で一度設定を確認してみてください。