11. セキュリティに関する考慮事項

TLS 拡張の一般的なセキュリティに関する考慮事項は [RFC5246] で扱われています。このドキュメントで定義された拡張に特有のセキュリティに関する考慮事項を以下に説明します。

11.1. server_name のセキュリティに関する考慮事項

単一のサーバーが複数のドメインをホストする場合、各ドメインの所有者がこれが自分たちのセキュリティニーズを満たすことを確認する必要があることは明らかです。これ以外に、server_name は重大なセキュリティ問題を導入しないように見えます。

実装は、server_name の長さフィールドの値が何であれ、バッファオーバーフローが発生しないことを保証する必要があります (MUST)。

server_name 拡張はアプリケーションにとってほぼ透過的であることを意図していますが、単一の基盤となるネットワークアドレスで複数のサーバーがホストされている場合、一部の構成では、アプリケーションがその ID の追加証拠を提供する必要がある場合があります。場合によっては、アプリケーションプロトコルがこれを実現する方法を提供することがあります。たとえば、HTTP の場合、クライアントは HTTP Request-URI にドメイン名を含めることができます（[RFC2616] のセクション 5.1.2 を参照）。他の場合には、何らかの帯域外メカニズムが必要になる場合があります。

server_name の 1 つの欠点は、機密性を提供しないことです。クライアントが server_name 拡張を含む ClientHello メッセージを送信できた場合でも、一部のアプリケーション層プロトコルでは、あまり大きな問題にはならないはずです。ただし、攻撃者が server_name 拡張を含む ClientHello メッセージを傍受した場合、攻撃者はクライアントが接続しようとしているサーバーの名前を知ることになり、一部の環境では機密情報と見なされる可能性があります。

11.2. max_fragment_length のセキュリティに関する考慮事項

最大フラグメント長はハンドシェイクメッセージを含めてすぐに有効になります。ただし、これは TLS にすでに存在しないセキュリティの複雑さを導入するものではありません。TLS は実装がフラグメント化されたハンドシェイクメッセージを処理できることを要求しているためです。

セクション 4 で説明されているように、非ヌル暗号スイートがアクティブになると、有効な最大フラグメント長は暗号スイートと圧縮方法、およびネゴシエートされた max_fragment_length に依存します。バッファのサイズ設定とバッファオーバーフローのチェックを行う際には、これを考慮に入れる必要があります。

11.3. client_certificate_url のセキュリティに関する考慮事項

client_certificate_url の使用で考慮すべき主要な問題が 2 つあります：

1. URL を制御するエンティティの ID と、その URL で証明書が取得されたときに ID が主張されるエンティティとの関係。通常の場合、証明書は HTTP または HTTPS を使用して取得されるため、URL はホストを識別します。そのホストがクライアントでない場合、クライアントが URL と証明書の間の対応を維持するためにホストをどの程度信頼するかという問題が生じます。たとえば、クライアントが URL http://www.example.com/cert.crt を使用して証明書を識別する場合、example.com を制御する人は誰でも、クライアントとして認証するために使用するために自分の証明書を置き換える可能性があります。

2. TLS サーバーの URL へのアクセスには、サーバーが通常アクセスできないホストにアクセスする必要がある場合があります。たとえば、URL はファイアウォールの背後にあるホストを識別する可能性があります。これにより、攻撃者が TLS サーバーに任意の URL への接続を引き起こす可能性があるため、ファイアウォールを貫通する手段を提供する可能性があります。その結果、セキュリティ脆弱性が発生する可能性があります。関連する問題は、サーバーがサポートする URI スキームに依存します。HTTP の場合、懸念事項は、公開アクセス可能な HTTP プロキシサーバーに適用されるものと類似しています。HTTPS の場合、ループとデッドロックが作成される可能性があり、これに対処する必要があります。FTP の場合、FTP バウンス攻撃に類似した攻撃が発生します。

この問題の結果として、client_certificate_url 拡張はデフォルトで有効にするのではなく、サーバー管理者によって具体的に有効にする必要があることが推奨されます (RECOMMENDED)。また、URI スキームを管理者が個別に有効にし、最小限のスキームセットのみを有効にすることが推奨されます (RECOMMENDED)。限定されたセキュリティを提供するか、セキュリティが十分に理解されていない異常なプロトコルは避けるべきです (SHOULD)。

[RFC3986] で説明されているように、デフォルト以外のポートを指定する URL は問題を引き起こす可能性があり、非常に長い URL も問題を引き起こす可能性があります（バッファオーバーフローバグの悪用に役立つ可能性が高いため）。

この拡張は（RFC 4366 のように）SHA-1 を引き続き使用し、アルゴリズムの敏捷性を提供しません。この場合、SHA-1 に必要なプロパティは、衝突耐性ではなく、第 2 原像耐性です。さらに、将来 SHA-1 に対する第 2 原像攻撃が発見されたとしても、client_certificate_url に対する攻撃には、サーバーによって有効な証明書として受け入れられ、同じ公開鍵を含む第 2 原像が必要になります。

また、HTTP キャッシングプロキシはインターネット上で一般的であり、一部のプロキシはオブジェクトの最新バージョンを正しくチェックしないことに注意してください。HTTP（または別のキャッシングプロトコル）を使用する要求が誤って構成されているか、その他の方法で壊れたプロキシを経由する場合、プロキシは古い応答を返す可能性があります。

11.4. trusted_ca_keys のセキュリティに関する考慮事項

クライアントが所有する CA ルート鍵は、機密情報と見なされる可能性があります。その結果、CA ルート鍵表示拡張は注意して使用する必要があります。

SHA-1 証明書ハッシュの代替使用により、各証明書が明確に指定されることが保証されます。このコンテキストは暗号ハッシュ関数を必要としないため、SHA-1 の使用は許容できると見なされ、アルゴリズムの敏捷性は提供されません。

11.5. truncated_hmac のセキュリティに関する考慮事項

切り詰められた MAC は「切り詰められていない」MAC よりも弱い可能性があります。ただし、MD5 または SHA-1 を使用し 80 ビットに切り詰められた HMAC については、現在、重大な弱点は知られておらず、存在することも予想されていません。

MAC の出力長は、対称暗号鍵の長さと同じである必要はありません。MAC 値の偽造はオフラインで実行できないためです：TLS では、単一の失敗した MAC 推測により、TLS セッションが直ちに終了します。

MAC アルゴリズムは、拡張パラメータに影響を与えるすべてのハンドシェイクメッセージが Finished メッセージのハッシュによって認証された後にのみ有効になるため、アクティブな攻撃者が切り詰められた HMAC 拡張の使用を強制的にネゴシエートすることは不可能です（ハンドシェイク認証が安全である限り）。したがって、将来切り詰められた HMAC にセキュリティ上の問題が見つかった場合でも、特定のセッションのクライアントまたはサーバーのいずれかが問題を考慮するように更新された場合、この拡張の使用を拒否できるようになります。

11.6. status_request のセキュリティに関する考慮事項

クライアントが OCSP 応答を要求する場合、侵害された鍵を使用する攻撃者のサーバーが拡張をサポートしていないふりをする可能性がある（そしておそらくそうするだろう）ことを考慮に入れる必要があります。この場合、証明書の OCSP 検証を必要とするクライアントは、OCSP サーバーに直接連絡するか、ハンドシェイクを中止すべきです (SHOULD)。

OCSP nonce リクエスト拡張 (id-pkix-ocsp-nonce) を使用すると、OCSP 応答を再生しようとする攻撃に対するセキュリティが向上する可能性があります。詳細については、[RFC2560] のセクション 4.4.1 を参照してください。