概要
HTTPSは、HTTP通信をTLSで保護した仕組みです。暗号化だけでなく、接続先が本物かを確認し、改ざんを防ぐ役割もあるため、現代のWebではほぼ必須です。
HTTPSは何をしているのか
HTTPSは、HTTPそのものを置き換える別物というより、HTTP通信をTLSで包んで安全にやり取りする仕組みです。重要なのは「暗号化」「真正性の確認」「改ざん検知」です。
HTTPSは HTTP Secure と呼ばれますが、実際には HTTP over TLS と考えると理解しやすいです。
通信の流れは次のようになります。
- クライアントがサーバーへ接続する
- TLSで安全な通信路を確立する
- その上でHTTPリクエスト/レスポンスをやり取りする
HTTPSが守ろうとしている主なこと:
- 通信内容を第三者に読まれにくくする
- 接続先が本物のサーバーか確認しやすくする
- 通信途中で内容が書き換えられていないことを担保する
HTTPのままだと何が危険か
HTTPは平文通信なので、同じネットワーク上の第三者や途中経路の機器から内容を読まれたり、書き換えられたりするリスクがあります。
HTTPのままでは、次のような情報を送ることが問題になりえます。
- ログイン情報、セッションCookie、個人情報
- 決済関連データ、APIトークン、管理画面の操作内容
| リスク | 何が起きるか |
|---|---|
| 盗聴 | 通信内容を読まれる |
| 改ざん | 途中でレスポンスやリクエストを書き換えられる |
| なりすまし | 本物でないサーバーに接続させられる可能性がある |
ログイン画面自体は表示できていても、HTTPで送信していれば資格情報が危険にさらされます。
TLSが提供する3つの重要な性質
TLSを使う価値は、単なる暗号化だけではありません。機密性、完全性、真正性の3つで考えると整理しやすいです。
機密性
機密性は、通信内容を第三者に読まれにくくする性質です。
HTTPSでは通信内容が暗号化されるため、途中で通信を見られても内容を理解しにくくなります。フォーム入力、APIレスポンス、Cookie、認証情報などが対象です。
完全性
完全性は、通信内容が途中で書き換えられていないことを確認しやすくする性質です。
途中経路でJavaScriptファイルやAPIレスポンスを書き換えられると、深刻な攻撃につながります。TLSはこうした改ざんを検知しやすくします。
真正性
真正性は、接続先が本物の相手かどうかを確認するための性質です。
ここで重要になるのが証明書です。ブラウザはサーバー証明書を検証し、接続先がそのドメインの正当な運用者であることを確認しようとします。
HTTPSとTLSの関係
HTTPSの安全性を支えている中核技術がTLSです。HTTPがアプリケーション層のやり取り、TLSがその通信を保護する層、と分けて理解するとわかりやすいです。
| 要素 | 役割 |
|---|---|
| HTTP | リクエスト/レスポンスのルール |
| TLS | 通信の暗号化、改ざん検知、証明書検証 |
| HTTPS | TLS上でHTTPを使う仕組み |
HTTPのメッセージをTLSが安全な封筒に入れて運ぶようなイメージです。
証明書は何のためにあるか
証明書は、接続先サーバーがそのドメインの正当な運用者であることを示すために使われます。暗号化だけでは"相手が本物か"は保証できないため、証明書が重要です。
ブラウザが https://example.com に接続するとき、サーバーは証明書を提示します。ブラウザはその証明書を検証して、次のような点を確認します。
- 証明書の有効期限内か
- 接続先ドメイン名と一致しているか
- 信頼された認証局から発行されているか
- 改ざんされていないか
認証局とは
認証局は、証明書の発行主体として信頼される組織です。ブラウザやOSは、あらかじめ信頼する認証局の情報を持っています。
これにより、ブラウザは「この証明書は信頼できる発行元から出ている」と判断できます。
自己署名証明書との違い
| 種類 | 主な用途 | ブラウザでの扱い |
|---|---|---|
| 公的認証局の証明書 | 本番公開サイト | 基本的に信頼される |
| 自己署名証明書 | 開発、検証 | 警告が出やすい |
本番環境では、信頼された認証局の証明書を使うのが基本です。
ブラウザでHTTPS接続時に何が起きるか
ブラウザでHTTPS URLを開くと、HTTP通信の前にTLSハンドシェイクが行われます。ここで暗号方式や証明書の確認が行われます。
大まかな流れ:
- ブラウザがサーバーへ接続を開始する
- サーバーが証明書を提示する
- ブラウザが証明書を検証する
- 双方で暗号通信に使う情報を決める
- 安全な通信路が確立する
- その上でHTTP通信が始まる
実務で意識すべき観点:
- 証明書が正しいか
- 証明書の期限が切れていないか
- ドメイン名が一致しているか
- クライアントとサーバーで使えるTLSバージョンや暗号方式が合っているか
HTTPSでも見える情報と見えにくい情報
HTTPSですべてが完全に隠れるわけではありません。通信本文は保護されますが、接続先ドメインなど一部の情報は観測されうる点に注意が必要です。
HTTPSで主に保護されるもの: URLのパスやクエリの多く、リクエストボディ、レスポンスボディ、Cookie、認証ヘッダー
状況によっては観測されうるもの: 接続先IPアドレス、ドメイン名、通信の有無、通信量やタイミング
HTTPSは非常に重要ですが、「何も見えなくなる魔法」ではありません。
なぜ今はHTTPSがほぼ必須なのか
現代のWebでは、ログイン画面や決済画面だけでなく、一般的なサイトでもHTTPSが前提になっています。
主な理由:
- フォーム送信やCookieを安全に扱うため
- セッションハイジャックのリスクを下げるため
- ブラウザがHTTPを危険表示しやすくなっているため
- Service Worker や一部のWeb APIがHTTPS前提
- SEOや信頼性の観点でも不利を避けるため
Secure属性付きCookieとの関係
認証系Cookieでは Secure 属性が重要です。これはHTTPS環境でのみ安全に送られます。
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax
HTTPのままだと、こうした安全なCookie運用が難しくなります。
リダイレクトとHSTS
HTTPS運用では、単に証明書を入れるだけでなく、HTTPアクセスをHTTPSへ誘導することも重要です。さらにHSTSを使うと、ブラウザにHTTPSを強制しやすくなります。
HTTPからHTTPSへのリダイレクト
利用者が http:// でアクセスしても、https:// へ転送する設定が一般的です。
HTTP/1.1 301 Moved Permanently
Location: https://example.com/login
HSTS
HSTSは、以後このサイトにはHTTPSでのみ接続すべきだとブラウザへ伝える仕組みです。
Strict-Transport-Security: max-age=31536000; includeSubDomains
これにより、次回以降はブラウザがHTTPアクセスを避けやすくなります。設定を誤ると影響範囲が大きいため、本番では慎重に扱う必要があります。
よくある証明書エラー
HTTPSのトラブルでは、通信そのものより証明書エラーが原因になることが多いです。まずは期限、ドメイン不一致、信頼されない発行元を疑うと切り分けやすいです。
| 症状 | 原因になりやすい点 |
|---|---|
| 証明書期限切れ警告 | 有効期限切れ |
| ドメイン不一致 | api.example.com 用でない証明書を使っている |
| 信頼されない証明書 | 自己署名証明書や不正なチェーン |
| 一部端末だけ失敗 | 古いTLS対応、証明書チェーン問題 |
| 本番だけ接続失敗 | 中間証明書や設定不備 |
証明書はアクセス先ドメインと一致していなければ意味がありません。api.example.com にアクセスしているのに www.example.com 向けの証明書では失敗します。また、証明書の自動更新が失敗したことに気づかないと本番障害になるため、証明書期限の監視は実務上かなり重要です。
DevToolsやCLIで確認するポイント
HTTPSは見えにくい仕組みですが、ブラウザやCLIツールを使うとかなり観察できます。
{{image:browser_certificate_info}}
ブラウザで確認したいこと:
- アドレスバーの警告有無
- 証明書情報
- Networkタブでのリダイレクト
Strict-Transport-SecurityヘッダーSet-CookieにSecureが付いているか
# レスポンスヘッダーを確認する
curl -I https://example.com
# HTTPからHTTPSへの転送を確認する
curl -I http://example.com
# 詳細な接続情報を見る
curl -Iv https://example.com
よくあるつまずき
| 症状 | 原因になりやすい点 | 確認方法 |
|---|---|---|
| ログイン後にCookieが効かない | Secure 属性付きCookieをHTTPで使っている | Set-Cookie とURLスキームを確認する |
| ブラウザで警告が出る | 証明書不正、期限切れ | 証明書詳細を確認する |
| 一部APIだけHTTPS失敗 | サブドメイン不一致 | 接続先ホスト名と証明書を確認する |
| HTTPで開けてしまう | HTTPS強制不足 | リダイレクトとHSTSを確認する |
| 本番だけTLSエラー | LB/プロキシ設定差分 | 終端構成と証明書配置を確認する |
実務で最低限やるべきこと
HTTPSは"対応済みかどうか"だけでなく、"安全に運用できているか"が重要です。
- 本番はHTTPSを使う
- HTTPアクセスをHTTPSへリダイレクトする
- 証明書期限を監視する
- 認証Cookieに
Secureを付ける HttpOnlyやSameSiteも適切に設定する- 必要に応じてHSTSを検討する
- TLS終端がどこか（Webサーバー、ロードバランサー、CDN）を把握する
まとめ
HTTPSは、HTTP通信をTLSで保護する仕組みであり、暗号化、真正性の確認、改ざん検知を提供します。現代のWebでは、ログインや決済だけでなく、通常のWeb運用でもほぼ必須の前提です。
- HTTPSはTLS上でHTTPを使う仕組み
- TLSは暗号化、完全性、真正性を支える
- 証明書により接続先が本物か確認しやすくなる
- HTTPのままでは盗聴、改ざん、なりすましのリスクがある
Secure属性付きCookieや一部Web機能はHTTPS前提- HTTPからHTTPSへのリダイレクトやHSTSも重要
- 実務では証明書期限、ドメイン一致、TLS終端構成の把握が重要