HTTPS / TLS

HTTPS（HyperText Transfer Protocol Secure）とは、HTTP通信をTLS（Transport Layer Security）プロトコルで暗号化し、安全なWeb通信を実現する仕組みです。Webブラウザとサーバー間の通信を盗聴・改ざん・なりすましから保護し、データの機密性・完全性・真正性を確保します。

TLSはSSL（Secure Sockets Layer）の後継プロトコルであり、最新版のTLS 1.3（RFC 8446、2018年策定）は、ハンドシェイクの高速化と暗号強度の大幅な向上を実現しています。現在では、すべてのWebサイトでHTTPSの使用が事実上の標準となっており、主要ブラウザはHTTPサイトに対して「保護されていない通信」の警告を表示します。

Let's Encryptの登場により、SSL/TLS証明書を無料かつ自動で取得できるようになり、HTTPS化の障壁が劇的に低下しました。Google Chromeの統計によると、Webトラフィックの95%以上がHTTPSで暗号化されています。HTTPSはSEOにも影響し、Googleはランキングシグナルの一つとしてHTTPSを採用しています。

TLSハンドシェイクの仕組み

TLSハンドシェイクは、クライアントとサーバー間で安全な暗号化通信を確立するプロセスです。TLS 1.2では2往復（2-RTT）が必要でしたが、TLS 1.3では1往復（1-RTT）に短縮されました。さらに、以前の接続情報を活用した0-RTT（Zero Round Trip Time）再開も可能です。

• ClientHello：クライアントがサポートする暗号スイート、TLSバージョン、ランダム値を送信
• ServerHello：サーバーが暗号スイートを選択し、証明書と鍵交換パラメータを送信
• 鍵交換：Diffie-Hellman鍵共有（ECDHE）により、セッション鍵を安全に生成
• 暗号化通信開始：共有されたセッション鍵を使用して、以降の通信を暗号化

TLS 1.3の改善点

• ハンドシェイクの高速化：1-RTTハンドシェイクによる接続時間の短縮。0-RTT再開により、再接続時のレイテンシをさらに削減
• 脆弱な暗号スイートの廃止：RC4、DES、3DES、MD5、SHA-1、静的RSA鍵交換、CBCモード暗号など、脆弱な暗号アルゴリズムを完全に排除
• 前方秘匿性（Forward Secrecy）の必須化：ECDHE鍵交換を必須とし、過去の通信が将来の鍵漏洩で復号されることを防止
• 暗号化されたハンドシェイク：ServerHello以降のハンドシェイクメッセージを暗号化し、中間者による通信内容の観察を困難に

証明書の種類

• DV（Domain Validation）証明書：ドメインの所有権のみを検証。Let's Encryptが発行するのはDV証明書。取得が最も簡単で無料〜低コスト
• OV（Organization Validation）証明書：ドメイン所有権に加えて組織の実在性を検証。企業サイトで広く利用される
• EV（Extended Validation）証明書：最も厳格な審査を経て発行。組織の法的存在、物理的所在地、運営実態を詳細に検証。かつてはブラウザのアドレスバーに組織名が緑色で表示されたが、現在は多くのブラウザで表示が簡素化

Let's EncryptとACMEプロトコル

Let's EncryptはISRG（Internet Security Research Group）が運営する無料の認証局で、2015年のサービス開始以来、HTTPSの普及に大きく貢献しています。ACME（Automatic Certificate Management Environment）プロトコル（RFC 8555）を使用して、証明書の発行・更新・失効を完全に自動化しています。CertbotやACME.shなどのクライアントツールで簡単に導入できます。

HSTSとCertificate Transparency

HSTS（HTTP Strict Transport Security）は、ブラウザに対してHTTPSでの接続を強制するセキュリティヘッダーです。Strict-Transport-Securityヘッダーにmax-ageを設定することで、指定期間中はHTTPへのダウングレード攻撃を防止します。preloadオプションにより、ブラウザのプリロードリストに登録することも可能です。

Certificate Transparency（CT）は、認証局が発行したすべての証明書を公開ログに記録する仕組みです。不正に発行された証明書を迅速に検出するために設計されており、Google ChromeはCT対応を証明書の信頼要件としています。

• 01
  TLS 1.3への移行と旧バージョンの無効化：TLS 1.3を優先的に使用し、TLS 1.0およびTLS 1.1は完全に無効化してください。TLS 1.2は当面サポートを維持しつつ、脆弱な暗号スイート（RC4、CBC等）を無効化しましょう。SSL Labs等のツールで定期的にTLS設定を評価してください。
• 02
  HSTSの適切な設定：Strict-Transport-Securityヘッダーを設定し、max-ageを最低1年（31536000秒）以上に設定してください。includeSubDomainsとpreloadオプションの追加を検討し、HSSTプリロードリストへの登録も推奨します。
• 03
  証明書の自動更新と監視：Let's EncryptとACMEクライアント（Certbot等）を使用して証明書の自動更新を設定してください。証明書の有効期限を監視し、更新失敗時にアラートを発行する仕組みを構築しましょう。
• 04
  Certificate Transparencyの活用：Certificate Transparencyログを監視し、自組織のドメインに対して不正な証明書が発行されていないかを定期的に確認してください。CAA（Certificate Authority Authorization）レコードをDNSに設定し、証明書を発行できる認証局を制限しましょう。
• 05
  HTTPからHTTPSへの適切なリダイレクト：すべてのHTTPリクエストを301リダイレクトでHTTPSに転送してください。Mixed Content（HTTPS内でのHTTPリソース読み込み）を排除し、すべてのリソースをHTTPSで配信しましょう。
• 06
  OCSP StaplingとCRL管理：OCSP Staplingを有効にして、証明書の失効状態をサーバーから効率的に提供してください。クライアントがOCSPレスポンダに個別にアクセスする必要がなくなり、プライバシーとパフォーマンスの両方が向上します。