Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] SSL breakage in 9.3.7.v20160115?
The changes for SLOTH apply the configuration exclusions for "^.*_RSA_.*_(MD5|SHA|SHA1)$" ciphers.
This eliminates the RSA + (MD5 or SHA or SHA1) ciphers from being used.

Something that future versions of Java will do at the JVM level.
(This change will likely show up in $JAVA_HOME/jre/lib/security/java.security like the other banned SSL/TLS ciphers, protocols, and certificates)

There are many production systems using Jetty 9.3.7 already, and you are the first one to report this being an issue.

If you feel this is invalid for your configuration, you can always reconfigure the SslContextFactory to suit your needs.
But the error you are seeing is highly unlikely to be related to this default configuration change.

One website running 9.3.7.v20160115 - https://webtide.com/
The SSL report for it (Score: A) -> https://www.ssllabs.com/ssltest/analyze.html?d=webtide.com





Joakim Erdfelt / joakim@xxxxxxxxxxx

On Wed, Jan 20, 2016 at 1:11 PM, David Kellum <dek94@xxxxxxxxxxxxx> wrote:
My integration tests started failing when I upgraded to 9.3.7.v20160115 from 9.3.6.  SSL connections are failing. Turning debug logging on, the cause appears to be this:

javax.net.ssl.SSLHandshakeException: no cipher suites in common

My testing is using pretty generic (ruby) SSL access, default client settings.

Now some conjecture—looking through the available release notes:

485714 Update SSL configuration to mitigate SLOTH vulnerability

But the bugzilla issue sounds incomplete:
…and despite the claim that the change was reverted, this at least made it into the release:
Please advise? Thanks.

—David




_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Back to the top