#はじめに
「このサイトは安全ではありません」——ブラウザにこの警告が表示されたら、ユーザーは離脱してしまいます。
現代のWebでは、HTTPSは「あれば良い」ではなく「必須」です。検索順位、ブラウザの警告、一部のWeb APIの利用制限など、HTTPSでなければできないことが増えています。
この記事を読むと、以下のことができるようになります:
- HTTPとHTTPSの違いを理解できる
- TLS/SSLの役割と仕組みがわかる
- 証明書とは何か、なぜ必要かがわかる
- 混合コンテンツ問題を理解し、対処できる
#HTTPの問題点
HTTPには3つの大きなセキュリティ上の問題があります。
#1. 盗聴(Eavesdropping)
HTTPの通信は暗号化されていないため、第三者が通信内容を見ることができます。
[あなた] ----パスワード: secret123----> [サーバー]
↑
[攻撃者が盗み見]
公共Wi-Fiなど、信頼できないネットワークでは特に危険です。
#2. 改ざん(Tampering)
通信経路上で、データを書き換えられる可能性があります。
[あなた] ----振込先: 正しい口座----> [攻撃者] ----振込先: 攻撃者の口座----> [サーバー]
#3. なりすまし(Impersonation)
本物のサイトになりすました偽サイトに誘導される可能性があります。
[あなた] ----ログイン情報----> [偽bank.example.com]
(本物に見えるが偽物)
#HTTPSとは
HTTPS(HTTP Secure)とは、HTTPにTLSによる暗号化を加えた通信プロトコルです。
HTTPSは上記の3つの問題を解決します:
| 問題 | HTTPSの解決策 |
|---|---|
| 盗聴 | 通信を暗号化し、第三者が読めなくする |
| 改ざん | データの完全性を検証し、改ざんを検知する |
| なりすまし | 証明書でサーバーの身元を確認する |
URLがhttp://ではなくhttps://で始まっていれば、その通信はHTTPSで保護されています。
#TLS/SSLとは
TLS(Transport Layer Security)とは、通信を暗号化し、安全にデータをやり取りするためのプロトコルです。
SSLはTLSの前身で、現在は使用されていません。「SSL証明書」という呼び方が残っていますが、実際にはTLSが使われています。
| 名称 | 状態 |
|---|---|
| SSL 2.0, 3.0 | 廃止(脆弱性あり) |
| TLS 1.0, 1.1 | 廃止推奨 |
| TLS 1.2 | 現役(広く使用) |
| TLS 1.3 | 現役(最新、推奨) |
#TLSの仕組み
TLSによる安全な通信は、以下の3ステップで実現されます。
#ステップ1: ハンドシェイク
クライアントとサーバーが「安全な通信の準備」をします。
[クライアント] [サーバー]
| |
|------- 1. ClientHello ------------------>|
| (対応するTLSバージョン、暗号方式) |
| |
|<------ 2. ServerHello ------------------|
| (選択したTLSバージョン、暗号方式) |
|<------ 3. 証明書 ------------------------|
|<------ 4. 鍵交換データ -------------------|
| |
|------- 5. 鍵交換データ ------------------>|
|------- 6. 暗号化開始通知 ---------------->|
| |
|<------ 7. 暗号化開始通知 ----------------|
| |
|====== 暗号化された通信開始 ===============|
このハンドシェイクで、両者が共有する「セッション鍵」が生成されます。
#ステップ2: 暗号化通信
ハンドシェイクで生成したセッション鍵を使って、通信内容を暗号化します。
平文: {"password": "secret123"}
↓ 暗号化
暗号文: x7Fj2kL9mNpQrStUvWxYz...
第三者が傍受しても、鍵がなければ内容を読めません。
#ステップ3: 改ざん検知
送信データにはMAC(Message Authentication Code)が付与されます。受信側でMACを検証し、データが改ざんされていないことを確認します。
#証明書とは
証明書(TLS証明書、SSL証明書)とは、Webサイトの「身分証明書」です。
証明書には以下の情報が含まれています:
- ドメイン名(このサイトは example.com である)
- 公開鍵(暗号化に使う鍵)
- 有効期限
- 発行者(認証局)の署名
#認証局(CA)の役割
認証局(Certificate Authority)は、証明書を発行する「信頼できる第三者機関」です。
[example.com] ---申請---> [認証局]
↓ 審査・発行
<--証明書----
ブラウザには、信頼できる認証局のリストがあらかじめ登録されています。証明書がこのリストの認証局から発行されていれば、ブラウザは「このサイトは本物」と判断します。
#証明書の種類
| 種類 | 検証内容 | 用途 |
|---|---|---|
| DV(Domain Validation) | ドメインの所有権 | 個人サイト、ブログ |
| OV(Organization Validation) | ドメイン + 組織の実在性 | 企業サイト |
| EV(Extended Validation) | ドメイン + 組織の詳細審査 | 銀行、ECサイト |
Let’s Encrypt は無料でDV証明書を発行する認証局で、個人サイトでも簡単にHTTPS化できます。
#DevToolsで証明書を確認する
- HTTPSサイト(例: https://example.com)にアクセス
- アドレスバーの鍵アイコンをクリック
- 「この接続は保護されています」→「証明書は有効です」をクリック
- 証明書の詳細を確認:
- 発行先(Subject)
- 発行者(Issuer)
- 有効期限
DevToolsのSecurityタブでも確認できます:
- DevToolsを開く(
F12) - 「Security」タブを選択
- 接続の詳細と証明書情報を確認
#混合コンテンツ(Mixed Content)
混合コンテンツとは、HTTPSページ内でHTTPリソースを読み込むことです。
<!-- HTTPSページ内で -->
<img src="http://example.com/image.jpg"> <!-- HTTPリソース -->
#なぜ問題なのか
HTTPSページでも、一部がHTTPで読み込まれると、その部分は暗号化されません。攻撃者がそのHTTPリソースを改ざんする可能性があります。
#混合コンテンツの種類
| 種類 | 例 | ブラウザの対応 |
|---|---|---|
| パッシブ | 画像、動画、音声 | 警告表示(読み込まれる) |
| アクティブ | スクリプト、iframe | ブロック(読み込まれない) |
アクティブな混合コンテンツは、ページの動作に影響を与える可能性があるため、ブラウザがブロックします。
#対処法
すべてのリソースをHTTPSで読み込むようにします:
<!-- 修正前 -->
<img src="http://example.com/image.jpg">
<!-- 修正後 -->
<img src="https://example.com/image.jpg">
<!-- または、プロトコル相対URL(非推奨だが見かけることがある) -->
<img src="//example.com/image.jpg">
DevToolsのConsoleタブで混合コンテンツの警告を確認できます。
#HTTPSが必要な理由
セキュリティ以外にも、HTTPSを使うべき理由があります。
#1. ブラウザの警告回避
Chromeなど主要ブラウザは、HTTPサイトに「保護されていない通信」と警告を表示します。
#2. 検索順位への影響
GoogleはHTTPSをランキング要因の一つとしています。
#3. 一部のWeb APIはHTTPSが必須
以下のAPIはセキュアなコンテキスト(HTTPS)でのみ利用可能です:
- Geolocation API
- Service Workers
- Web Bluetooth
- Web Crypto API
- HTTP/2
#4. HTTP/2とHTTP/3の利用
主要ブラウザはHTTPS接続でのみHTTP/2とHTTP/3をサポートしています。
#まとめ
- HTTPは盗聴・改ざん・なりすましのリスクがある
- HTTPSはHTTP + TLSで、これらの問題を解決する
- TLSは暗号化、完全性検証、認証を提供する
- 証明書はサイトの身分証明書、認証局が発行する
- 混合コンテンツはHTTPS内でHTTPリソースを読み込むこと、避けるべき
- HTTPSは必須: ブラウザ警告、SEO、Web API、パフォーマンス
#次のステップ
HTTPSの仕組みがわかったところで、次はHTTP/2とHTTP/3について学びましょう。「なぜHTTP/2は速いのか」「QUICとは何か」——最新のHTTPプロトコルを理解することで、パフォーマンス最適化の選択肢が広がります。