我在一个Linux实例上的Java 8 JVM中启用了SSL记录,从而再现了这个问题.使用-Djavax.net.debug = ssl：handshake：verbose打开SSL日志记录.这显示了一些有用的信息.

我们在生产中使用并已证明可以为我们工作的解决方法是在JVM上设置此参数：

-Djdk.tls.client.protocols=TLSv1

如果你想要更多的细节,请继续阅读.

在可以再现问题的服务器上(再次只有5-10％的时间),我观察到以下情况：

*** ClientHello,TLSv1.2

--- 8

main,WRITE: TLSv1.2 Handshake,length = 195

main,READ: TLSv1.2 Handshake,length = 1130

*** ServerHello,TLSv1.2

--- 8

%% Initialized: [Session-79,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256]

** TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

--- 8

Algorithm: [SHA1withRSA]

--- 8

*** Diffie-Hellman ServerKeyExchange

--- 8

*** ServerHelloDone

*** ClientKeyExchange,DH

--- 8

main,length = 133

--- 8

main,WRITE: TLSv1.2 Change Cipher Spec,length = 1

*** Finished

verify_data: { 108,116,29,115,13,26,154,198,17,125,114,166 }

***

main,length = 40

main,called close()

main,called closeInternal(true)

main,SEND TLSv1.2 ALERT: warning,description = close_notify

main,WRITE: TLSv1.2 Alert,length = 26

main,called closeSocket(true)

main,waiting for close_notify or alert: state 5

main,received EOFException: ignored

main,called closeInternal(false)

main,close invoked again; state = 5

main,handling exception: java.io.IOException: sql Server returned an incomplete response. The connection has been closed. ClientConnectionId:12a722b3-d61d-4ce4-8319-af049a0a4415

请注意,TLSv1.2由数据库服务器选择并用于此交换.我观察到,当有问题的linux服务连接失败时,TLSv1.2始终是所选的级别.但是,当使用TLSv1.2时,连接不总是失败.他们只能在5-10％的时间内失败.

现在这里是一个没有问题的服务器的交换.一切都是平等的.即,连接到相同的数据库,相同版本的JVM(Java 1.8.0_60),相同的JDBC驱动程序等.请注意,在这里,TLSv1由数据库服务器而不是TLSv1.2选择,如在故障服务器的情况下.

*** ClientHello,length = 207

main,READ: TLSv1 Handshake,length = 604

*** ServerHello,TLSv1

--- 8

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA

--- 8

%% Initialized: [Session-79,TLS_RSA_WITH_AES_128_CBC_SHA]

** TLS_RSA_WITH_AES_128_CBC_SHA

--- 8

Algorithm: [SHA1withRSA]

--- 8

***

*** ServerHelloDone

*** ClientKeyExchange,RSA PreMasterSecret,TLSv1

--- 8

main,WRITE: TLSv1 Handshake,length = 134

main,WRITE: TLSv1 Change Cipher Spec,length = 1

*** Finished

verify_data: { 26,155,166,89,229,193,126,39,103,206,21 }

***

main,length = 48

main,READ: TLSv1 Change Cipher Spec,length = 1

main,length = 48

*** Finished

因此,当在Linux JVM和sql Server之间协商TLSv1时,连接总是成功的.当协商TLSv1.2时,我们得到零星的连接失败.

(注意：Java 7(1.7.0_51)总是协商TLSv1,这就是为什么我们使用Java 7 JVM的问题.)

我们还有的开放性问题是：

>为什么从两个不同的Linux服务器运行的相同的Java 8 JVM将始终协商TLSv1,但是当从另一个Linux服务器连接时,它始终协商TLSv1.2.

>而且为什么TLSv1.2协商连接在该服务器上最成功,但并非全部成功？

资源：