HTTPS と TLS ハンドシェイク

HTTPS と TLS ハンドシェイク

解説

このレッスンで分かること

• HTTPS は HTTP を TLS で暗号化したプロトコルで、機密性・完全性・認証の 3 要素を保証します
• TLS 1.3 が現代の推奨で、1 RTT (再開時 0 RTT) のハンドシェイクで体感が大幅改善
• Let's Encrypt の登場で Web 全体の HTTPS 化が進み、現在は HTTP のままだと警告が出るのが当たり前

解説

HTTPS と TLS ハンドシェイク とは

暗号化通信 HTTPS と、TLS で鍵を共有する流れを理解します。本レッスンでは、HTTPS と TLS ハンドシェイク の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

TLS バージョン比較

このレッスンで学ぶこと

HTTPS と TLS の仕組みを理解します。なぜブラウザの URL バーに鍵マークが付くと安全なのか、その裏でどんなハンドシェイクが行われているのかを学びましょう。

HTTPS とは

HTTPS は HTTP を TLS (Transport Layer Security) で暗号化したものです。https:// の URL はすべて HTTPS で通信し、ポートは 443 番が標準です。

HTTPS が保証するのは下記の 3 つです。

• 機密性 (暗号化) — 第三者がパケットを盗聴しても中身が読めない
• 完全性 (改ざん検知) — 経路の途中で書き換えられたら気づける
• 認証 (なりすまし防止) — 通信相手が正しいサーバーであることを確認できる

TLS の歴史

• SSL 2.0 (1995) / 3.0 (1996) — 古くて脆弱、現在は使用禁止
• TLS 1.0 (1999) / 1.1 (2006) — 同じく非推奨
• TLS 1.2 (2008) — 長く主流だったが徐々に置き換え中
• TLS 1.3 (2018) — 現在の推奨。1 RTT で確立、0 RTT 再開もある

慣習で「SSL 証明書」と呼びますが、実態は TLS 証明書です。

TLS ハンドシェイクの大まかな流れ

TCP 3-way ハンドシェイクの後、TLS のハンドシェイクが続きます。TLS 1.3 の場合は次のとおりです。

1. ClientHello — クライアントがサポートする暗号スイートと鍵交換情報を送る
2. ServerHello — サーバーが選んだ暗号スイートと鍵交換情報、証明書、署名を送る
3. Finished — お互いハンドシェイクの完了を確認

これで暗号鍵が共有され、以降のデータは暗号化されてやりとりされます。TLS 1.3 では 1 往復 (1 RTT) で完了するので、TLS 1.2 の 2 RTT より体感が速いです。

サーバー証明書

サーバー証明書は「このドメインの公開鍵は確かにこのサーバーのもの」と認証局 (CA) が保証する電子文書です。証明書には下記が入っています。

• ドメイン名 (CN, SAN)
• 公開鍵
• 発行者 (CA)
• 有効期限
• CA の署名

ブラウザはルート証明書 (信頼している CA のリスト) を OS や自前で持っていて、サーバーの証明書が「信頼チェーン」をたどって信頼できる CA にたどり着けるかを検証します。たどり着けないと「この接続は安全ではありません」と警告が出ます。

鍵交換と暗号スイート

TLS の中では、下記の暗号技術を組み合わせて使います。

• 鍵交換 — ECDHE (楕円曲線ディフィー・ヘルマン) で一時鍵を生成。Forward Secrecy を実現。
• 認証 — RSA / ECDSA 署名でサーバー証明書の正当性を担保。
• 対称暗号 — AES-GCM, ChaCha20-Poly1305 でデータを高速に暗号化。
• ハッシュ — SHA-256 などで改ざんを検知。

これらの組み合わせを「暗号スイート (Cipher Suite)」と呼び、ClientHello と ServerHello でお互い対応している組を選びます。

SNI と HTTPS

1 つの IP / ポートで複数のドメインの HTTPS をホスティングするには SNI (Server Name Indication) を使います。クライアントが ClientHello で「これから talk したいドメインはこれ」と平文で伝えるので、サーバーは適切な証明書を選んで返せます。

ただし SNI は平文なので、どのドメインに接続しているかが第三者にも分かる、というプライバシー上の課題があります。ESNI / ECH (Encrypted Client Hello) という拡張で、SNI も暗号化する動きが進んでいます。

まとめ

このレッスンの要点は、TLS 3 要素 / TLS 1.3 のハンドシェイク / 証明書チェーン の 3 点です。実務でこれらを切り分けて説明できるようになると、設計レビューや障害対応の精度が一段上がります。

理解度チェック

Q. TLS 1.3 のハンドシェイクが TLS 1.2 より速い主要因はどれ？

1. 暗号アルゴリズムが軽量になった
2. ハンドシェイクが 1 RTT に短縮された (再開時は 0 RTT)
3. 証明書サイズが小さくなった
4. サーバー証明書が不要になった

答えを見る

正解は 2。TLS 1.2 は 2 RTT 必要でしたが、TLS 1.3 は鍵交換情報を最初のラウンドで送ることで 1 RTT に短縮。さらにセッション再開時は 0 RTT で即送信できます。

出典 (References)

• IETF RFC 8446 — TLS 1.3
• Mozilla — TLS Configuration Recommendations
• Let's Encrypt — How It Works

最終更新: 2026-05-28

関連レッスン

• HTTP の基本
• HTTP メソッド
• HTTP/2 と HTTP/3 (QUIC)
• REST API の設計原則

よくある質問

Q. GET と POST はどう使い分けますか？

A. 「取得して副作用がない」なら GET、「作成・更新など状態を変える」なら POST が原則です。GET は URL にパラメータが入りキャッシュも効きますが、POST はボディに乗せられ大きなデータも送れます。冪等性も GET は持ち、POST は持たないという違いがあります。

Q. ステータスコードは何を返すべき？

A. 成功は 2xx、リダイレクトは 3xx、クライアントエラーは 4xx、サーバーエラーは 5xx が大原則です。新規作成は 201、認証失敗は 401、権限不足は 403 を返すと REST 慣習に沿った設計になります。200 で全部返すのは避けてください。

Q. REST と GraphQL の違いは？

A. REST はリソース単位のエンドポイント、GraphQL は単一エンドポイントでクエリ言語を使って欲しいデータを指定します。フロントの要件が頻繁に変わるなら GraphQL、シンプルな CRUD なら REST がメンテしやすいことが多いです。

次のレッスン

次は HTTP/2 と HTTP/3 (QUIC) で、暗号化通信 HTTPS と、TLS で鍵を共有する流れを理解します を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

1. HTTPS / TLS の要点を自分の言葉で説明できる
2. このレッスンの最小コード (または操作手順) を見ずに書ける
3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. HTTPS / TLS とは何か、1 文で説明してください。

関連レッスン

• REST API の設計原則
• HTTP メソッド
• HTTP の基本