SSL / TLS再ネゴシエーションを使用する必要がありますか？
SSL/TLS再ネゴシエーションを使用する必要がありますか？つまり、SSL/TLSの再ネゴシエーションはセキュリティを強化または弱めますか？
問題は再交渉を行うことではありません。再ネゴシエーションが提供しないが提供するのは、セキュリティ特性を信じることです。
再ネゴシエーションは、SSL/TLS接続の最中に新しいハンドシェイクを作成しています。これは 標準 で説明されていますが、明確な用語ではありませんが、特に再交渉の申し出を保証するものを定義する場合はそうです。
再ネゴシエーションは、クライアント証明書、特にIISで使用される場合に非常に一般的です。次のようになります。
- サーバーはポート443で接続要求を受信します。握手が始まります。サーバーはクライアント証明書を要求しません。
- ハンドシェイクが完了すると、クライアントは実際のターゲットURLをSSLトンネルでHTTPリクエストとして送信します。その時点まで、サーバーはどのページがターゲットにされているのかわかりませんでした。彼はせいぜい、目的のサーバーnameしか知りませんでした（ Server Name Indication を通じて）。サーバーはどのページがターゲットにされているかを知ったので、どの "サイト"（つまり、サーバーの一部、IIS用語））が使用されるかを知っています。
- 特定のサイトが証明書ベースのクライアント認証を必要とするか、少なくとも要求する場合、サーバーは新しいハンドシェイクをトリガーします。今回は
CertificateRequestメッセージが表示されます。
ここでのセキュリティ問題は、レイヤーの問題です。ハンドシェイクメッセージは、メインの「アプリケーションデータ」トラフィック（単なるHTTP）の周囲に、管理用のアウトオブバンド管理対話として「裏側」に表示されます。新しいハンドシェイクが実行されると、その後に送信されたアプリケーションデータは、SSLの認証の傘によってカバーされます。ただし、2番目のハンドシェイクの前に送信されたアプリケーションデータ、特にサーバーが2番目のハンドシェイクを実行することを決定した最初のHTTPリクエスト、またはその他のHTTPリクエストその後（ただし、新しいハンドシェイクの前）にパイプライン処理されますか？
Webサーバーは、2番目のハンドシェイクで実行された認証はすべて、過去のデータに遡って「転送」できると仮定する傾向があります。たまたまそうなのです。これはSSL/TLS標準では明確に述べられていませんが、そのような認証は順方向にのみ機能し、タイムトラベルはありません。前の段落で重要な言葉は「その後」です。これにより実際の攻撃が可能になりました（広範な説明へのポインタについては このページ を参照してください）。
実際の攻撃の重要なポイントは、2番目のハンドシェイクメッセージが新しい接続のハンドシェイクメッセージ（つまり、「最初のハンドシェイク」）と区別できないことです。 RFC 5746 は、主要なブラウザとサーバーに実装されているパッチについて説明しています（セキュリティ修正で最新であると想定しています。それ以外の場合は、とにかく大きな問題を抱えています）。これは、OpenSSLが「Secure Renegotiation」として報告するものでもあります。 RFCが率直に言っていることに注意してください：
この拡張機能は、概要で説明した中間者攻撃を軽減しますが、再ネゴシエーションを認識していない場合にアプリケーションが直面する可能性のあるすべての問題を解決するわけではありません。
言い換えれば、これは実証済みの問題を修正するためのパッチですが、すべての根拠を網羅しているわけではありません。再交渉が実際に提供するものは、まだどこにも明確に定義されていません。クライアントとサーバーが「安全な再ネゴシエーション」をサポートしている場合、現時点では問題ありません（すべての現在知られている攻撃を防ぎます）。再交渉とインターリーブハンドシェイクの全体的な概念は、まだより正式な分析を必要としています。
再ネゴシエーション中に、攻撃者は接続に情報を挿入できます。詳細は here で説明しています。