8

自己署名証明書を使用して、javax.net.ssl を利用する https サーバーの単純な Netty 実装。サーバーが起動し、Restlet によって DHCを使用して要求が行われます。サーバー側では次のようになります。

io.netty.handler.ssl.SslHandler setHandshakeFailure 警告: SSLEngine.closeInbound() は、接続が閉じられているために例外を発生させました。javax.net.ssl.SSLException: ピアの close_notify を受信する前に受信が閉じられました: トランケーション攻撃の可能性がありますか? sun.security.ssl.Alerts.getSSLException (未知のソース) で sun.security.ssl.SSLEngineImpl.fatal (未知のソース) で sun.security.ssl.SSLEngineImpl.fatal (未知のソース) で sun.security.ssl.SSLEngineImpl io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:905) の .closeInbound (不明なソース) io.netty.handler.ssl.SslHandler.channelInactive(SslHandler.java:576) で io.netty.channel .DefaultChannelHandlerContext.invokeChannelInactive(DefaultChannelHandlerContext.java:819) で io.netty.channel.DefaultChannelHandlerContext.access$1300(DefaultChannelHandlerContext.java:38) で io.netty.channel.DefaultChannelHandlerContext$5.run(DefaultChannelHandlerContext.java:808) で io. io.netty の netty.channel.SingleThreadEventExecutor.runAllTask​​s(SingleThreadEventExecutor.java:259)。channel.nio.NioEventLoop.run(NioEventLoop.java:305) at io.netty.channel.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:110) at java.lang.Thread.run(不明なソース)

そしてクライアント側では：

応答なし。証明書は有効ですか？ここをクリックして確認してください。

Chrome のアドレス バーで同じリクエストを発行すると、同じサーバー側の例外が発生します。Firefox のアドレス バーで同じ例外を発行すると、証明書が信頼できる CA からのものではないという警告ページが Firefox に表示されます。この例外は非常に一般的なようで、プロトコルの状態を直接示しているわけではありません。これら 3 つのクライアント (Chrome、Firefox、Restlet による DHC ) がプロトコルを適切に実行しておらず、close_notify を送信するのではなく、サーバー上で消えてしまうということですか? それとも、SSL RFC によって義務付けられているクライアント側の動作ですか、それとも単にセキュリティ指向のクライアント側の設計ですか?

4

2 に答える 2

5

Restlet チームから DHC に連絡したところ、回避策を教えてくれました。

Chrome には、証明書を管理するための API が用意されていません。つまり、証明書を自動的に受け入れる API も、「信頼されていない証明書」ダイアログを表示する方法もありません。ただし、少し回避策を使用できます。

  1. 別のタブで https URL を開きます。
  2. 証明書を手動で受け入れます。
  3. DHC に戻ると、前の手順で証明書が手動で受け入れられている (Chrome に保存されている) ため、機能します。

通常、これは一度だけ行う必要があります。

于 2013-07-10T15:57:05.227 に答える