GNU/Linux >> Linux の 問題 >  >> Linux

Java 8 での SQL Server JDBC エラー:ドライバーは、Secure Sockets Layer (SSL) 暗号化を使用して SQL Server への安全な接続を確立できませんでした

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

回避策 本番環境で使用していて、うまくいくことが証明されているのは、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

そのため、Linux JVM と SQL Server の間で TLSv1 がネゴシエートされると、接続は常に成功します。 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://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 無制限強度ポリシー、および TLS を介した SSL ハンドシェイク

    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


    これは、MS SQL JDBC ドライバーのバージョン 4.2 で修正されたようです。サーバーに 1000 回接続し、試行ごとに 100 ミリ秒を一時停止するプログラムを作成しました。バージョン 4.1 では、散発的にしか発生しませんでしたが、毎回問題を再現することができました。バージョン 4.2 では問題を再現できませんでした。


    SQL JDBC ドライバーをアップグレードする前に、まず互換性を確認してください:

    • Sqljdbc.jar は 5 の JRE を必要とし、JDBC 3.0 API をサポートします
    • Sqljdbc4.jar は 6 の JRE を必要とし、JDBC 4.0 API をサポートします
    • Sqljdbc41.jar は 7 の JRE を必要とし、JDBC 4.1 API をサポートします
    • Sqljdbc42.jar は 8 の JRE を必要とし、JDBC 4.2 API をサポートします

    ソース:https://www.microsoft.com/en-us/download/details.aspx?id=11774


    Linux
    1. プードルSSL攻撃からISPConfig3サーバーを保護する方法

    2. エラー:メイン クラスが見つからないか、読み込めませんでした

    3. CHECK_NRPE:エラー - SSL ハンドシェイクを完了できませんでした

    1. Windowsを修正する方法は、PassSpecializeの無人応答ファイルを解析または処理できませんでした

    2. PHPでssh2_connect()を使用して接続を確立できません

    3. WSL - GEDIT サーバーを初期化できません:接続できませんでした:接続が拒否されました

    1. Tmuxは.tmux.confを調達していませんか?

    2. 修正::LinuxSSHエラー接続が拒否されました

    3. サーバーのMySQLタイムアウトを変更する