Saya mengaktifkan SSL logging di Java 8 JVM pada instance Linux yang mereproduksi masalah. Log SSL diaktifkan menggunakan -Djavax.net.debug=ssl:handshake:verbose . Ini mengungkapkan beberapa informasi berguna.
Solusinya yang kami gunakan dalam produksi dan telah terbukti berhasil bagi kami adalah menyetel parameter ini di JVM:
-Djdk.tls.client.protocols=TLSv1
Jika Anda ingin detail lebih lanjut, silakan baca terus.
Di server tempat masalah dapat direproduksi (sekali lagi, hanya 5-10% dari waktu), saya mengamati hal berikut:
*** 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
Perhatikan bahwa TLSv1.2 dipilih oleh server database dan digunakan dalam pertukaran ini. Saya telah mengamati bahwa, ketika koneksi gagal dari layanan linux yang bermasalah, TLSv1.2 SELALU merupakan level yang dipilih. Namun, koneksi tidak SELALU gagal saat TLSv1.2 digunakan. Mereka hanya gagal 5-10% dari waktu.
Sekarang di sini adalah pertukaran dari server yang TIDAK bermasalah. Segala sesuatu yang lain adalah sama. Yaitu, menghubungkan ke database yang sama, versi JVM yang sama (Java 1.8.0_60), driver JDBC yang sama, dll. Perhatikan bahwa, di sini, TLSv1 dipilih oleh server basis data alih-alih TLSv1.2 seperti pada kasus server yang salah.
*** 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
Jadi, saat TLSv1 dinegosiasikan antara Linux JVM dan SQL Server, koneksi SELALU berhasil. Saat TLSv1.2 dinegosiasikan, kami mendapatkan kegagalan koneksi sporadis.
(Catatan:Java 7 (1.7.0_51) selalu menegosiasikan TLSv1, itulah sebabnya masalah tidak pernah terjadi pada kami dengan JVM Java 7.)
Pertanyaan terbuka yang masih kami miliki adalah:
- MENGAPA Java 8 JVM yang sama dijalankan dari 2 server Linux yang berbeda akan selalu menegosiasikan TLSv1, tetapi saat menghubungkan dari server Linux lain selalu menegosiasikan TLSv1.2.
- Dan juga mengapa koneksi yang dinegosiasikan TLSv1.2 paling berhasil, tetapi tidak semua, di server itu?
Pembaruan 10/6/2017: Posting dari Microsoft ini menjelaskan masalah dan solusi yang mereka usulkan.
Sumber:
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-build-a-secure-connection-to-sql-server-by-using-secure- sockets-layer-ssl-encryption.aspx
Java 8 , Kebijakan Kekuatan Tak Terbatas JCE dan Jabat Tangan SSL melalui 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
Ini tampaknya telah diperbaiki dalam versi 4.2 dari driver MS SQL JDBC. Saya membuat program di mana saya terhubung ke server 1000 kali, menjeda 100ms di antara setiap upaya. Dengan versi 4.1 saya dapat mereproduksi masalah setiap saat, meskipun hanya terjadi secara sporadis. Dengan versi 4.2 saya tidak dapat mereproduksi masalah.
Sebelum Anda memutakhirkan SQL JDBC Driver, periksa dulu kompatibilitasnya:
- Sqljdbc.jar membutuhkan JRE 5 dan mendukung JDBC 3.0 API
- Sqljdbc4.jar memerlukan JRE 6 dan mendukung JDBC 4.0 API
- Sqljdbc41.jar membutuhkan JRE 7 dan mendukung JDBC 4.1 API
- Sqljdbc42.jar membutuhkan JRE 8 dan mendukung JDBC 4.2 API
Sumber:https://www.microsoft.com/en-us/download/details.aspx?id=11774