3

Java NIO および SSL ライブラリを使用して記述された、HTTP および HTTPS で実行される HTTP サーバーがあります。HTTPS モードでは、クライアント証明書の有無にかかわらず通信できます。しかし、再交渉をしたいです。ここで、クライアントは HTTPS で接続し、リソースを参照し、非常に安全なリソースに到達すると、サーバーはクライアントに証明書を要求します。これにはいくつかの問題があり、ワークフローがどうあるべきかを知る必要があります。これは、IE 9 と Chrome の両方で観察したことです。

1) クライアントがセキュアなリソースを要求すると、HTTP 要求に完全に応答します。次に、完了時にクライアントに証明書を要求します

engine.setNeedClientAuth(true);  
engine.beginHandshake();

その結果、クライアントからの TCP FIN が返され (クライアント側の接続が閉じられます)、再ネゴシエーションは失敗します。

2) クライアントが安全なリソースを要求すると、応答する前に証明書を要求します。このシナリオでは、交換が発生し、両方のブラウザーが証明書の要求をポップアップ表示しますが、プロンプトが表示されるとすぐにクライアントから TCP FIN が送信され、再ネゴシエーションが終了します。クライアントは、最終的に証明書を持つ別の要求を送信します。

ここでの私の質問は、何が起こるはずですか? 最初のブラウザ接続は開いたままであるはずですか、それともこのような終了は正常ですか?

注:ここでのもう 1 つの非常に興味深い観察は、シナリオ 2 で、ブラウザが TCP 接続を閉じると、証明書を選択した後に再接続することです。ただし、リクエストを再送信しません。ただそこに座って、サーバーが応答することを期待していますか? NIO の用語では、OP_READ を待機しています。これは、ソケットの入力バッファーにデータがないことを意味します。ブラウザは、接続を終了した元のメッセージへの応答を期待していますか??

このワークフローに関するドキュメントや仕様がまったくないのは奇妙なことですが、私がテストしたすべてのブラウザーで、このワークフローに従っているようです。

4

1 に答える 1

1

(1) は安全ではないため、これ以上議論する必要はありません。資格情報を要求する前に、すでに情報を漏らしています。

（2）はこれを行う正しい方法です。再ネゴシエーションを許可するように構成されている場合、クライアントは接続を閉じるべきではありません。昨年かそこらで SSL セキュリティの問題が発生したため、一時的に SSL 再ネゴシエーションがデフォルトで許可されないフェーズがありました。あなたはこれに遭遇するかもしれません。その場合、最初に HTTP リダイレクトを発行し、最後に接続を閉じて、クライアントに新しい接続を強制的に使用させる必要があります。新しい接続はクライアント証明書を要求する必要があります。コード内でそれをどのように配置するかは、あなた次第です。

于 2013-06-19T00:16:29.170 に答える