7. セキュリティに関する考慮事項
本書は、TLS および DTLS の実装と展開に関するセキュリティ上の推奨事項の集まり全体を構成しています。追加のセキュリティに関する考慮事項については、以下のセクションで詳しく説明します。
7.1. ホスト名の検証
TLS セキュリティの重要な部分は、クライアントによる証明書検証です。クライアントが証明書の信頼性（証明書が信頼できる認証局によって発行され、有効であること）を確認するだけでは十分ではありません。クライアントは、証明書と提示されたサービス識別子（サーバーのホスト名や IP アドレスなど）の関連性を検証しなければなりません（MUST）。
ホスト名検証に関するガイダンスは [RFC6125] に記載されていますが、検証ルールは特定のアプリケーションプロトコルによって定義されています。実装および展開は、[RFC6125] に従ってホスト名検証に従わなければなりません（MUST）。
7.2. システム時刻
システム時刻が大幅にずれていると、証明書の有効期間チェックが正しく機能しません。そのため、TLS エンドポイントは、そのオペレーティングシステムが信頼できるタイムソース（例：Network Time Protocol [RFC5905]）と同期されていることを確認すべきです（SHOULD）。
7.2.1. シークレットに依存した時間変動
攻撃者は、特定の計算を行うのにかかった時間を測定することで、TLS 実装に関する情報を推測できる可能性があります。詳細については、[RFC7457] のセクション 2.7 を参照してください。
[Boeck2016] による分析は、短い時間差であっても攻撃者が解読に利用できることを示しています。したがって、TLS 実装は、時間変動が可能な限り小さくなるようにする必要があります。特に、[RFC5288] のガイダンスを更新し、レコードが認証に失敗したため（セクション 6.2）、またはパディングチェックに失敗したため（セクション 6.2.1）にエラーが発生した場合、TLS 実装は、アラート生成のタイミングがエラーの原因に依存しないようにしなければなりません（MUST）。アラートが送信されない場合、実装のエンドポイントは、エラーの有無に関わらず、後続の処理にかかる時間を同じにする必要があります。
7.3. 前方秘匿性
前方秘匿性（Forward Secrecy: FS、または Perfect Forward Secrecy: PFS とも呼ばれます）は、攻撃者がサーバーの秘密鍵を入手したとしても、過去の通信内容を復号できないことを保証するセキュリティ特性です。
従来の RSA 鍵交換（静的 RSA）では、サーバーの公開鍵で暗号化されたプリマスターシークレットがネットワーク上を流れます。攻撃者がこの通信を記録し、後でサーバーの秘密鍵を入手すれば、プリマスターシークレットを復号し、続いてセッション鍵を導出して通信内容を解読できます。
一方、Diffie-Hellman (DH) や Elliptic Curve Diffie-Hellman (ECDH) を使用した「一時的（Ephemeral）」な鍵交換では、各セッションごとに新しい一時的な鍵ペアが生成されます。サーバーの長期的な秘密鍵は、一時的な公開鍵への署名に使用されるだけで、暗号化には使用されません。そのため、サーバーの秘密鍵が漏洩しても、過去のセッションの鍵を復元することはできず、通信の機密性が保たれます。
本書では、セクション 4.1 にて、前方秘匿性を提供する暗号スイートの使用を強く推奨しています。
7.4. Diffie-Hellman 指数の再利用
パフォーマンス向上のため、一部のサーバー実装では、一時的な Diffie-Hellman (DH) または Elliptic Curve Diffie-Hellman (ECDH) 鍵ペアを複数のセッションで再利用することがあります。これにより、サーバー側の計算負荷は軽減されますが、前方秘匿性の範囲が狭まります。鍵ペアが再利用されている期間中に攻撃者がその一時的な秘密鍵を入手した場合、その期間内のすべての通信が危険にさらされます。
したがって、サーバーは、可能な限りセッションごとに新しい一時鍵ペアを生成すべきです（SHOULD）。再利用する場合でも、その期間は極めて短く（例：数分または数時間）、かつ再起動時などには必ず新しい鍵ペアを生成するように制限しなければなりません（MUST）。
DH 鍵再利用に関連する攻撃（例：Logjam [Logjam]）のリスクを最小限に抑えるためにも、セクション 4.5 で推奨されているように、十分な長さの鍵と適切なパラメータを使用することが重要です。
7.5. 証明書の失効確認
証明書が誤発行されたり、秘密鍵が侵害されたりした場合、認証局 (CA) はその証明書を失効させます。クライアントは、接続先のサーバーが提示した証明書が失効していないことを確認すべきです（SHOULD）。
証明書の失効確認には、主に Certificate Revocation List (CRL) と Online Certificate Status Protocol (OCSP) [RFC6960] の 2 つの方法があります。
- CRL: 失効した証明書のリストをダウンロードして確認します。リストが大きくなるとダウンロードに時間がかかり、パフォーマンスに影響を与える可能性があります。
- OCSP: 証明書のステータスをリアルタイムで問い合わせます。プライバシーの問題や、OCSP レスポンダーへの依存性があります。
OCSP ステープリング（TLS Certificate Status Request 拡張 [RFC6066]）は、サーバーが自分の証明書の OCSP レスポンスを取得し、ハンドシェイク時にクライアントに提供するメカニズムです。これにより、クライアントが直接 OCSP レスポンダーに問い合わせる必要がなくなり、パフォーマンスとプライバシーが向上します。
サーバーは OCSP ステープリングをサポートし、可能な場合は有効な OCSP レスポンスを含めるべきです（SHOULD）。クライアントは、可能であれば OCSP ステープリングを利用すべきです（SHOULD）。また、クライアントは、OCSP レスポンスが欠落している場合やエラーが発生した場合のポリシー（ソフトフェイルまたはハードフェイル）を適切に設定する必要があります。多くのブラウザは、ユーザビリティを考慮してソフトフェイル（検証不可でも接続を許可）を採用していますが、セキュリティ重視のアプリケーションではハードフェイル（接続を拒否）が適切な場合もあります。
OCSP Must-Staple 拡張 [RFC7633] を使用すると、証明書に OCSP ステープリングが必須であることを示すことができます。これにより、攻撃者が OCSP レスポンスを隠蔽して失効確認を回避することを防げます。