OCSP、mTLSなど、TLS関連をざっくり整理してみた
はじめに
TLS（Transport Layer Security）は、インターネット上でのセキュアな通信を可能にするプロトコルです（インターネットでウェブサイトにアクセスする際にhttps://～から始まるURLなど）。
また、似たようなワードとしてSSLというものがありますが、SSLは（Secure Socket Layer）の略で、ざっくりいうとTLSの前に使われていた技術です。今も通称としてSSLという呼称が残っていて、SSL/TLSと併記されたりSSLと呼ばれることもあります。
SSLはSSL3.0までリリースされていましたが、セキュリティ上の問題で廃止されています。
TLSの現時点の最新バージョンはTLS1.3で、TLS1.0、TLS1.1についてはセキュリティ上の問題で今は廃止されています。
本記事では、TLSの概要を簡単にまとめてみます。
1. TLSの目的
TLSの主な目的は以下の通りです：
- 認証: サーバーやクライアントの身元を確認し、中間者攻撃を防ぐ
- 暗号化: データの機密性を保護する
- 完全性: データが改ざんされていないことを保証する
これらを実現するためにデジタル証明書（TLS証明書）が使われます。
2. サーバー認証と相互認証
簡単に言うと、サーバー認証は接続先のサーバーの身元のみを証明することで、一般的なウェブサイトではサーバー認証が使われています。
サーバー認証ではサーバーに配置されたサーバー証明書を検証することで接続先のサーバーの身元を確認して、問題ないと判断された場合にTLSを確立します。
相互認証（mutual-TLS/mTLSと言われたりもします）の場合は、サーバーだけではなくて、クライアント側もクライアント証明書を使って身元の検証がされます。サーバー/クライアントの双方向・相互で認証するので相互認証と言われます。
3. TLSハンドシェイクのシーケンス
TLSレイヤで接続を確立するためのシーケンスを書いてみます。
TLS 1.3ではハンドシェイクプロセスが大幅に簡素化され、1-RTT（Round Trip Time）で完了することができるようになりました。
最初のClientHelloとServerHelloで暗号化方式（暗号スイート）の合意がされたあとのハンドシェイクプロセスは暗号化されています。
以下では、TLS1.3におけるサーバー認証のみのパターンと相互認証のパターンを示します。
サーバー認証シーケンス
相互認証シーケンス
4. サーバー証明書/中間証明書/ルート証明書
証明書は、ルート証明書を最上位として、次の下位の証明書に署名し、次の証明書がさらにその次の証明書に署名するというチェーン構造（トラストチェーン）になっています。
ルート証明書は中間証明書を署名（正当性を証明）し、中間証明書はサーバー/クライアント証明書を署名します。
ルート証明書は、信頼の起点になっている証明書で信頼されるパブリック認証局（CA/Certificate Authoroties）の自己署名された証明書です。
パブリックな認証局はDigiCertなど数社しかありません。
自社内など、限定された範囲内で使用する場合はプライベート認証局の自己署名されたルート証明書を使うこともあります（いわゆるオレオレ証明書）。
証明書チェーンのざっくりイメージを書くと下記のようになります。
ちなみに中間証明書は無くてもいいです（逆に複数設定することも可能）。
なぜ中間証明書があるのかというと、一般にパブリックな認証局のルート証明書はパソコンやブラウザに組み込まれており、容易に入れ替えたりすることができず、有効期間も長めに設定されています。そのため、秘密鍵漏洩などのインシデントが起きた際の影響が大きくなります。そのため、中間証明書を間に挟んで、有効期間を比較的短くすることで何かあった際の影響範囲を小さくすることが可能です。
この階層構造により、証明書の信頼性を効率的に検証できるようになっています
5. 証明書の失効管理（CRLとOCSP）
証明書には有効期限が設定されており、期限が切れた証明書は使用することができません。
また、期限内でも秘密鍵が流出したり、なんらか違反があって失効になる場合がありますが、期限内でも失効になった証明書を管理する仕組みがCRLとOCSPです。
CRL (Certificate Revocation List)
- 失効した証明書のリスト
- 定期的に更新され、クライアントがダウンロード
OCSP (Online Certificate Status Protocol)
- OCSPレスポンダにリアルタイムで問い合わせて証明書の状態を確認
※ちなみに先日無料の証明書を提供しているLet's EncryptがOCSPサポートを停止すると発表していましたね...。
CRLシーケンス
OCSPシーケンス
CRLとOCSPの比較
CRLとOCSPはそれぞれ異なる特性を持っており、用途や環境に応じて適切な方式を選択することが重要です。
| 特性 | CRL（Certificate Revocation List） | OCSP（Online Certificate Status Protocol） |
|---|---|---|
| 概要 | 失効した証明書のリストを定期的に発行 | リアルタイムで証明書の状態を問い合わせ |
| 更新頻度 | 定期的（例：日次、週次） | リアルタイム |
| データサイズ | 大きい（すべての失効証明書を含む） | 小さい（1つの証明書の状態のみ） |
| ネットワーク負荷 | 定期的に大きなダウンロード | 頻繁な小さなクエリ |
| レイテンシ | 低（ローカルで検証） | 中〜高（オンライン問い合わせ） |
| 鮮度 | 更新頻度に依存 | 常に最新 |
| オフライン使用 | 可能（最後にダウンロードしたリストを使用） | 不可能 |
| サーバー負荷 | 低（定期的な配布のみ） | 高（リアルタイムの問い合わせに応答） |
| プライバシー | 高（CAは個別の検証を追跡できない） | 低（CAが証明書の使用を追跡可能） |
| 実装の複雑さ | 比較的簡単 | やや複雑 |
| スケーラビリティ | 失効証明書が多い場合に課題あり | 問い合わせ数が多い場合に課題あり |
| 適した用途 | ・大規模なシステム ・帯域幅が制限された環境 ・オフライン検証が必要な場合 |
・即時の失効確認が重要な場合 ・頻繁に更新が必要な環境 ・個別の証明書検証が重要な場合 |
OCSP Stapling
OCSPには、OCSP StaplingというTLSハンドシェイク中にサーバーがOCSPレスポンスをキャッシュする機能があります。
OCSP Staplingの利点として下記があげられます。
- クライアントがCAに直接問い合わせる必要がないため、接続が高速化されます
- CAがクライアントの接続を追跡できません
- サーバー側でOCSP応答をキャッシュするため、CAの負荷が軽減されます
ただ、キャッシュ更新タイミングによっては古いOCSP応答を返してしまう可能性があります。
まとめ
TLSに関連する仕組みを整理してみました。
次回はOpenSSL使って証明書やOCSPレスポンダを作って実際の動きを検証したいと思っています。
Discussion