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.
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 need to Configure TLSv1.2 in WebSphere 7.0.0.45 (Java 1.6 SR 16 FP60). So I configured the Dynamic outbound configuration in WAS and Configured the SSL Configuration by following the steps in the links
https://developer.ibm.com/answers/questions/244958/how-do-i-configure-step-by-step-dynamic-outbound-e/
And I added the Custom property in Global Security and JVM Custom property
com.ibm.websphere.ssl.include.ECCiphers = true
After configuration I am able to Establish the connection with TLSv1.2 for
https://fancyssl.hboeck.de/ which only support TLSv1.2.
But I can't establish a connection for strong Cipher suite sites like
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003C)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009D)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC027)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC028)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC02F)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030)
It's throwing an
Fatal Error : Handshake Failure in ClientHello
I tried downloading the Unrestricted IBM Java policy files too. Still no luck
Please suggest me some best practice to configure TLSv1.2 in WAS7.0 and configure the Strong Cipher Suites to resolve the issue.
I opened a PRM with IBM for the same problem. After several iterations, I have not been able to solve it yet.
IBM suggested to me to install the unrestricted policy file. After doing it I could install the ssl certificate doing a "Retrieve from port" from the was admin console. But the problem continue while trying to connect from the appl.
You may tray the same to see if it works for you following the steps here:
https://developer.ibm.com/answers/questions/178395/how-do-i-install-the-unrestricted-policy-files-in.html
I am trying to establish connection over ssl. The client has only enabled TLSv1.0 and supports limited number of cipher suites mentioned below:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
I am running the server on Java 1.8.0_151-b12. When client is requesting to establish SSL connection I see following exception on server console:
https-jsse-nio-9080-exec-8, fatal: engine already closed.
Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common
I have tried the Java Cryptography Extension (JCE) Unlimited Strength and it didn't worked.
Is there a way to enable these cipher suite in Java v1.8?
Thank you in anticipation.
#dave_thompson_085 Thanks for looking into my query. I was able to resolve this problem and here are the steps,
Print all Java DefaultCipherSuites & SupportedCipherSuites and look for the one needed.
If found then add the cipher suite name on SpringBoot configuration file as described here,
How to set up SSL (TLS) / HTTPS on Spring Boot using AES-256?
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).
I have configured Jetty embedded server to include/exclude some protocols and cipher suites. Is there way to report those on working service? I think about something like getSupportedCipherSuites() and getSupportedProtocols() of javax.net.ssl.SSLServerSocket but for Jetty server objects. My code already shows things from configration:
HTTPSPDYServerConnector SSLconnector = new HTTPSPDYServerConnector(server, sslContextFactory);
SSLconnector.setPort(PortHTTPS);
...
server.setConnectors(new Connector[] { SSLconnector });
...
showInfo(sslContextFactory.getIncludeCipherSuites());
showInfo(sslContextFactory.getExcludeCipherSuites());
showInfo(sslContextFactory.getIncludeProtocols());
showInfo(sslContextFactory.getExcludeProtocols());
...
server.start();
Now I want to see what protocols and cipher suites are available for clients.
EDIT (more info):
My environment can work with those protocols:
SSLv2Hello
SSLv3
TLSv1
TLSv1.1
TLSv1.2
This is result of SSLServerSocket.getSupportedProtocols() that is reported by http://www.java2s.com/Code/JavaAPI/javax.net.ssl/SSLServerSocketgetSupportedProtocols.htm
But with Jetty environment I do not know how to get such list. I excluded some protocols by calling
sslContextFactory.addExcludeProtocols() (I disabled TLSv1.2 because of Chrome bug ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED in Google Chrome)
How can I get list of protocols available (not excluded) for Jetty server?
I suppose that for my environment such result will be:
SSLv2Hello
SSLv3
TLSv1
TLSv1.1
(TLSv1.2 was disabled)
I've just gone through a similar problem.
The way Jetty works, it instantiates a default SSLEngine and then it applies exclusions and other preferences. By default, Jetty 9.4 excludes the following protocols:
this.addExcludeProtocols("SSL", "SSLv2", "SSLv2Hello", "SSLv3");
Ciphers are managed in a similar way, but you can uge regexes. By default, Jetty 9.4 excludes the following:
this.setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
this.addExcludeCipherSuites("^TLS_RSA_.*$");
this.addExcludeCipherSuites("^SSL_.*$");
this.addExcludeCipherSuites("^.*_NULL_.*$");
this.addExcludeCipherSuites("^.*_anon_.*$");
If you call the include/exclude methods yourselp, you will have to deal with the particular sequence of processing that Jetty performs, which is potentially confusing. So I recommend you use the setter methods first with empty arrays, in order to clear anything Jetty put in place by default, and then add your preferred items. Example:
// empty the collections, we don't need no education
sslContextFactory.setExcludeProtocols(new String[]{});
sslContextFactory.setExcludeCipherSuites(new String[]{});
// tell me what you want, what you really really want
sslContextFactory.setIncludeProtocols("TLSv1","TLSv1.1","TLSv1.2");
sslContextFactory.setIncludeCipherSuites(omgIveNeverSeenSuchABigArrayOfCiphers);
If you need a list of ciphers that a specific Java client supports, run that client with -Djavax.net.debug=ssl:handshake:verbose and look for ClientHello messages.