2

SSLEngineのドキュメントには、SSL 接続を適切に閉じる方法が示されています。より具体的には、切断された接続を処理する方法について説明します。

正常なシャットダウンに加えて、クローズ メッセージが交換される前にトランスポート リンクが切断される非正常なシャットダウンも発生する可能性があります。前の例では、非ブロッキング SocketChannel に対して読み取りまたは書き込みを試行すると、アプリケーションは -1 を取得する可能性があります。入力データの最後に到達したら、engine.closeInbound() を呼び出す必要があります。これにより、リモート ピアが SSL/TLS の観点から正常に閉じられたことを SSLEngine で検証します。その後、アプリケーションは引き続き正常にシャットダウンを試行する必要があります。上記の手順を使用して。

基本的に、リンクが切れた場合はengine.closeInbound()呼び出す必要があります。ただし、このcloseInbound()メソッドのドキュメントには、ピアから適切な終了メッセージを受信する前に呼び出された場合、例外がスローされることが示されています。接続が切断された場合、この close_notify メッセージは決して受信されないように思われるため、このメソッドは常にその例外をスローします。

私はテストを行い、socketChannel.read()-1 を返す単純なシャットダウン プロシージャを作成しました。呼び出すengine.closeInbound()と、実際に次の例外が発生します。

javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?

私は何が欠けていますか？ドキュメントのこれら 2 つの部分は矛盾していませんか?

4

2 に答える 2

4

ドキュメントのこれら 2 つの部分が互いに矛盾しているとは思いません。

入力データの最後に到達したら、engine.closeInbound() を呼び出す必要があります。

これは、完全に閉じた接続と切断された接続の両方に適用されます。例外がスローされるのは、接続が切断されたときです (つまり、 を受信する前に呼び出した場合close_notify)。が受信された場合close_notify(または接続がまったく開始されていない場合)、この例外はスローされません。

単純なシャットダウン テストをどのように行ったのかよくわかりませんが、close_notify最初に相手側から送信する必要がありました (closeOutbound()たとえば、)。socketChannel.read()この場合、取得する前にfrom から -1 を受け取るべきではありませんclose_notify(その場合、例外は発生しません)。

（参考までに、少し前に同様の質問がありました。）SSLSocket

于 2014-04-16T13:21:40.477 に答える
3

あなたはこれを読み違えました。

基本的にリンクが切れている場合は、closeInbound() を呼び出す必要があります。

それはまったく言わない。

closeInbound()メソッドは常に「入力データの最後に到達したとき」に呼び出す必要があり、切断された接続を検出します。

close_notifyが受信されない場合、例外がスローされます。

于 2014-04-16T22:31:48.283 に答える