在异常的请求开始 - ClientAuth SSL [英] Exception at start of request - ClientAuth SSL

问题描述

我有一个应用程序中嵌入码头。我想使用SSL客户端证书认证，当我启用;我正在逐渐的请求开始，以下情况例外。但该请求得到后正常服务。从IE或Chrome访问时，此异常只配备。从Firefox访问时它不来的。我们有我们的扩展SslSocketConnector定制SSLConnector。我试图调试它;但想知道是否有任何特定的地方/ code在那里我可以开始检查。

I have an application embedding Jetty. I would like to use client cert authentication in SSL and when I enable that; I am getting the following exception at start of request. But the request is getting served properly after that. This exception comes only when accessed from IE or Chrome. It does not come when accessed from Firefox. We have our custom SSLConnector extending SslSocketConnector. I am trying to debug it; but wanted to know if there is any specific place/code where I can start checking.

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:808) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123) 
        at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:631) 
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451) 
Caused by: java.io.EOFException: SSL peer shut down incorrectly 
        at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:333) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789) 

更新：

我启用SSL调试选项，并得到一个立即读取后ServerHelloDone消息此异常。这是服务器请求客户端证书，我相信一起发送其证书的信息。我不知道什么在第一次读取发生。任何帮助是深深AP preciated。

I enabled SSL debug option and was getting this exception on a read immediately after the ServerHelloDone message. This is the message where server sends its cert along with request for client certificate i believe. I am not sure whats happening in first read. Any help is deeply appreciated.

*** ClientHello, TLSv1
****
%% Created:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
*** ServerHello, TLSv1
*** Certificate chain
***
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
*** ServerHelloDone
WRITE: TLSv1 Handshake, length = 703
received EOFException: error
handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

更新：
更新JDK到最新，23和启用/禁用这两个属性尝试。还是流汗相同的行为。

Update: Updated JDK to latest, 23 and tried with the two properties enabled/disabled. Still gettting the same behavior.

更多信息：
使用TLSv1和SSLv3的所有浏览器都启用。该通信正常发生未经客户-auth的启用。随着客户端验证，我们总是在第一次握手得到异常，接下来就是越来越得当，没有例外进行。使用码头6.1.14版本在服务器端

More info: TLSv1 and SSLv3 are enabled in all browsers. The communication is happening properly without client-auth enabled. With client auth, always we get exception on first handshake and the next is getting properly done and proceeding without exceptions. Using jetty version 6.1.14 at server side

推荐答案

我已经看到了这样的使用TLS / SSLv3的协商议题。
<一href=\"http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html\">http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html

I have seen issues like this with TLS/SSLv3 negotiation. http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html

在SSL / TLS，再谈判可以通过任一侧发起的。像第一阶段的修复，应用与可互操作的模式下未升级等并尝试启动重新协商（通过 SSLSocket.startHandshake通信（）或 SSLEngine.beginHandshake（））将获得出现SSLHandshakeException （ IOException异常）和连接将被关闭（ handshake_failure ）。接收来自非升级等重新协商请求，申请将按照适当的连接类型回应：

In SSL/TLS, renegotiations can be initiated by either side. Like the Phase 1 fix, applications communicating with an un-upgraded peer in Interoperable mode and that attempt to initiate renegotiation (via SSLSocket.startHandshake() or SSLEngine.beginHandshake()) will receive a SSLHandshakeException (IOException) and the connection will be shutdown (handshake_failure). Applications that receive a renegotiation request from a non-upgraded peer will respond according to the type of connection in place:

  
• 的TLSv1：警告提示类型的消息 no_renegotiation （100）将被发送到对等和该连接将保持打开状态。旧版本SunJSSE将关机 no_renegotiation 警报在收到时连接。

  
• 的SSLv3：应用程序将获得出现SSLHandshakeException ，并且连接将被关闭（ handshake_failure ）。 （ no_renegotiation 未在SSLv3的规范中定义。）

  

• TLSv1: A warning Alert message of type "no_renegotiation(100)" will be sent to the peer and the connection will remain open. Older versions of SunJSSE will shutdown the connection when a "no_renegotiation" Alert is received.
• SSLv3: The application will receive a SSLHandshakeException, and the connection will be closed (handshake_failure). ("no_renegotiation" is not defined in the SSLv3 spec.)

要设置这些模式，2个系统属性用于：

To set these modes, two system properties are used:

  
• sun.security.ssl.allowUnsafeRenegotiation - 在第一阶段推出，这种控制是否遗留（不安全的）重新谈判允许

  
• sun.security.ssl.allowLegacyHelloMessages - 在第二阶段推出，这使得同行，而不需要适当的RFC 5746的消息握手
。
  

• sun.security.ssl.allowUnsafeRenegotiation - Introduced in Phase 1, this controls whether legacy (unsafe) renegotiations are permitted.
• sun.security.ssl.allowLegacyHelloMessages - Introduced in Phase 2, this allows the peer to handshake without requiring the proper RFC 5746 messages.

如果仍然没有帮助，您可以尝试打开SSL dedug，并采取一看握手。结果
-Djavax.net.debug =所有

If that still doesn't help, you can try turning on SSL dedug, and taking a look at the handshaking.
-Djavax.net.debug=all

这篇关于在异常的请求开始 - ClientAuth SSL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！