HTTPS - 暗号化全般

HTTPSとは

HTTPS（HTTP Secure / HTTP over TLS）は、HTTPプロトコルをTLS（Transport Layer Security）で暗号化したセキュアな通信プロトコルです。ポート443を使用し、クライアント（ブラウザ）とサーバー間のすべての通信を暗号化します。HTTPSという名称自体は特定の1本のRFCで定義されているわけではなく、HTTPのセマンティクス（RFC 9110）とバージョンごとの通信方式（HTTP/1.1はRFC 9112、HTTP/2はRFC 9113、HTTP/3はRFC 9114）を、TLSのレコード層の上に載せて運用する構成全体を指す呼称です。アプリケーション層のHTTPと、トランスポート層（TCP、またはHTTP/3の場合はQUIC/UDP）の間にTLSという暗号化レイヤーを挟み込むイメージを持つと理解しやすくなります。

2014年のHTTPS Everywhere運動以降、GoogleはHTTPSをSEOランキング要因に追加し、現在ではほぼすべてのWebサイトがHTTPSを使用しています。Let's Encryptの登場により、無料でTLS証明書を取得できるようになったことも普及を後押ししました。ブラウザ側の統計でも、読み込まれるページの大半がHTTPS経由であるとされ、HTTPのみのサイトはChromeやFirefoxで「保護されていない通信」という警告表示の対象になります。

仕組み・詳細解説

HTTPSの安全性は、大きく分けて「①最初に安全な鍵を共有する（ハンドシェイク）」「②共有した鍵で実際のデータを暗号化する」「③相手が本物のサーバーであることを検証する」という3つの仕組みの組み合わせで成り立っています。それぞれを分解して見ていきます。

TLSハンドシェイクの流れ

現在主流のTLS 1.3（RFC 8446で規定）では、以下のような1往復（1-RTT）でハンドシェイクが完了します。TLS 1.2までは2往復（2-RTT）を要していたため、TLS 1.3への移行は接続確立の遅延短縮にも直結します。

1. ClientHello：クライアントが対応可能な暗号スイート、TLSバージョン、鍵共有用の公開値（key_share）を提示
2. ServerHello：サーバーが暗号スイートを選択し、自身の鍵共有値、サーバー証明書、署名を返送
3. 鍵導出：双方がECDHE（後述）で得た共有シークレットから、HKDFというアルゴリズムでセッション鍵を導出
4. Finished：双方がハンドシェイク内容が改ざんされていないことを確認するメッセージを交換し、以降のHTTPデータ本体はこのセッション鍵で暗号化される

さらにTLS 1.3では、以前に接続したサーバーとの再接続時にPSK（Pre-Shared Key）を使った0-RTT（往復なしでの初回データ送信）にも対応していますが、リプレイ攻撃のリスクがあるため冪等なリクエストに限定するなどの注意が実装上必要です。

鍵交換とPerfect Forward Secrecy

鍵交換には主にECDHE（Elliptic Curve Diffie-Hellman Ephemeral）が使われます。ECDHEは通信のたびに一時的な鍵ペアを生成するため、仮に後日サーバーの長期秘密鍵（証明書の秘密鍵）が漏洩したとしても、過去に記録・傍受された通信を復号することはできません。この性質をPerfect Forward Secrecy（PFS、完全前方秘匿性）と呼びます。TLS 1.3では鍵交換方式がECDHE（および実験的なPQC併用方式）に一本化され、PFSを持たない静的RSA鍵交換は廃止されました。詳細はPerfect Forward Secrecyの項目も参照してください。

対称鍵暗号によるデータ転送

ハンドシェイクが完了すると、実際のHTTPリクエスト・レスポンスはAEAD（Authenticated Encryption with Associated Data）と呼ばれる方式の対称鍵暗号でやり取りされます。代表的な暗号はAES-128-GCM、AES-256-GCM、ChaCha20-Poly1305です。AEADは暗号化と改ざん検知（認証）を1つの演算でまとめて行うため、以前のCBCモード＋別立てMAC（Encrypt-then-MACやMAC-then-Encrypt）の組み合わせで問題になっていたパディングオラクル攻撃（POODLE、Lucky13など）の心配がありません。ChaCha20-Poly1305はAES-NIのようなハードウェアアクセラレーションを持たないモバイル端末やIoT機器でも高速に動作するよう設計されており、Google製品を中心に採用が進みました。

証明書検証とトラストチェーン

ブラウザは受け取ったサーバー証明書（リーフ証明書）から、中間認証局（Intermediate CA）証明書、ルート認証局（Root CA）証明書へとたどる「トラストチェーン」を検証します。あわせて、有効期限、SAN（Subject Alternative Name）とアクセス先ホスト名の一致、失効情報（OCSPステープリング等）、Certificate Transparencyログへの記載有無がチェックされます。中間証明書の配布漏れはクライアントによって挙動が割れる典型的な設定ミスであり、後述のトラブル事例でも扱います。証明書の構造そのものについてはX.509、検証の連鎖については証明書チェーン、認証局の仕組みは認証局（CA）の項目で詳しく解説しています。

HTTPSのメリットとデメリット

メリット

• 通信の暗号化：盗聴からデータを保護
• データ完全性：改ざんを検知
• 認証：正しいサーバーと通信していることを保証
• SEO向上：GoogleがHTTPSを優遇
• 信頼性：ブラウザの「鍵」アイコンでユーザーに安心感

デメリット・注意点

• 処理オーバーヘッド：TLSハンドシェイクやAEAD暗号化にはCPUコストが発生します。ただしTLS 1.3のセッション再開機能や、現代CPUのAES-NIハードウェアアクセラレーションにより、実務上はほぼ無視できる水準まで軽減されています
• 証明書のライフサイクル管理コスト：有効期限の監視と自動更新の仕組みが必須です。更新失敗はそのままサービス停止につながるため、監視体制が重要になります
• SNIによる接続先情報の露出：ハンドシェイク中のSNI（Server Name Indication）で接続先ホスト名が平文で送られる場合があり、通信経路上の観測者にアクセス先が分かってしまう可能性があります。これを暗号化するEncrypted Client Hello（ECH）は一部のブラウザ・CDNで試験導入が進んでいる段階です
• 企業ネットワークでの通信検査の複雑化：プロキシによるTLSインスペクションを行う環境では、証明書の再署名やピン留め（証明書ピンニング）との相性を事前に検討する必要があります

実装例：Nginxを用いたHTTPS設定

APIサーバーやWebアプリケーションを公開する際、HTTPSの設定は避けて通れません。以下はNginxでのHTTPS設定例です。

server {
    listen 80;
    server_name api.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;
    
    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
    
    # セキュリティヘッダー
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    
    location / {
        proxy_pass http://localhost:8000;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

混同されやすい用語・類似技術との違い

HTTPSは周辺技術と名称が似ているため混同されがちです。実務でよく質問される違いを整理します。

Let's Encryptによる無料証明書

Let's Encryptは、ACME（Automatic Certificate Management Environment、RFC 8555）というプロトコルを使って証明書の発行・更新を自動化する無料の認証局です。ドメイン所有権の確認方式には、Webサーバー上に検証用ファイルを設置するHTTP-01チャレンジと、DNSにTXTレコードを追加するDNS-01チャレンジがあり、ワイルドカード証明書（*.example.comのような形式）を取得する場合はDNS-01が必須になります。

# certbotのインストール（Ubuntu）
sudo apt install certbot python3-certbot-nginx

# 証明書の取得と自動設定
sudo certbot --nginx -d api.example.com

# 自動更新の確認
sudo certbot renew --dry-run

有効期間は90日と短く設計されており、これは万一秘密鍵が漏洩した場合の被害期間を短く抑える設計思想に基づいています。運用上はcertbotのタイマー（systemdタイマーやcron）による自動更新を前提とし、更新失敗を検知するアラートを別途仕込んでおくのが定石です。

HSTS（HTTP Strict Transport Security）

HSTSは、ブラウザに対してHTTPSのみを使用するよう強制するセキュリティ機構で、RFC 6797で規定されています。HTTPでの初回アクセス自体を悪用する中間者攻撃（SSL Stripping）を防ぐことが主目的です。

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

各ディレクティブの意味は次の通りです。max-ageはこの指示をブラウザが記憶する秒数（上記例は1年）、includeSubDomainsはサブドメインにも同じポリシーを適用すること、preloadはブラウザベンダーが管理するHSTSプリロードリスト（hstspreload.org）への登録を希望する意思表示です。プリロードリストに登録されると、そのドメインへの初回アクセスからHTTPでの通信自体が発生しなくなりますが、登録には全サブドメインでのHTTPS配信が前提条件となるため、登録前に社内外すべてのサブドメインの対応状況を確認しておく必要があります。

鍵長・アルゴリズムの推奨基準（2026年時点）

暗号アルゴリズムや鍵長の「安全な水準」は年々見直されています。NIST（米国国立標準技術研究所）はSP 800-57 Part 1やSP 800-131Aで、アルゴリズムごとの推奨強度と非推奨化のスケジュールを示しており、HTTPSサーバーの設定でもこれらの基準を参考にするのが実務上の定石です。

NISTの基準では、RSA-2048やECC P-256相当の「112ビット安全性」は2030年前後を境に非推奨方向に見直される見込みとされ、長期的にはRSA-3072やECC P-384相当の「128ビット安全性」への移行が推奨される流れにあります。新規に証明書やシステムを設計する際は、この移行スケジュールを見越して鍵長を選定しておくと、将来の再発行コストを抑えられます。あわせて、量子コンピュータによる将来的な脅威に備えた耐量子暗号（PQC）との併用（ハイブリッド鍵交換）も、CloudflareやGoogleのブラウザ実装で試験的に導入が進んでいます。TLS関連の推奨設定はRFC 9325（BCP 195、旧RFC 7525を置き換え）にもまとまっており、サーバー設定の見直し時に参照する価値があります。

トラブル事例と対策

2025〜2026年の最新動向

• HTTP/3（QUIC）の普及：Chrome、Firefox、SafariすべてがHTTP/3対応。主要サービスの多くがHTTP/3を有効化
• TLS 1.3の完全移行：TLS 1.0/1.1は主要ブラウザで無効化済み。TLS 1.2→1.3への移行が加速
• 証明書の短期化：Apple等がSSL証明書の有効期間を47日に短縮する方針を提案（2026年〜）
• 耐量子TLS：Cloudflare・Google等が量子コンピュータ対応のPQC鍵交換の試験を実施
• Encrypted Client Hello（ECH）：SNIによる接続先ホスト名の露出を防ぐ仕組みが一部ブラウザ・CDNで試験導入段階にある
• Certificate Transparencyの強化：主要ブラウザがCT証跡のないTLS証明書を信頼しない運用の厳格化を継続

よくある質問（FAQ）

関連用語

• TLS - HTTPSが使う暗号化プロトコル
• TLS証明書 - HTTPSに必要なデジタル証明書
• Let's Encrypt - 無料TLS証明書プロバイダー
• 非対称暗号 - HTTPSの基盤技術
• SSL - TLSの前身プロトコル
• Perfect Forward Secrecy - ECDHE鍵交換がもたらす前方秘匿性
• 証明書チェーン - トラストチェーンの検証構造
• 認証局（CA） - 証明書の発行元となる第三者機関
• Certificate Transparency - 不正証明書の発行を検出する公開ログ
• 耐量子暗号（PQC） - 量子コンピュータ時代を見据えた次世代の鍵交換・署名方式
• デジタル署名 - 証明書の真正性を保証する仕組み
• 鍵長 - 暗号アルゴリズムの安全性を左右するパラメータ

外部リンク・参考資料

• Let's Encrypt 公式サイト - 無料SSL/TLS証明書の発行元
• HSTS Preload List - Chrome等が管理するHSTSプリロード登録サイト
• Qualys SSL Labs Server Test - 無料のHTTPS/TLS設定品質診断ツール
• RFC 9110 - HTTP Semantics - IETFによるHTTPの意味論の標準規格
• RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3 - TLS 1.3の正式仕様
• NIST SP 800-57 Part 1 Rev.5 - 鍵管理と推奨鍵長に関するNISTのガイドライン

📝 関連ブログ記事

【2026年最新】OpenSSLの深刻な問題とは？

HTTPS導入のご相談