My client java -version is 1.7.0_85 and the server version is lower than that. the communication takes place fine when the client was a version lower. But since the update i get the handshake_failure error. Upon firing openssl command for the server it said that the cipher was RC4-SHA in the latest update RC4 were disabled by default. Cant update the server not in my control, how should i establish the communication using properties in the java.security
file
You can look at the value for the jdk.tls.disabledAlgorithms parameter in java.security and remove RC4 from that values list.
Rather than retain this change and make clients insecure, it would be a better option if a parallel thread is opened with the server operator(s) to have them fix their SSL setup.
I'd like to repeat what the JRE release notes states about the usage of RC4 (emphasis mine).
Area: security-libs/javax.net.ssl
Synopsis: Prohibit RC4 cipher suites
RC4 is now considered as a compromised cipher. RC4 cipher suites have
been removed from both client and server default enabled cipher suite
list in Oracle JSSE implementation. These cipher suites can still be
enabled by SSLEngine.setEnabledCipherSuites() and
SSLSocket.setEnabledCipherSuites() methods.
See JDK-8077110 (not public).
Related
I was trying to update my project SDK from JDK 10 to 11. However, when my program tries to connect to my MySQL server (currently hosted on my local machine) I get a javax.net.ssl.SSLException.
I see there are some changes to SSL in JDK 11 but I don't know what they mean or how to fix my program:
security-libs/javax.net.ssl ➜ Disabled all DES TLS Cipher Suites
DES-based TLS cipher suites are considered obsolete and should no
longer be used. DES-based cipher suites have been deactivated by
default in the SunJSSE implementation by adding the "DES" identifier
to the jdk.tls.disabledAlgorithms security property. These cipher
suites can be reactivated by removing "DES" from the
jdk.tls.disabledAlgorithms security property in the java.security file
or by dynamically calling the Security.setProperty() method. In both
cases re-enabling DES must be followed by adding DES-based cipher
suites to the enabled cipher suite list using the
SSLSocket.setEnabledCipherSuites() or
SSLEngine.setEnabledCipherSuites() methods.
Note that prior to this change, DES40_CBC (but not all DES) suites
were disabled via the jdk.tls.disabledAlgorithms security property.
EDIT:
Ok, I figured out a solution. I wasn't aware that I could add useSSL=false to my database url. I did that and everything works fine!
In my case I was never using SSL (as I was connecting to a MySQL server on my local machine). In JDK 10 this worked fine, but in JDK 11 I needed to add useSSL=false to my database url which solved the problem.
I have https integration with two host server and I am using java 1.6 and provided cipher using the -Dhttp.ciphers list. we have added Strong cipher first and then added the weaker once. Assuming the order is been followed when we make the SSL connection.
What i observed in the SSL debug log whenever java application is making the connection to host A
Cipher list order is maintain as given in -D option in client Hello message.
Here we are using httpsURLconnection to make a connection.
But when we make the SSL connection to host B cipher list in client hello message is getting changed. Weak cipher is coming before Strong cipher and as a result weak cipher is selected by the Server host B. Here we are making an use of Apache Default httpclient 3.1 to make https connection.
Any idea about why the order of weak ciphers is getting changed ?
I want to record things like client sent tls version, server preferred version, server preferred cipher suite in JSSE. how to do this?
Note that I can only use Java code to do this.Parsing log files are not accepted.
You can add -Djavax.net.debug=all flag to your java execution string and it will dump all that info into the console.
http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
The only way this information is available is via the javax.net.debug system property. If you can't parse that output all you can get is the data in the resulting SSLSession, which consists of what the negotiated protocol and cipher suite were, and the peer certificates. You can also have a look at your own SSLSocket's enabled protocols and cipher suites, but I don't see where it's going to get you.
In an attempt to harden my ssl server I have inadvertently broken a third party integration. They need Java 7u25 support in our SSL config and now we apparently do not have it with this config.
ssllabs.com says we have "Java 7u25 Protocol or cipher suite mismatch"
we have configured ssl.conf
# SSL Protocol support:
SSLProtocol -SSLv2 -SSLv3 -TLSv1 +TLSv1.1 +TLSv1.2
# SSL Cipher Suite:
SSLCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-RSA-AES256-SHA384:
ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES128-SHA256:
ECDHE-ECDSA-AES128-SHA256:
AES128-GCM-SHA256:
AES256-GCM-SHA384:
AES128-SHA256:
AES256-SHA256:
AES:
!aNULL:
!eNULL:
!EXPORT:
!DES:
!RC4:
!MD5:
!PSK:
!aECDH:
!EDH-DSS-DES-CBC3-SHA:
!EDH-RSA-DES-CBC3-SHA:
!KRB5-DES-CBC3-SHA
(formatting of cipher suites in ssl.conf is all in one line without spaces; it was changed one per line in this post for readability)
Thank you
By default Java 7 needs TLSv1 support which you've disabled. Re-enable it and you might be able to use that AES cipher depending what that corresponds to, but it probably can't use the SHA256 or SHA384 ones (again in default mode).
Best to run your site through ssllabs.com again and then compare the ciphers available to the Java 7 list: https://www.ssllabs.com/ssltest/viewClient.html?name=Java&version=7u25
Btw Java 7 can support TLSv1.1 and TLSv1.2 but not by default (see here: https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html) and have seen people struggle to get them working.
How can I obtain a list of ciphers supported by a remote server via a Java JSSE environment.
I want to get a list of weak ciphers supported by the remote server, so that they can be fixed.
I am using SSLSocket, which has a method called getSupportedCipherSuites, but this method returns ciphers that are supported by the client, not a remote server.
You can't get a list of the supported cipher suites, but you can get the server's enabled weak cipher suites, as follows:
Enable all the weak cipher suites at your client, and none of the strong ones.
Have your client connect and call startHandshake().
If that succeeds, the server has chosen a weak cipher suite, which you can get from the SSLSession. Remove that from the enabled cipher suites and repeat.
All the handshakes at (2) which succeed indicate that the corresponding weak cipher suite is enabled at the server. If there are zero, good. Otherwise print out the succeeding cipher suites and act accordingly.
You can try gnutls-cli