Jetty.project: Exclude TLS_RSA_* ciphers by default

Created on 15 Aug 2018 · 20Comments · Source: eclipse/jetty.project

ssllabs.com caps sites to grade B if they support TLS_RSA_* ciphers, because they don't support forward secrecy, see https://blog.qualys.com/ssllabs/2018/02/02/forward-secrecy-authenticated-encryption-and-robot-grading-update.

We already exclude few weak/insecure ciphers by default:
https://github.com/eclipse/jetty.project/blob/d5fc0523cfa96bfebfbda19606cad384d772f04c/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java#L215

The problem is whether we want to be really strict by default (those currently excluded won't be enough to get grade A on ssllabs.com so we would need to exclude a lot more) affecting both standalone and embedded usages, or we leave the default configuration as is, moving the responsibility of a stronger cipher selection to users.
A too strict setting by default in the SslContextFactory constructor may result in no cipher suites for people using an old JDK version (as the JDK may not have the more recent ciphers and we exclude all that it provides).

@joakime @gregw @janbartel @jmcc0nn3ll thoughts?

Enhancement Security

Source

sbordet

Most helpful comment

I'll go with the final exclusion list as the following ...

// Exclude weak / insecure ciphers
setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
// Exclude ciphers that don't support forward secrecy
addExcludeCipherSuites("^TLS_RSA_.*$");
// Exclude SSL ciphers (that are accidentally present due to Include patterns)
addExcludeCipherSuites("^SSL_.*$");
// Exclude NULL ciphers (that are accidentally present due to Include patterns)
addExcludeCipherSuites("^.*_NULL_.*$");
// Exclude anon ciphers (that are accidentally present due to Include patterns)
addExcludeCipherSuites("^.*_anon_.*$");

joakime on 24 Aug 2018

👍2

All 20 comments

I have updated our website by changing the jetty-ssl-context.xml configuration, exclusing TLS_RSA_* ciphers.

sbordet on 15 Aug 2018

I say we add the exclusion and document it, aka ...

// Exclude weak / insecure ciphers
setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
// Exclude ciphers that don't support forward secrecy
setExcludeCipherSuites("^TLS_RSA_.*$");

joakime on 15 Aug 2018

@gregw this is the issue you wanted in 9.4.12

joakime on 23 Aug 2018

So with Java 8u161 JCE unlimited strength Ciphers are now included. (according to 8u151 changelog it was added back then, but can't seem to get it to work)

So we have a grid of tests ...

One axis is Client & versions. Like OpenSSL, Java 8u121, Java 8u161, Java 10.0.1 default, Java 10.0.1 w/JCE unlimited enabled, Java 11+27
Another axis is TLS/1.0, TLS/1.1, TLS/1.2

I can run these tomm and collect the results.

joakime on 23 Aug 2018

We came to the conclusion that we recommend that cipher suites and protocols be specified explicitly, rather than using include/exclude wildcards/regexes. We defer to SSL Labs or Mozilla for those lists.

Maybe they could be moved to a module, thus allowing deployers to specify jetty-tls-super-secure.mod or jetty-tls-super-compatible.mod etc.

Especially as Java versions proliferate, testing gets way harder it seems.

But we also think that the default exclude list for cipher suites should also include NULL, DES, DSS, etc as documented as being "old, insecure, or anonymous". Or maybe that's a feature.

Thanks again.

tomzeller on 23 Aug 2018

@tomzeller actually the intent of this issue is that Jetty out-of-the-box should rate A on ssllabs.com.

If you want "old, weak, vulnerable" ciphers, by all means go and reconfigure Jetty.
If you want "super-secure" ciphers, ditto.

Our reasoning to change the default exclusion pattern was about the default Jetty behavior.
Do you see problems with this approach?

Thanks!

sbordet on 23 Aug 2018

Well, to some sense yes we see a problem. By default NULL is not excluded, for example.

tomzeller on 23 Aug 2018

// Exclude weak / insecure ciphers
setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
// Exclude ciphers that don't support forward secrecy
setExcludeCipherSuites("^TLS_RSA_.*$");

Using the proposed new default exclusions (see above), the resulting "selected cipher suites" is the following.

Cipher | Java 8u121 (default) | Java 8u181 (default) | Java 11+27 (default) | HTTP/2 Cipher Black List
------ | -------------------- | -------------------- | -------------------- | -------------
TLS_AES_128_GCM_SHA256 | - | - | Supported | -
TLS_AES_256_GCM_SHA384 | - | - | Supported | -
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 | Supported | Supported | Supported | Banned
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 | Supported | Supported | Supported | -
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 | - | Supported | Supported | Banned
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 | - | Supported | Supported | -
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 | Supported | Supported | Supported | Banned
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | Supported | Supported | Supported | -
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 | - | Supported | Supported | Banned
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | - | Supported | Supported | -
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | Supported | Supported | Supported | Banned
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | Supported | Supported | Supported | -
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | - | Supported | Supported | Banned
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | - | Supported | Supported | -
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 | Supported | Supported | Supported | Banned
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | Supported | Supported | Supported | -
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 | - | Supported | Supported | Banned
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | - | Supported | Supported | -
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 | Supported | Supported | Supported | Banned
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 | Supported | Supported | Supported | Banned
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 | - | Supported | Supported | Banned
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 | - | Supported | Supported | Banned
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 | Supported | Supported | Supported | Banned
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 | Supported | Supported | Supported | Banned
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 | - | Supported | Supported | Banned
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 | - | Supported | Supported | Banned
TLS_EMPTY_RENEGOTIATION_INFO_SCSV | Supported | Supported | Supported | Banned

joakime on 23 Aug 2018

The problem is that all it takes is a wildcard include by a deployer to pull in the NULL ciphers you're not excluding. That's obviously somewhat "deployer beware" but it's an awfully easy mistake with a pretty catastrophic result. You really, really should be excluding NULL cases.

scantor on 23 Aug 2018

@scantor fair point.

Along those lines we might need/want more excludes ??

// Exclude SSL ciphers
setExcludeCipherSuites("^SSL_.*$");
// Exclude NULL ciphers
setExcludeCipherSuites("^.*_NULL_.*$");
// Exclude anon ciphers
setExcludeCipherSuites("^.*_anon_.*$");

joakime on 23 Aug 2018

👍1

With original proposed default exclude list ...

// Exclude weak / insecure ciphers
setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
// Exclude ciphers that don't support forward secrecy
setExcludeCipherSuites("^TLS_RSA_.*$");

... on a Jetty 9.4.12.RC2 Server running either Java 8u181 or Java 11+27.

Jetty HttpClient 9.4.11 - default SslContextFactory
- Java 8u121 client - connects HTTP/1.1 fine (HTTP/2 not tested)
- Java 8u181 client - connects HTTP/1.1 fine (HTTP/2 not tested)
- Java 11+27 client - connects HTTP/1.1 fine (HTTP/2 not tested)
Jetty HttpClient 9.4.12.RC2 - SslContextFactory with same exclusions as Server ("^.*_(MD5|SHA|SHA1)$" and "^TLS_RSA_.*$")
- Java 8u121 client - connects HTTP/1.1 fine (HTTP/2 not tested)
- Java 8u181 client - connects HTTP/1.1 fine (HTTP/2 not tested)
- Java 11+27 client - connects HTTP/1.1 fine (HTTP/2 not tested)
Java 8u121 HttpsUrlConnection - connects HTTP/1.1 fine
Java 8u181 HttpsUrlConnection - connects HTTP/1.1 fine
Java 11+27 HttpsUrlConnection - connects HTTP/1.1 fine
Java 7u80 HttpsUrlConnection
- Default - cannot connect (no cipher suites in common, Received fatal alert: handshake_failure)
- Enabling TLSv1.2 on command line (-Dhttps.protocols=SSLv3,TLSv1,TLSv1.1,TLSv1.2) - cannot connect (no cipher suites in common, Received fatal alert: handshake_failure)
- Enabling TLS/1.2 in code - cannot connect (no cipher suites in common, Received fatal alert: handshake_failure)

OpenSSL 1.0.2m s_client -tls1 cannot connect using any cipher.
OpenSSL 1.0.2m s_client -tls1_1 cannot connect using any cipher.
OpenSSL 1.0.2m s_client -tls1_2 connects fine with the following cipher suites:

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256

joakime on 23 Aug 2018

Looks like the proposed exclusion list will make TLS/1.0 and TLS/1.1 stop functioning due to lack of cipher suites in common.

joakime on 23 Aug 2018

I'll go with the final exclusion list as the following ...

// Exclude weak / insecure ciphers
setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
// Exclude ciphers that don't support forward secrecy
addExcludeCipherSuites("^TLS_RSA_.*$");
// Exclude SSL ciphers (that are accidentally present due to Include patterns)
addExcludeCipherSuites("^SSL_.*$");
// Exclude NULL ciphers (that are accidentally present due to Include patterns)
addExcludeCipherSuites("^.*_NULL_.*$");
// Exclude anon ciphers (that are accidentally present due to Include patterns)
addExcludeCipherSuites("^.*_anon_.*$");

joakime on 24 Aug 2018

👍2

PR opened at #2855

joakime on 24 Aug 2018

Closing as merged.

joakime on 24 Aug 2018

I have a problem,how to enable these ciphersuites which disabled by jetty9.4.12.
like follows:
SslContextFactory sslContextFactory = new SslContextFactory();
sslContextFactory.setExcludeCipherSuites(
"SSL_DHE_DSS_WITH_DES_CBC_SHA",

some systems must use some weak cipher suites. how to solve it??

vigorSmith on 10 Nov 2018

@vigorSmith you should know that DES is now disabled at the JVM level.
See the OpenJDK Crypto Roadmap -> https://java.com/en/jre-jdk-cryptoroadmap.html

Also, we are going to add a default exclusion for DES within Jetty to follow the OpenJDK Crypto Roadmap (Issue #2889)
Note that Java 12 has plans to not just disable vulnerable cipher suites, but outright remove them. (no possibility to use them, under any configuration)
You should start plans immediately to ensure your clients can use non-vulnerable cipher suites.

Despite that, you can always set the exclusion list on Jetty via the SslContextFactory you are using.
That will address the Jetty side, but for the JVM side, you'll need to modify in the installation of your JVM Runtime to enable DES again.

To modify the SslContextFactory using the proper ${jetty.home} and ${jetty.base} configuration, you can always provide a new XML to manage the SslContextFactory.
See: https://www.eclipse.org/jetty/documentation/current/configuring-ssl.html#configuring-sslcontextfactory-cipherSuites

Also consider some of the advice and example XML files given in comment https://github.com/eclipse/jetty.project/issues/2921#issuecomment-422747678

joakime on 10 Nov 2018

@sbordet "actually the intent of this issue is that Jetty out-of-the-box should rate A on ssllabs.com.
If you want "old, weak, vulnerable" ciphers, by all means go and reconfigure Jetty.
If you want "super-secure" ciphers, ditto.
Our reasoning to change the default exclusion pattern was about the default Jetty behavior.
Do you see problems with this approach?"

Yes, the problem with this approach is that actual systems running jetty in any meaningful fashion at any meaningful scale exist in a heterogenous environment, where cipher-level agreement between all components is a challenge to maintain. jetty is an application and should limit its demand-scope to that realm, the security of the bits it's dealing with after it leaves its context are not its concern. Plainly, it should use the interfaces as provided by the JRE and let administrators tune cipher specs within the JRE as the JRE is designed to do so. There is no such thing as a "weak" cipher because that definition relies entirely upon the context of the environment, and jetty can not envision the full span of the environments it might exist in.

Reference this commit: @joakime https://github.com/eclipse/jetty.project/commit/970efdeb5f737ef5114a684c705a81ba01f69c81

All addExcludeProtocols() and setExcludeCipherSuites() in the trustALL block should be removed.

-SS

scosol on 21 May 2020

trustALL refers to certificates, not protocols or cipher suites.

joakime on 21 May 2020

@joakime yes, you're using the trustAll SslContext (which trust all certs), and within it, you're hardcoding ciphers to exclude. In the current 10.x code:
https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java

202-206:
{
setTrustAll(trustAll);
setExcludeProtocols(DEFAULT_EXCLUDED_PROTOCOLS);
setExcludeCipherSuites(DEFAULT_EXCLUDED_CIPHER_SUITES);
}

126:138:
private static final String[] DEFAULT_EXCLUDED_CIPHER_SUITES = {
// Exclude weak / insecure ciphers
"^._(MD5|SHA|SHA1)$",
// Exclude ciphers that don't support forward secrecy
"^TLS_RSA_.$",
// The following exclusions are present to cleanup known bad cipher
// suites that may be accidentally included via include patterns.
// The default enabled cipher list in Java will not include these
// (but they are available in the supported list).
"^SSL_.$",
"^._NULL_.$",
"^._anon_.*$"
};