HTTPSとSSL/TLSの仕組みを理解する

前回の記事では、HTTPリクエストとレスポンスの基本構造について解説しました。今回は、HTTPをセキュアにするHTTPSと、その基盤となるSSL/TLS暗号化の仕組みについて詳しく解説します。

現代のWeb開発において、HTTPS対応は必須です。HTTPSを理解することで、なぜセキュアな通信が必要なのか、SSL/TLS証明書がどのような役割を果たしているのかを把握できます。

HTTPとHTTPSの違い

HTTPとHTTPSの最も大きな違いは、通信が暗号化されているかどうかです。この違いがWebセキュリティにおいて非常に重要な意味を持ちます。

HTTPの問題点

HTTP（HyperText Transfer Protocol）は、データを平文（暗号化されていない状態）で送受信します。これにより、以下のセキュリティリスクが発生します。

sequenceDiagram
    participant Client as クライアント
    participant Attacker as 攻撃者
    participant Server as サーバー
    Client->>Server: 平文のHTTPリクエスト
    Note over Attacker: 攻撃者が傍受可能

HTTPSによる解決

HTTPS（HTTP Secure）は、HTTP通信をSSL/TLSプロトコルで暗号化したものです。HTTPSでは以下の3つの保護が提供されます。

sequenceDiagram
    participant Client as クライアント
    participant Attacker as 攻撃者
    participant Server as サーバー
    Client->>Server: 暗号化されたHTTPSリクエスト
    Note over Attacker: 攻撃者は解読不可

HTTPとHTTPSの技術的な違い

HTTPとHTTPSには、以下の技術的な違いがあります。

SSL/TLS暗号化の仕組み

SSL/TLSは、インターネット上で安全な通信を実現するための暗号化プロトコルです。HTTPS通信の基盤となる技術です。

SSLとTLSの歴史

SSL（Secure Sockets Layer）は、Netscape社が1990年代に開発した暗号化プロトコルです。その後、IETF（Internet Engineering Task Force）によって標準化され、TLS（Transport Layer Security）として発展しました。

現在、「SSL」という用語は慣習的に使われていますが、実際にはTLS 1.2またはTLS 1.3が使用されています。

暗号化の種類

SSL/TLSでは、2種類の暗号化方式を組み合わせて使用します。

共通鍵暗号方式（対称鍵暗号）

送信者と受信者が同じ鍵を使用してデータを暗号化・復号する方式です。

flowchart LR
    subgraph 共通鍵暗号方式
        A["平文"] -->|共通鍵で暗号化| B["暗号文"]
        B -->|共通鍵で復号| C["平文"]
    end
    Note1["メリット: 処理が高速"]
    Note2["デメリット: 鍵の共有方法が課題"]

代表的なアルゴリズム: AES（Advanced Encryption Standard）

公開鍵暗号方式（非対称鍵暗号）

公開鍵と秘密鍵のペアを使用する方式です。公開鍵で暗号化したデータは、対応する秘密鍵でのみ復号できます。

sequenceDiagram
    participant Sender as 送信者
    participant Receiver as 受信者
    Note over Sender,Receiver: 公開鍵暗号方式
    Receiver->>Sender: 公開鍵を送付
    Note over Sender: 平文を公開鍵で暗号化
    Sender->>Receiver: 暗号文を送信
    Note over Receiver: 秘密鍵で復号 → 平文
    Note over Sender,Receiver: メリット: 鍵の共有が安全
    Note over Sender,Receiver: デメリット: 処理が遅い

代表的なアルゴリズム: RSA、ECDSA（楕円曲線DSA）

ハイブリッド暗号方式

SSL/TLSでは、両方の暗号化方式の長所を活かすハイブリッド暗号方式を採用しています。

sequenceDiagram
    participant Client as クライアント
    participant Server as サーバー
    Note over Client,Server: ハイブリッド暗号方式
    Note over Client,Server: 1. 公開鍵暗号で「共通鍵」を安全に交換
    Client->>Server: 公開鍵暗号で共通鍵を交換
    Note over Client,Server: 2. 交換した共通鍵で実際のデータを高速に暗号化
    Client->>Server: 共通鍵暗号で高速なデータ通信

証明書の役割

SSL/TLS証明書は、Webサイトの身元を証明し、暗号化通信を実現するために必要なデジタル証明書です。

証明書に含まれる情報

SSL/TLS証明書には以下の情報が含まれています。

認証局（CA）の役割

認証局（Certificate Authority: CA）は、SSL/TLS証明書を発行する信頼された第三者機関です。

flowchart LR
    subgraph CA["認証局（CA）の役割"]
        A["サイト運営者"] -->|1. 申請| B["CA"]
        B -->|2. ドメイン所有権を検証| B
        B -->|3. 証明書を発行（署名付き）| C["証明書"]
    end

代表的な認証局として、以下があります。

• Let’s Encrypt（無料の認証局）
• DigiCert
• GlobalSign
• Sectigo（旧Comodo）

証明書の種類

SSL/TLS証明書には、検証レベルによって3つの種類があります。

証明書チェーン

ブラウザは「ルート証明書」を信頼の起点として、証明書チェーン（信頼の連鎖）を検証します。

flowchart TB
    subgraph chain["証明書チェーン"]
        Root["ルート証明書<br>(Root CA)"]
        Intermediate["中間証明書<br>(Intermediate)"]
        Server["サーバー証明書<br>(End-entity)"]
        Root -->|署名| Intermediate
        Intermediate -->|署名| Server
    end
    Note1["ブラウザに事前インストール済み<br>自己署名で信頼の起点"] -.- Root
    Note2["ルートCAから署名を受けた証明書"] -.- Intermediate
    Note3["中間CAから署名を受けた証明書<br>Webサイトに設定"] -.- Server

HTTPS通信の流れ

HTTPS通信は、TLSハンドシェイクと呼ばれる手順で暗号化通信を確立します。ここでは、TLS 1.2とTLS 1.3のハンドシェイクの流れを解説します。

TLS 1.2のハンドシェイク

TLS 1.2では、暗号化通信を確立するために2往復（2-RTT）の通信が必要です。

sequenceDiagram
    participant Client as クライアント
    participant Server as サーバー
    Client->>Server: 1. ClientHello（対応する暗号スイート一覧）
    Server->>Client: 2. ServerHello（選択した暗号スイート）
    Server->>Client: 3. Certificate（サーバー証明書）
    Server->>Client: 4. ServerKeyExchange（鍵交換に必要な情報）
    Server->>Client: 5. ServerHelloDone
    Note over Client: 証明書の検証
    Client->>Server: 6. ClientKeyExchange（プリマスターシークレット）
    Client->>Server: 7. ChangeCipherSpec（暗号化通信への切り替え通知）
    Client->>Server: 8. Finished（ハンドシェイク完了通知）
    Server->>Client: 9. ChangeCipherSpec
    Server->>Client: 10. Finished
    Note over Client,Server: 暗号化通信開始

TLS 1.3のハンドシェイク

TLS 1.3では、ハンドシェイクが1往復（1-RTT）に短縮され、パフォーマンスが向上しています。

sequenceDiagram
    participant Client as クライアント
    participant Server as サーバー
    Client->>Server: 1. ClientHello + 鍵共有パラメータ
    Server->>Client: 2. ServerHello + 鍵共有パラメータ<br>+ EncryptedExtensions<br>+ Certificate<br>+ CertificateVerify<br>+ Finished
    Note over Client: 証明書の検証
    Client->>Server: 3. Finished
    Note over Client,Server: 暗号化通信開始

TLS 1.3の主な改善点

TLS 1.3は、TLS 1.2から以下の点が改善されています。

開発者ツールでHTTPS通信を確認する方法

Chrome DevToolsを使用して、Webサイトのセキュリティ状態やHTTPS通信の詳細を確認できます。

前提条件

プライバシーとセキュリティパネルの使用

Chrome DevToolsのプライバシーとセキュリティパネルで、HTTPS通信の状態を確認できます。

パネルを開く手順

1. 確認したいWebサイトを開く
2. F12 キーまたは Ctrl+Shift+I（macOSは Cmd+Option+I）でDevToolsを開く
3. Ctrl+Shift+P（macOSは Cmd+Shift+P）でコマンドメニューを開く
4. 「privacy」と入力し、「プライバシーとセキュリティを表示」を選択

確認できる情報

セキュリティパネルでは以下の情報を確認できます。

Networkパネルでの確認

Networkパネルでは、各リクエストの詳細なセキュリティ情報を確認できます。

確認手順

1. DevToolsのNetworkタブを開く
2. ページを再読み込み（F5またはCtrl+R）
3. 任意のリクエストをクリック
4. 「Security」タブを選択

期待される結果

正常なHTTPS接続の場合、以下の情報が表示されます。

Connection - secure (TLS 1.3)
Certificate - valid and trusted

curlコマンドでの確認

ターミナルからcurlコマンドを使用して、SSL/TLS証明書の情報を確認することもできます。

1
2
3
4
5

# 証明書情報の表示
curl -vI https://example.com 2>&1 | grep -E "SSL|TLS|subject|issuer|expire"

# 詳細なSSL/TLS情報の表示
curl -v https://example.com 2>&1 | grep -E "SSL connection|TLSv"

期待される出力例:

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=example.com
*  issuer: C=US; O=Let's Encrypt; CN=R11
*  expire date: Mar 31 00:00:00 2026 GMT

opensslコマンドでの確認

より詳細な証明書情報を確認する場合は、opensslコマンドを使用します。

1
2
3
4
5

# サーバー証明書の取得と表示
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -text -noout

# 証明書チェーンの確認
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

まとめ

この記事では、HTTPSとSSL/TLSの仕組みについて解説しました。重要なポイントを振り返ります。

• HTTPは平文通信であり、盗聴・改ざん・なりすましのリスクがある
• HTTPSはSSL/TLSによる暗号化で、機密性・完全性・認証を提供する
• SSL/TLSは公開鍵暗号と共通鍵暗号を組み合わせたハイブリッド方式を採用
• 証明書は認証局（CA）が発行し、サーバーの身元を証明する
• TLS 1.3は1-RTTでハンドシェイクが完了し、セキュリティとパフォーマンスが向上
• Chrome DevToolsでHTTPS通信の状態を確認できる

現代のWeb開発では、HTTPS対応は必須です。次回は、CookieとSessionの仕組みについて解説し、HTTPのステートレス性をどのように補うかを学びます。

参考リンク

• MDN Web Docs - Transport Layer Security
• Let’s Encrypt - How It Works
• Chrome DevTools - プライバシーとセキュリティパネル
• RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
• Mozilla SSL Configuration Generator
• SSL Labs - SSL Server Test