GNU/Linux >> Znalost Linux >  >> Linux

Chyba SQL Server JDBC v jazyce Java 8:Ovladač nemohl vytvořit zabezpečené připojení k serveru SQL pomocí šifrování Secure Sockets Layer (SSL)

Zapnul jsem protokolování SSL v Java 8 JVM na instanci Linuxu, která reprodukuje problém. Protokolování SSL se zapíná pomocí -Djavax.net.debug=ssl:handshake:verbose . To odhalilo některé užitečné informace.

Řešení který používáme ve výrobě a osvědčil se nám, je nastavit tento parametr na JVM:

 -Djdk.tls.client.protocols=TLSv1

Pokud chcete další podrobnosti, čtěte dále.

Na serveru, kde lze problém reprodukovat (opět pouze 5–10 % případů), jsem zaznamenal následující:

*** 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

Všimněte si, že TLSv1.2 je vybrán databázovým serverem a používán při této výměně. Všiml jsem si, že když selžou připojení z problematické linuxové služby, TLSv1.2 je VŽDY zvolená úroveň. Při použití TLSv1.2 se však připojení VŽDY nezdaří. Selhávají pouze v 5–10 % případů.

Nyní je zde výměna ze serveru, který NEMÁ problém. Všechno ostatní je stejné. Tj. připojení ke stejné databázi, stejné verzi JVM (Java 1.8.0_60), stejnému ovladači JDBC atd. Všimněte si, že zde TLSv1 je vybrán databázovým serverem namísto TLSv1.2 jako v případě vadného serveru.

*** 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

Takže když je TLSv1 vyjednáno mezi Linux JVM a SQL Server, připojení jsou VŽDY úspěšná. Když je vyjednáno TLSv1.2, dochází k sporadickým selháním připojení.

(Poznámka:Java 7 (1.7.0_51) vždy vyjednává TLSv1, což je důvod, proč u nás s Java 7 JVM problém nikdy nenastal.)

Stále máme otevřené otázky:

  1. PROČ je to, že stejný Java 8 JVM spuštěný ze 2 různých linuxových serverů vždy vyjedná TLSv1, ale při připojení z jiného linuxového serveru vždy vyjedná TLSv1.2.
  2. A také proč jsou vyjednaná připojení TLSv1.2 úspěšná většinou, ale ne všude, na tomto serveru?

Aktualizace z 10. 6. 2017: Tento příspěvek od společnosti Microsoft popisuje problém a jeho navrhované řešení.

Zdroje:

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 Unlimited Strength Policy a SSL Handshake přes 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


Zdá se, že toto bylo opraveno ve verzi 4.2 ovladače MS SQL JDBC. Vytvořil jsem program, ve kterém jsem se k serveru připojil 1000krát a mezi každým pokusem jsem udělal pauzu 100 ms. S verzí 4.1 jsem byl schopen problém reprodukovat pokaždé, i když se to vyskytovalo jen sporadicky. S verzí 4.2 jsem nebyl schopen problém reprodukovat.


Před upgradem ovladače SQL JDBC nejprve zkontrolujte kompatibilitu:

  • Sqljdbc.jar vyžaduje JRE 5 a podporuje JDBC 3.0 API
  • Sqljdbc4.jar vyžaduje JRE 6 a podporuje JDBC 4.0 API
  • Sqljdbc41.jar vyžaduje JRE 7 a podporuje JDBC 4.1 API
  • Sqljdbc42.jar vyžaduje JRE 8 a podporuje JDBC 4.2 API

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


Linux
  1. Tmux nevyužívá .tmux.conf?

  2. Změňte časový limit MySQL na serveru

  3. Jak zabezpečit připojení SSL s Apache na Ubuntu 18.04

  1. Chyba:Nelze najít nebo načíst hlavní třídu

  2. CHECK_NRPE:Chyba – nelze dokončit navázání spojení SSL

  3. WSL - GEDIT Nelze inicializovat server:Nelze se připojit:Připojení odmítnuto

  1. Jak zabezpečit váš server ISPConfig 3 proti útoku pudle SSL

  2. Jak opravit Windows nemohl analyzovat nebo zpracovat soubor odpovědí bezobslužné služby pro Pass Specialize

  3. Nelze navázat spojení pomocí ssh2_connect() v PHP