「HTTPS化したから安全」の誤解を解く：TLSが守るもの・守らないもの

はじめに：「うちはHTTPSだから大丈夫」の危うさ

こんな会話を聞いたことはありませんか？

「セキュリティ対策はどうなってますか？」 「HTTPS化してるんで大丈夫です」

あるいは、こんなやり取り。

「このフォーム、セキュリティ大丈夫？」 「SSLで暗号化されてるから安心して」

気持ちは分かります。ブラウザに鍵マークが表示されていると、なんとなく安心しますよね。

でも、HTTPSは万能ではありません。

この記事では、TLS/SSLが「何を守っていて」「何を守っていないのか」を整理します。これを理解すると、本当に必要な対策が何かが見えてきます。

第1章：TLS/SSLとHTTPSの基本

そもそもHTTPSとは

HTTPSは「HTTP over TLS」の略です。つまり、HTTPという通信をTLSで暗号化したものです。

    HTTP  = 通信の内容が丸見え（はがき）
HTTPS = 通信の内容が暗号化（封書）
  

TLSとSSLの違い

よく混同されますが、正確には：

「SSL証明書」と呼ばれていますが、実際に使われているのはTLSです。歴史的な名残で「SSL」と呼び続けているだけです。

HTTPSが守る「3つのこと」

TLS/SSLは、以下の3つを保証します。

    graph LR
    subgraph "TLSが守る3つのこと"
        A[機密性<br/>Confidentiality]
        B[完全性<br/>Integrity]
        C[認証<br/>Authentication]
    end

    A --> A1[通信内容を暗号化<br/>第三者に読まれない]
    B --> B1[通信内容の改ざん検知<br/>途中で書き換えられない]
    C --> C1[接続先の確認<br/>偽サイトでないことを確認]

    style A fill:#4caf50,stroke:#333,color:#fff
    style B fill:#2196f3,stroke:#333,color:#fff
    style C fill:#ff9800,stroke:#333,color:#fff
  

1. 機密性：通信を暗号化し、第三者に読まれないようにする
2. 完全性：通信が途中で改ざんされていないことを保証する
3. 認証：接続先が本物であることを証明書で確認する

第2章：TLSが「守っているもの」

守られているもの①：通信経路の盗聴

HTTPSを使うと、あなたのブラウザとサーバーの間の通信が暗号化されます。

    sequenceDiagram
    participant ユーザー
    participant 攻撃者
    participant サーバー

    Note over ユーザー,サーバー: HTTP（暗号化なし）の場合
    ユーザー->>攻撃者: パスワード: secret123
    攻撃者->>サーバー: パスワード: secret123
    Note right of 攻撃者: 丸見え！

    Note over ユーザー,サーバー: HTTPS（暗号化あり）の場合
    ユーザー->>攻撃者: ※△□◎×...（暗号化）
    攻撃者->>サーバー: ※△□◎×...（暗号化）
    Note right of 攻撃者: 読めない！
  

具体的に守られるシーン：

• カフェのフリーWi-Fiでログインしても、パスワードが盗まれない
• 同じネットワークにいる悪意のある人に、通信内容を見られない
• ISP（インターネットプロバイダー）にも通信内容が見られない

守られているもの②：通信の改ざん

HTTPSでは、通信内容が途中で書き換えられると検知できます。

例：HTTPの場合（危険）

    銀行サイトで振込：100万円 → 攻撃者が改ざん → 1000万円
振込先：自分の口座 → 攻撃者が改ざん → 攻撃者の口座
  

例：HTTPSの場合（安全）

    改ざんされると通信がエラーになる
→ 改ざんは成功しない
  

守られているもの③：接続先の真正性

HTTPS（正確にはTLS証明書）は、「今アクセスしているサイトが本物かどうか」を確認できます。

例：フィッシングサイトの検知

    本物：https://www.amazon.co.jp（正規の証明書あり）
偽物：https://www.amaz0n.co.jp（正規の証明書なし or 警告）
  

ブラウザは、証明書を確認して「このサイトは本当にamazon.co.jpか？」を検証しています。

第3章：TLSが「守っていないもの」

ここからが本題です。HTTPSにしても防げない攻撃は、実はたくさんあります。

守られないもの①：SQLインジェクション

    graph LR
    A[ユーザー] -->|HTTPS| B[サーバー]
    B --> C[データベース]

    D[攻撃者] -->|HTTPS| B
    D -.->|SQLインジェクション| C

    style D fill:#f44336,stroke:#333,color:#fff
  

何が起きるか：

• 攻撃者が入力フォームに悪意のあるSQLを入力
• サーバーがそのままSQLを実行
• データベースの情報が漏洩

なぜHTTPSで防げないか：

• 通信は正規の経路で、正規の暗号化がされている
• TLSは「通信の中身が正当かどうか」は判断しない
• 暗号化されたSQLインジェクションは、ただの「暗号化されたデータ」

守られないもの②：XSS（クロスサイトスクリプティング）

何が起きるか：

• 攻撃者が掲示板などに悪意のあるJavaScriptを投稿
• 他のユーザーがそのページを閲覧
• ユーザーのブラウザで悪意のあるスクリプトが実行される

なぜHTTPSで防げないか：

• スクリプトは「サーバーから正規に配信されたコンテンツ」として扱われる
• 暗号化は「誰が送ったか」は関係ない

守られないもの③：CSRF（クロスサイトリクエストフォージェリ）

何が起きるか：

• ユーザーが銀行サイトにログイン中
• 攻撃者の罠サイトにアクセス
• 知らないうちに銀行サイトへ振込リクエストが送信される

なぜHTTPSで防げないか：

• リクエストはユーザーの正規セッションで送信される
• 「ユーザーの意図したリクエストか」はTLSの守備範囲外

守られないもの④：認証・認可の脆弱性

何が起きるか：

• 弱いパスワードが推測される
• 認可チェックの漏れで他人のデータにアクセスできる
• セッション管理の不備でセッションハイジャック

なぜHTTPSで防げないか：

• これらはアプリケーションの実装の問題
• 通信が暗号化されていても、ロジックの脆弱性は残る

守られないもの⑤：サーバー自体への侵入

何が起きるか：

• SSHの脆弱性を突かれてサーバーに侵入
• 管理画面のパスワードが漏洩
• サーバー内のファイルが盗まれる

なぜHTTPSで防げないか：

• HTTPSは「ブラウザ ↔ サーバー」間の通信を守るだけ
• サーバー自体のセキュリティは別の話

守られないもの⑥：マルウェア・フィッシング

HTTPSでも起きること：

• HTTPSのフィッシングサイトに誘導される
• HTTPSでマルウェアがダウンロードされる
• HTTPSのサイトでクレジットカード情報を入力し、攻撃者に送信される

なぜHTTPSで防げないか：

• HTTPS証明書は「このドメインの所有者」を証明するだけ
• 「このサイトが安全か」「運営者が信頼できるか」は証明しない

    攻撃者のサイト：https://secure-login-amazon.com
→ 正規のHTTPS証明書を取得可能
→ 鍵マークは表示される
→ でも詐欺サイト
  

第4章：「鍵マークの誤解」を解く

誤解①：鍵マーク = 安全なサイト

現実： 鍵マークは「通信が暗号化されている」ことを示すだけ。

• 詐欺サイトでも鍵マークは表示される
• フィッシングサイトでも鍵マークは表示される
• マルウェア配布サイトでも鍵マークは表示される

Let’s Encryptの普及により、誰でも無料でHTTPS化できるようになりました。これ自体は良いことですが、「HTTPS = 信頼できる」という誤解を生む原因にもなっています。

誤解②：証明書 = 身元保証

証明書には種類があります：

Let’s Encryptの無料証明書はDV証明書です。「このドメインを管理している」ことは証明しますが、「この組織が信頼できる」ことは証明しません。

誤解③：HTTPSなら入力しても大丈夫

現実： 入力した情報は、サーバーには届きます。

    graph LR
    A[ユーザー] -->|HTTPS暗号化| B[サーバー]
    B -->|復号化して保存| C[(データベース)]

    D[攻撃者] -.->|サーバーに侵入| C
    D -.->|DBを盗む| C

    style D fill:#f44336,stroke:#333,color:#fff
  

• サーバーが侵害されれば、データは盗まれる
• サーバー管理者は復号化されたデータを見られる
• HTTPSは「通信経路」を守るだけで、「保存されたデータ」は守らない

第5章：HTTPSの「その先」の対策

HTTPSは必要条件ですが、十分条件ではありません。以下の対策も必要です。

アプリケーションレベルの対策

インフラレベルの対策

TLS設定自体の強化

HTTPSを使っていても、設定が悪いと脆弱になります：

チェックポイント：

    □ TLS 1.2以上のみを許可しているか
□ 弱い暗号スイート（RC4、DESなど）を無効にしているか
□ HSTS（HTTP Strict Transport Security）を設定しているか
□ 証明書の有効期限を監視しているか
  

HSTSの設定例（nginx）：

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
  

これにより、ブラウザは「このサイトには常にHTTPSでアクセスする」と記憶します。

第6章：よくある質問

Q1：「HTTPSじゃないとChromeで警告が出る」からHTTPS化した。これで十分？

A：HTTPSは最低限の対策です。

Chromeが警告を出すのは「通信が暗号化されていない」ことへの警告であり、「サイトが安全になった」という証明ではありません。

HTTPSは「スタートライン」であって「ゴール」ではありません。

Q2：Let’s Encryptの無料証明書でも大丈夫？

A：通信の暗号化という点では問題ありません。

Let’s Encryptの証明書でも、TLSの暗号化強度は有料証明書と同じです。

ただし、組織の身元証明が必要な場合（銀行、EC大手など）は、OV/EV証明書の検討を。

Q3：社内システムもHTTPS化すべき？

A：はい、すべきです。

• 社内ネットワークでも盗聴のリスクはある
• 特にリモートワークが増えた今、VPN経由でも暗号化は重要
• 「社内だから安全」は過去の考え方

Q4：APIもHTTPSにすべき？

A：はい、必須です。

• API通信には認証トークンが含まれる
• トークンが盗まれると、なりすましが可能
• 内部API同士の通信もHTTPS化を検討

Q5：HTTPSにするとサイトが遅くなる？

A：現代ではほぼ影響ありません。

• TLS 1.3は以前のバージョンより高速
• HTTP/2（HTTPS必須）により、むしろ速くなることも
• CDNを使えば、TLSの処理はエッジでオフロード可能

第7章：まとめ

HTTPSが守るもの・守らないもの

覚えておくべき3つのこと

1. HTTPSは「通信経路」を守るだけ

   • 送信元・送信先・送信内容の正当性は保証しない

2. 鍵マーク ≠ 安全なサイト

   • 詐欺サイトでもHTTPS化できる
   • 暗号化と信頼は別の問題

3. HTTPSは必要条件、十分条件ではない

   • アプリケーション、インフラ、運用の対策も必要
   • 多層防御の一つとして位置づける

セキュリティチェックリスト

HTTPS関連：

• 全ページがHTTPS化されているか
• HTTPからHTTPSへリダイレクトしているか
• HSTSが設定されているか
• TLS 1.2以上のみを許可しているか
• 証明書の有効期限を監視しているか

その先の対策：

• SQLインジェクション対策（プレースホルダー）
• XSS対策（エスケープ、CSP）
• CSRF対策（トークン）
• 認証強化（MFA、強力なパスワードポリシー）
• WAFの導入検討
• 定期的な脆弱性診断

「HTTPS化したから安全」ではなく、「HTTPS化はセキュリティの第一歩」という認識を持ちましょう。

鍵マークは「通信が暗号化されている」という事実を示しているだけです。その先にあるアプリケーションの脆弱性、サーバーの設定、運用の問題は、別途対策が必要です。

HTTPSは、セキュリティ対策のスタートラインです。

関連記事

• セキュリティが苦手なWebエンジニアのための用語集 — TLS、XSS、CSRFなどの用語解説
• あなたのサーバーは毎日「下見」されている — サーバーセキュリティの基本
• 【保存版】ログ設計完全ガイド — セキュリティ監視に必要なログ設計