証明書チェーンの一般的な交換のためも使われる可能性がある。種別から区別するために要求される。中の下記の値は、本書を参照するように更新されている。中の記の値は、本書を参照するように更新されている。値は、本書を参照するように更新されている。セキュリティの考慮事項は、後述される。art)を監視することを続け、識別されたあらゆる弱点に対応する必要がある。English単一のサーバが複数のドメインをホストする場合、明らかに、各ドメインのオーナーにとっては「これ(サーバ)が、セキュリティニーズを満たすこと」を確保することが必要不可欠である。顕著なセキュリティ論点をもたらすようには現れない。提示する可能性があるので、これらの名前が同一であることに依存するアプリケーションサーバの実装は、「そのクライアントは、そのアプリケーションプロトコル内で異なる名前を提供しなかったこと」を確保するためにチェックしなければならない(MUST)。フィールドの値がどのようなものであれ、バッファオーバーフローが起こらないこと」を確保しなければならない(MUST)。English最大フラグメント長は、ハンドシェイクメッセージを含めて、ただちに影響を与える。無い、いかなるセキュリティの複雑な事項(complication)も持ち込まない。実装にフラグメント化されたハンドシェイクメッセージを扱えることを要求するからである。共に、そのサイファースィートおよび圧縮方法に依存すること」に注意。これは、バッファの大きさを測るとき、そしてバッファオーバーフローについてチェックするとき、考慮されなければならない。プロトコルにおけるクライアントとしてふるまうサーバを巻き込む。接続することを知らせることを試みる」という追加された関心事を伴う。一般に、この論点は、「攻撃者は、そのサーバを、何らかのセキュリティの欠陥について、脆弱である別のホストを間接的に攻撃するために使う可能性があること」を意味する。これは、サービス妨害攻撃の可能性ももたらす。ここでは、攻撃者は、そのサーバ宛に多くの接続(connection)を作る。その各々は、「その攻撃の標的宛に、そのサーバが試みる接続」をもたらす。「そのサーバは、ファイアウォールの背後に在る可能性があること、あるいは、さもなければ、公衆インターネットから直接のアクセスは不可能なホストにアクセスできること」に注意。これは、上記の潜在的なセキュリティ問題であったり、サービス妨害問題を実行可能であると共に、さもなければ隠されていたであろう内部ホストの存在を確認できるようにする可能性がある。プロキシサーバに適用されるものと同様である。場合、ループ(loop)およびデッドロック(deadlock)が作り出される可能性があり、これは、対応される必要がある。場合、攻撃が発生する。攻撃と同様のものである。拡張は、デフォルトで有効化されているのではなく、サーバ運用管理者によって特定して有効にされる必要があること」が推奨される(RECOMMENDED)。プロトコルは、その運用管理者によって個別に有効にされ、最小セットのプロトコルのみが有効にされこと」も推奨される(RECOMMENDED)。限られたセキュリティしか提供しない特殊な(unusual)プロトコル、もしくは、そのセキュリティがよく理解されていない特殊な(unusual)プロトコルは、避けられる必要がある(SHOULD)。問題をもたらす可能性があるのと同様に、問題をもたらす可能性がある。(これは、バッファオーバーフロー脆弱性を攻略する際に有用となってしまう可能性が、より高い。使い続け、アルゴリズムの交換可能性(agility)を提供しない。あり、衝突攻撃耐性ではない。対する攻撃は、サーバによって妥当な証明書として受容されて、同一の公開鍵を含む第二原像を要求する。ついて、正しくチェックしないものがあること」にも注意。リクエストが誤設定されたプロクシ(もしくは、壊れたプロキシ)を通過する場合、そのプロキシは、期限切れの(out-of-date)レスポンスを返す可能性がある。ルート鍵をクライアントが保持しているかは、機密情報と見なされうる」可能性がある。ルート鍵表示拡張は、注意を払って使われる必要がある。証明書ハッシュ代替(alternative)の利用は、「各証明書は、明確に(unambiguously)規定されること」を確保する。ハッシュの両方を使うことが必要不可欠とは信じられていなかった。弱い」という可能性がある。ついて、顕著な弱点は、現在、知られていないか、あるいは、存在することが予想されている。値の偽造(forging)は、オフラインではできないので、公開鍵暗号技術の鍵ほどの長さである必要はない。termination)を引き起こすこと」に注意。拡張が使われないところに(「そのハンドシェイク認証(authentication)は、セキュアである」という程度までに)強要することは、不可能である。メッセージ中のハッシュによって認証されている」ということに影響を与える。HMAC」について見つかった際には、あるセッションについて、クライアントかサーバのいずれかが、その問題を考慮して更新された場合、この拡張の利用を拒否することは可能である。レスポンスを要求する場合、クライアントは、「侵害された(compromised)鍵を使う攻撃者のサーバは、その拡張をサポートしないふりをする(そして、おそらく)可能性があること」を考慮しなければならない。サーバに直接、問い合わせるか、あるいは、そのハンドシェイクを中止するか、いずれかを行う必要がある(SHOULD)。レスポンスを再生することを試みる攻撃に対するセキュリティを改善する可能性がある。本書の間の顕著な変更点が、後述される。ついて、)一般的な拡張メカニズムと、具体的な拡張の両方を記述していた。