I'm trying to connect to a WCF server that needs a client cert. I've imported the client cert into a JKS file locally and provided the cert location to the JAXWS client using the -Djavax.net.ssl*** options. The SSL debug prints the below information before it finally gets a Connection refused exception. Apparently the handshake seems to successful but then a closeInternal(true) is called and then the exception. Any clues/ideas are much appreciated. Thanks in advance.
... no IV used for this cipher
main, WRITE: TLSv1 Change Cipher Spec, length = 17
*** Finished
verify_data: { 68, 26, 22, 198, 55, 196, 10, 167, 6, 30, 206, 143 }
***
main, WRITE: TLSv1 Handshake, length = 32
main, READ: TLSv1 Change Cipher Spec, length = 17
main, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data: { 233, 31, 138, 146, 138, 210, 137, 249, 81, 126, 169, 166 }
***
%% Cached client session: [Session-3, SSL_RSA_WITH_RC4_128_MD5]
main, READ: TLSv1 Application Data, length = 469
main, called close()
main, called closeInternal(true)
main, SEND TLSv1 ALERT: warning, description = close_notify
main, WRITE: TLSv1 Alert, length = 18
Exception in thread "main" com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.
java.net.ConnectException: Connection refused: connect
java.net.ConnectException: Connection refused: connect
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:161)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:133)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:254)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:165)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:93)
at javax.xml.ws.Service.<init>(Service.java:56)
at com.acs.echo.gen.EchoService.<init>(EchoService.java:46)
at com.acs.echo.client.EchoClient.invokeWebService(EchoClient.java:43)
at com.acs.echo.client.EchoClient.main(EchoClient.java:17)
The SSL handshake and TCP connection to the server are succeeding, but the retrieval of the WSDL is failing. It appears to be coming from a non-SSL host that is giving you 'connection refused', which means that nothing is listened at the port specified in the WSDL RL, or maybe an intervening firewall has vetoed the connect attempt.
Related
I am having a problem connecting to SQL Server 2012 using TLS1.2. Below is the code,network trace and output from NMap. From the trace and Nmap output I think it looks like there is a cipher problem but I am not sure. The trace tells me the handshake starts with TLS 1.2 but then the connection gets closed and don't know why. If it is a cipher problem, how does the handshake determine which cipher to use and where are the possible ciphers stored?
Using: IBM Java 6, SQL Server 2012, sqljdbc4.jar
Thanks
public static void doConnect2()
{
try
{
System.setProperty("javax.net.debug", "all");
System.setProperty("javax.net.debug","ssl:handshake:verbose");
System.setProperty("com.ibm.jsse2.overrideDefaultTLS","true");
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver").newInstance();
Connection conn = DriverManager.getConnection(
"jdbc:sqlserver://MIMV-DBTE02;databaseName=CMS",
"userid",
"password");
}
catch(Exception e)
{
System.out.println(e.getMessage());
}
}
Network Trace:
IBMJSSE2 will not allow protocol SSLv3 per com.ibm.jsse2.disableSSLv3 set to TRUE or default
IBMJSSEProvider2 Build-Level: -20171020
IBMJSSE2 will set SSLContext per com.ibm.jsse2.overrideDefaultTLS set to true
Installed Providers =
IBMPKCS11Impl
IBMJCE
IBMJSSE2
IBMJGSSProvider
IBMCertPath
IBMCMSProvider
IBMSPNEGO
IBMSASL
IBMXMLCRYPTO
IBMXMLEnc
Policy
keyStore is: C:\IBM\WebSphere85\AppServer\java\jre\lib\security\cacerts
keyStore type is: jks
keyStore provider is:
init keystore
SSLContextImpl: Using X509ExtendedKeyManager com.ibm.jsse2.id
SSLContextImpl: Using X509TrustManager com.microsoft.sqlserver.jdbc.TDSChannel$PermissiveX509TrustManager
JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.2
trigger seeding of SecureRandom
done seeding SecureRandom
IBMJSSE2 will enable CBC protection
IBMJSSE2 to send SCSV Cipher Suite on initial ClientHello
JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version 1.2
jdk.tls.client.protocols is defined as null
SSLv3 protocol was requested but was not enabled
SSLv3 protocol was requested but was not enabled
SUPPORTED: [TLSv1, TLSv1.1, TLSv1.2]
SERVER_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
CLIENT_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
IBMJSSE2 will allow RFC 5746 renegotiation per com.ibm.jsse2.renegotiate set to none or default
IBMJSSE2 will not require renegotiation indicator during initial handshake per com.ibm.jsse2.renegotiation.indicator set to OPTIONAL or default taken
IBMJSSE2 will not perform identity checking against the peer cert check during renegotiation per com.ibm.jsse2.renegotiation.peer.cert.check set to OFF or default
IBMJSSE2 will not allow unsafe server certificate change during renegotiation per jdk.tls.allowUnsafeServerCertChange set to FALSE or default
Is initial handshake: true
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1505038140 bytes = { 3, 147, 184, 179, 43, 30, 167, 241, 216, 122, 188, 126, 82, 179, 249, 106, 59, 94, 84, 130, 211, 236, 170, 210, 180, 91, 234, 57 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RENEGO_PROTECTION_REQUEST]
Compression Methods: { 0 }
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA256withDSA, SHA1withDSA, MD5withRSA
***
main, WRITE: TLSv1.2 Handshake, length = 101
main, called close()
main, called closeInternal(true)
main, SEND TLSv1 ALERT: warning, description = close_notify
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket(selfInitiated)
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 did not return a response. The connection has been closed. ClientConnectionId:8d6d75fb-67d7-4114-9f62-cd6886be0557
main, SEND TLSv1 ALERT: fatal, description = unexpected_message
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
Mar 23, 2018 10:29:17 AM com.microsoft.sqlserver.jdbc.TDSChannel enableSSL
INFO: java.security path: C:\IBM\WebSphere85\AppServer\java\jre\lib\security
Security providers: [IBMPKCS11Impl version 1.6, IBMJCE version 1.2, IBMJSSE2 version 1.6, IBMJGSSProvider version 1.6, IBMCertPath version 1.1, IBMCMSProvider version 59.0, IBMSPNEGO version 1.0, IBMSASL version 1.5, IBMXMLCRYPTO version 1.0, IBMXMLEnc version 1.0, Policy version 1.0]
SSLContext provider info: IBM JSSE provider2 (implements IbmX509 key/trust factories, SSLv3, TLSv1)
SSLContext provider services:
[Provider IBMJSSE2 Service SSLContext.SSL com.ibm.jsse2.uc
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.SSL_TLSv2 com.ibm.jsse2.wc
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLSv1 com.ibm.jsse2.zc
Aliases []
Attributes {}, Provider IBMJSSE2 Service KeyManagerFactory.NewIbmX509 com.ibm.jsse2.rc$b_
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.SSL_TLS com.ibm.jsse2.vc
Aliases []
Attributes {}, Provider IBMJSSE2 Service TrustManagerFactory.IbmX509 com.ibm.jsse2.fd$b_
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLSv1.1 com.ibm.jsse2.ad
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLS com.ibm.jsse2.yc
Aliases []
Attributes {}, Provider IBMJSSE2 Service KeyManagerFactory.IbmX509 com.ibm.jsse2.rc$a_
Aliases []
Attributes {}, Provider IBMJSSE2 Service SSLContext.TLSv1.2 com.ibm.jsse2.bd
Aliases []
Attributes {}, Provider IBMJSSE2 Service TrustManagerFactory.PKIX com.ibm.jsse2.fd$a_
Aliases [IbmPKIX, X509, X.509]
Attributes {}, Provider IBMJSSE2 Service SSLContext.Default com.ibm.jsse2.tc
Aliases []
Attributes {}]
java.ext.dirs: C:\IBM\WebSphere85\AppServer\java\jre\lib\ext
NMap:
1433/tcp open ms-sql-s
| ssl-enum-ciphers:
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Weak certificate signature: SHA1
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
| warnings:
| Weak certificate signature: SHA1
|_ least strength: A
I'am trying to invoke SOAP service, hosted on IIS server (version unknown) from java application inside Docker container. Added CE certificate to JDK cert store. Also there is a proxy server in our corporate network. IIS server located in private network, so I added JDK proxy CLI parameters to go through proxy to internet and bypass proxy for private network. Communication with internet over HTTPS is fine, but invoking IIS server I always receive such error:
Telegram Executor, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data: { 179, 239, 20, 68, 62, 114, 149, 9, 213, 8, 166, 3 }
***
Telegram Executor, WRITE: TLSv1.2 Handshake, length = 40
Telegram Executor, READ: TLSv1.2 Change Cipher Spec, length = 1
Telegram Executor, READ: TLSv1.2 Handshake, length = 40
*** Finished
verify_data: { 188, 169, 41, 148, 80, 6, 90, 100, 144, 226, 166, 42 }
***
%% Cached client session: [Session-6, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
Telegram Executor, WRITE: TLSv1.2 Application Data, length = 676
Telegram Executor, WRITE: TLSv1.2 Application Data, length = 772
Telegram Executor, handling exception: java.net.SocketException: Connection reset
%% Invalidated: [Session-6, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
Telegram Executor, SEND TLSv1.2 ALERT: fatal, description = unexpected_message
Telegram Executor, WRITE: TLSv1.2 Alert, length = 26
Telegram Executor, Exception sending alert: java.net.SocketException: Broken pipe (Write failed)
Telegram Executor, called closeSocket()
Telegram Executor, called close()
Telegram Executor, called closeInternal(true)
Mar 19, 2018 9:26:13 AM org.telegram.telegrambots.logging.BotLogger severe
SEVERE: BOTSESSION
javax.xml.ws.WebServiceException: java.net.SocketException: Connection reset
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:195)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:226)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:217)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:130)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:124)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:1121)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:1035)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:1004)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:862)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:448)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:178)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147)
at com.sun.proxy.$Proxy46.getUserInfo(Unknown Source)
at isd.bot.commands.TimeClockSecureCommand.timeClockLoginHandler(TimeClockSecureCommand.java:89)
at isd.bot.commands.TimeClockSecureCommand.execute(TimeClockSecureCommand.java:59)
at isd.bot.DefaultUpdateHandler.accept(DefaultUpdateHandler.java:49)
at isd.bot.DefaultUpdateHandler.accept(DefaultUpdateHandler.java:16)
at isd.bot.IsdTelegramLongPollingBotImpl.onUpdateReceived(IsdTelegramLongPollingBotImpl.java:43)
at java.util.ArrayList.forEach(ArrayList.java:1255)
at org.telegram.telegrambots.generics.LongPollingBot.onUpdatesReceived(LongPollingBot.java:27)
at org.telegram.telegrambots.updatesreceivers.DefaultBotSession$HandlerThread.run(DefaultBotSession.java:311)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:706)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:191)
... 22 more
The same service works fine from .NET application.
Could you please advice what can be the problem?
Java side code:
ITimeClockServer service = new TimeClockServer().getWSHttpBindingITimeClockServer();
((BindingProvider)result).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, BotProperties.getInstance().getTimeClockEndpoint());
((BindingProvider)result).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, BotProperties.getInstance().getUserLogin());
((BindingProvider)result).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, BotProperties.getInstance().getUserPassword());
TimeClockUserInfo userInfo = service.getUserInfo(login);
I have strange problem, that I could not fixed.
I have JDK 1.5 version and SSL based communication via sockets, simply send and receive string data.
try {
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(
"path_to_.jks"),
"secret_of_jks".toCharArray());
TrustManagerFactory tmf = TrustManagerFactory
.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(ks);
KeyManagerFactory kmf = KeyManagerFactory
.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(ks, "secret_of_jks".toCharArray());
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
Socket s = ctx.getSocketFactory().createSocket("address_of_server", PORT);
String jsonEx = "json text to send server";
StringBuilder sb = new StringBuilder();
sb.append(jsonEx.getBytes().length);
sb.append("\r\n");
sb.append(jsonEx);
PrintWriter writer = new PrintWriter(s.getOutputStream(), true);
writer.println(sb.toString());
BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream()));
System.out.println(in.readLine());
writer.flush();
} catch (Exception e) {
e.printStackTrace();
}
When I use JDK 1.7+ everything works properly, but when I switch into 1.6- it throws javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
My certificates are 2048 encrypted and I also installed JCE Unlimited Strength Jurisdiction Policy
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
Here is full exception if some is interested:
javax.net.ssl.SSLException: Connection has been shutdown:
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1154)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:65)
at
sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
at
sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at
java.io.InputStreamReader.read(InputStreamReader.java:167) at
java.io.BufferedReader.fill(BufferedReader.java:136) at
java.io.BufferedReader.readLine(BufferedReader.java:299) at
java.io.BufferedReader.readLine(BufferedReader.java:362) at
ConnectorTest.main(ConnectorTest.java:45) Caused by:
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:739)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:619)
at
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
at
sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at
java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at
java.io.BufferedWriter.flush(BufferedWriter.java:236) at
java.io.PrintWriter.newLine(PrintWriter.java:410) at
java.io.PrintWriter.println(PrintWriter.java:559) at
java.io.PrintWriter.println(PrintWriter.java:670) at
ConnectorTest.main(ConnectorTest.java:43) Caused by:
java.io.EOFException: SSL peer shut down incorrectly at
com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:321)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:720)
... 13 more
ConnectorTest Line 43 is
System.out.println(in.readLine());
Updated
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1439443814 bytes = { 228, 36, 73, 128, 109, 225, 11, 36, 62, 40, 147, 150, 27, 145, 150, 163, 244, 28, 97, 56, 188, 81, 117, 31, 235, 60, 101, 224 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
Update 2
I just found out that, difference between them are:
Valid from Tue Feb 16 20:07:36 GET 2016 until Thu Feb 16 20:07:36 GET
2017 1.7 Correct
Valid from Tue Feb 16 16:07:36 GMT 2016 until Thu Feb 16 16:07:36 GMT
2017 1.6 Error
After a lot of research, I found out that, there is no way to do this and of course, installing the unlimited policy is also ugly solution. Sun does not recommend us changing policy. The best way to solve that problem is, that always maintain your Java version better then this one. I had to write on 1.5 and had no other chance to simply upgrade system and decided worse but the only solution, that worked, of course. I created some kind of proxy service with Java 1.8 + Wildlfy 8.2 on the same machine with different port of Jboss and call services from there. 1.5 and 1.8 apps communicate with simple soap protocol. Problem "fixed".
Could be that the server does not support the SSL version of the client (client is offering too low SSL version).
Try adding the system property "javax.net.debug=ssl" so you get a better error description into system out. For example:
System.setProperty("javax.net.debug", "ssl");
or add command line parameter:
-Djavax.net.debug=ssl
Why would you want to use older Java? If you must use 1.6 try updating it to the latest patch version.
Using Apache FTPSClient to listFiles(String)....
The aplication crashes sometimes after resuming an SSL Session and then calling sslSocketImpl.startHandshake() from the Apache FTPSClient code.
I set javax.net.debug to print the ssl information...
System.setProperty("javax.net.debug", "all");
And this is what I get.
%% Client cached [Session-3, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
%% Try resuming [Session-3, SSL_RSA_WITH_3DES_EDE_CBC_SHA] from port 4149
*** ClientHello, TLSv1
....
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 28 ......(
main, called closeSocket()
[Mon Aug 30 17:41:52 PDT 2010][class com.smgtec.sff.fileupload.poller.BasicFTPAccess] - Could not list directory: sqjavax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:808)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1107)
at com.smgtec.sff.fileupload.poller.FixedFTPSClient._openDataConnection_(FixedFTPSClient.java:525)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2296)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2269)
Padded plaintext before ENCRYPTION: len = 32
0000: 50 41 at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2046)
at com.smgtec.sff.fileupload.poller.BasicFTPAccess.listFiles(BasicFTPAccess.java:100)
at com.smgtec.sff.fileupload.poller.FTPPoller.addFileForProcessing(FTPPoller.java:67)
at com.smgtec.sff.fileupload.poller.FTPPoller.main(FTPPoller.java:385)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:333)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789)
... 10 more
We also have jscape FTPS client here and it produces the same problem.
I suggest you include some retry logic in your FTPPoller - it looks like the host is closing the connection rather than your code. We used to see occasional connection closed by remote host errors which are best handled by simply retrying.
I solved it like this using SSLSession.invalidate() it seems to work now... although we aren't using FTPS anymore. If this is a true solution there is a problem in Apache commons-net FTPSClient or the FTP Server we are connecting to.
ftp = new FTPSClient()
{
private Socket socket;
protected Socket _openDataConnection_(int command, String arg) throws IOException
{
if (socket != null && socket instanceof SSLSocket)
{
// We have problems resuming cached SSL Sessions. Exceptions are
// thrown and the system crashes... So we invalidate each SSL
// session we used last.
SSLSocket sslSocket = (SSLSocket) socket;
sslSocket.getSession().invalidate();
}
socket = super._openDataConnection_(command, arg);
return socket;
}
};
BTW I believe we were connecting to a FileZilla FTP server. I suspect this fix will cause more network chatter passing back and forth keys/certs and so forth.
We've got here a problem of random disconnections between our Java apps and our PostgreSQL 8.3 server with a "bad record MAC" SSL error.
We run Debian / Lenny on both side. On the client side, we see :
main, WRITE: TLSv1 Application Data, length = 104
main, READ: TLSv1 Application Data, length = 24
main, READ: TLSv1 Application Data, length = 104
main, WRITE: TLSv1 Application Data, length = 384
main, READ: TLSv1 Application Data, length = 24
main, READ: TLSv1 Application Data, length = 8216
%% Invalidated: [Session-1, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
main, SEND TLSv1 ALERT: fatal, description = bad_record_mac
main, WRITE: TLSv1 Alert, length = 24
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLException: bad record MAC
2010-03-09 02:36:27,980 WARN org.hibernate.util.JDBCExceptionReporter.logExceptions(JDBCExceptionReporter.java:100) - SQL Error: 0, SQLState: 08006
2010-03-09 02:36:27,980 ERROR org.hibernate.util.JDBCExceptionReporter.logExceptions(JDBCExceptionReporter.java:101) - An I/O error occured while sending to the backend.
2010-03-09 02:36:27,981 ERROR org.hibernate.transaction.JDBCTransaction.toggleAutoCommit(JDBCTransaction.java:232) - Could not toggle autocommit
org.postgresql.util.PSQLException: An I/O error occured while sending to the backend.
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:220)
at org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionCommand(AbstractJdbc2Connection.java:650)
at org.postgresql.jdbc2.AbstractJdbc2Connection.commit(AbstractJdbc2Connection.java:670)
at org.postgresql.jdbc2.AbstractJdbc2Connection.setAutoCommit(AbstractJdbc2Connection.java:633)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.jdbc.datasource.SingleConnectionDataSource$CloseSuppressingInvocationHandler.invoke(SingleConnectionDataSource.java:336)
at $Proxy17.setAutoCommit(Unknown Source)
at org.hibernate.transaction.JDBCTransaction.toggleAutoCommit(JDBCTransaction.java:228)
at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:220)
at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:196)
at org.hibernate.ejb.TransactionImpl.rollback(TransactionImpl.java:85)
at org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:482)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:823)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:800)
at org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:339)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:635)
...
Caused by: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: bad record MAC
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1255)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1267)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:43)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at org.postgresql.core.PGStream.flush(PGStream.java:508)
at org.postgresql.core.v3.QueryExecutorImpl.sendSync(QueryExecutorImpl.java:692)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:193)
... 22 more
Caused by: javax.net.ssl.SSLException: bad record MAC
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1569)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:850)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:135)
at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:104)
at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:186)
at org.postgresql.core.PGStream.Receive(PGStream.java:445)
at org.postgresql.core.PGStream.ReceiveTupleV3(PGStream.java:350)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1322)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:194)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:254)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1808)
at org.hibernate.loader.Loader.doQuery(Loader.java:697)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.loadCollection(Loader.java:2015)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:59)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:587)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:83)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1743)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:366)
at org.hibernate.collection.PersistentSet.add(PersistentSet.java:212)
...
the cypher suites SSL_RSA_WITH_3DES_EDE_CBC_SHA or SSL_RSA_WITH_RC4_128_SHA were used.
We tried on the client side :
the OpenJDK package
the sun JDK package
the sun tar package
the libbcprov-java package
the PostgreSQL driver 8.3 instead of 8.4
On the server side we see :
2010-03-01 08:26:05 CET [18513]: [161833-1] LOG: SSL error: sslv3 alert bad record mac
2010-03-01 08:26:05 CET [18513]: [161834-1] LOG: could not receive data from client: Connection reset by peer
2010-03-01 08:26:05 CET [18513]: [161835-1] LOG: unexpected EOF on client connection
the error type seams to be SSL_R_SSLV3_ALERT_BAD_RECORD_MAC.
the SSL layer is configured with :
ssl_ciphers = 'ALL:!ADH:!LOW:!EXP:!MD5:#STRENGTH'
and on the server side we changed the cipher suites to :
'ALL:!SSLv2:!MEDIUM:!AES:!ADH:!LOW:!EXP:!MD5:#STRENGTH'
but none of these changes fixed the problem. Suggestions appreciated !
I don't know how Java deals with it, but a number of vendors recently released security updates that disabled SSL renegotiation support, sometimes in broken ways. Some have been fixed since, some not. This could be your problem, in case this is something that happens after a fairly large amount of data (512Mb by default) has passed over a connection. Since you're likely using a connection pool, that seems quite possible.
In PostgreSQL 8.4.3 (due out this week), we have added a configuration parameter that lets you disable SSL renegotiation completely - that might be worth a try. (there are also new versions in the previous trees (like 8.3) that contain this feature)