Java8でのSQLServerJDBCエラー：ドライバーは、Secure Sockets Layer（SSL）暗号化を使用してSQLServerへの安全な接続を確立できませんでした

LinuxインスタンスのJava8JVMでSSLロギングをオンにしたところ、問題が再現されました。 SSLロギングは、-Djavax.net.debug=ssl:handshake:verboseを使用してオンになります。これにより、いくつかの有用な情報が明らかになりました。

回避策 私たちが本番環境で使用していて、私たちのために機能することが証明されているのは、JVMでこのパラメーターを設定することです：

 -Djdk.tls.client.protocols=TLSv1

詳細については、以下をお読みください。

問題を再現できるサーバーで（ここでも、5〜10％の確率で）、次のことがわかりました。

*** ClientHello, TLSv1.2
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 195
main, READ: TLSv1.2 Handshake, length = 1130
*** ServerHello, TLSv1.2
--- 8<-- SNIP -----
%% Initialized:  [Session-79, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256]
** TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
--- 8<-- SNIP -----
Algorithm: [SHA1withRSA]
--- 8<-- SNIP -----
*** Diffie-Hellman ServerKeyExchange
--- 8<-- SNIP -----
*** ServerHelloDone
*** ClientKeyExchange, DH
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 133
--- 8<-- SNIP -----
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, WRITE: TLSv1.2 Handshake, 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, TLSv1.2
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 207
main, READ: TLSv1 Handshake, length = 604
*** ServerHello, TLSv1
--- 8<-- SNIP -----
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
--- 8<-- SNIP -----
%% Initialized:  [Session-79, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
--- 8<-- SNIP -----
Algorithm: [SHA1withRSA]
--- 8<-- SNIP -----
***
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
--- 8<-- SNIP -----
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, 126, 21 }
***
main, WRITE: TLSv1 Handshake, length = 48
main, READ: TLSv1 Change Cipher Spec, length = 1
main, READ: TLSv1 Handshake, length = 48
*** Finished

したがって、TLSv1がLinuxJVMとSQLServerの間でネゴシエートされると、接続は常に成功します。 TLSv1.2がネゴシエートされると、散発的な接続障害が発生します。

（注：Java 7（1.7.0_51）は常にTLSv1をネゴシエートします。そのため、Java 7 JVMで問題が発生することはありませんでした。）

まだ残っている未解決の質問は次のとおりです。

なぜ、2つの異なるLinuxサーバーから実行される同じJava 8 JVMは常にTLSv1をネゴシエートしますが、別のLinuxサーバーから接続する場合は常にTLSv1.2をネゴシエートします。
また、TLSv1.2でネゴシエートされた接続が、そのサーバーでほとんどの場合成功するのはなぜですか？

2017年6月10日更新： Microsoftからのこの投稿では、問題とその提案された解決策について説明しています。

リソース：

http://www.infoworld.com/article/2849292/operating-systems/more-patch-problems-reported-with-the-ms14-066-kb-2992611-winshock-mess.html

http://blogs.msdn.com/b/jdbcteam/archive/2008/09/09/the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure- sockets-layer-ssl-encryption.aspx

Java 8、JCE Unlimited Strength Policy、SSL Handshake over TLS

http://blogs.msdn.com/b/saponsqlserver/archive/2013/05/10/analyzing-jdbc-connection-issues.aspx

https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#descPhase2

https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls