HTTPS / TLS

HTTPS / TLS とは

HTTPS は HTTP を TLS (Transport Layer Security) で暗号化したプロトコルで、通信の盗聴・改ざん・なりすましを防ぐ。TLS は SSL の後継で、最新版は 2018 年 8 月に RFC 8446 として標準化された TLS 1.3 である (2026 年 8 月時点)。主要ブラウザは HTTP のみのページを「保護されていない通信」として表示するため、公開サイトでは HTTPS が前提になっている。

TLS が提供する 3 つの保護

TLS が提供する 3 つの保護を以下にまとめる。

保護	説明	防ぐ攻撃
暗号化	通信内容を第三者が読めない	盗聴
完全性	通信内容が改ざんされていない	改ざん (中間者による書き換え)
認証	サーバーが本物であることを証明	なりすまし

TLS ハンドシェイク (TLS 1.3)

TLS ハンドシェイク (TLS 1.3) を図で示す。

クライアント → ClientHello (暗号スイート候補 + 鍵共有の材料) → サーバー
クライアント ← ServerHello (鍵共有の材料) + 証明書 + Finished ← サーバー
クライアント → Finished → サーバー
→ 暗号化通信開始 (1-RTT)

TLS 1.3 は TLS 1.2 より 1 RTT 少なく、再接続時は 0-RTT で通信を開始できる。

1 往復で済むのは、クライアントが最初の ClientHello の時点で鍵共有の材料 (key_share) を先出しするからである。共有鍵は ClientHello と ServerHello の組み合わせで決まるため、TLS 1.2 のように「暗号スイートを決めてから改めて鍵交換する」往復が要らない。

0-RTT は速いが、載せるデータを選ぶ必要がある。RFC 8446 は 0-RTT データの安全性が通常の通信より弱いことを明記しており、理由は前方秘匿性が無いこと、そして接続をまたいだ再送 (リプレイ) を防ぐ保証が無いことである。決済や注文確定のような冪等でないリクエストを 0-RTT に載せてはいけない。体感速度に効かない用途なら 0-RTT を無効にしておく判断も普通にある。

ACM はパブリック証明書を無料で発行し、期限前に自動更新する。CloudFront、ALB、API Gateway に設定できる。落とし穴はリージョンで、CloudFront に使う証明書は米国東部 (バージニア北部) で発行またはインポートする必要があり、ALB では対象のロードバランサーと同じリージョンの証明書が要る。通常の証明書はリージョンをまたいで使い回せないので、発行先を間違えたら対象リージョンで取り直すことになる。

TLS 1.2 vs TLS 1.3

TLS 1.2 と TLS 1.3 の違いを以下にまとめる。

観点	TLS 1.2	TLS 1.3
ハンドシェイク	2-RTT	1-RTT (再接続 0-RTT)
暗号スイート	多数 (脆弱なものも)	安全なもののみ
前方秘匿性	オプション	必須

HSTS

HSTS を図で示す。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

ブラウザに「このサイトには常に HTTPS でアクセスせよ」と指示するヘッダーで、2 回目以降は HTTP へのリクエスト自体が発生しなくなる。裏を返せば、ヘッダーを受け取る前の初回アクセスは守れない。その穴を埋めるのが preload だが、ヘッダーに書くだけでは効かず、hstspreload.org へ登録してブラウザ同梱のリストに載って初めて初回から HTTPS になる。登録の条件として max-age は 31536000 (1 年) 以上、includeSubDomains 付きが求められる。長い max-age は「しばらく HTTP へ戻せない」ことも意味するので、サブドメインまで HTTPS を維持できる確信を持ってから付ける。

Let's Encrypt vs ACM

Let's Encrypt と ACM の違いを以下にまとめる。

観点	Let's Encrypt	ACM
コスト	無料	無料
更新	90 日ごと (自動更新)	自動更新
対象	任意のサーバー	統合された AWS サービス (CloudFront・ALB・API Gateway 等)

基礎から学ぶなら関連書籍が手がかりになる。