Dropwizard reporting incorrectly enabled HTTPS protocols

[shahr]

The deafult Dropwizard behaviour seems to enable TLSv1.1 (despite the documentation stating that TLSv1.1 is in the excludedProtocols by default). It does also not match what is bieng logged by Dropwizard.

Steps to reproduce (using Dropwizard v.2.0.13):

1. Create a simple Dropwizard application. Add HTTPs configuration (do not set any values for supportedProtocols and excludedProtocols)
2. Start up server. Server logs indicate:
   io.dropwizard.jersey.HttpsConnectorFactory: Enabled protocols: [TLSv1.2, TLSv1.3] io.dropwizard.jersey.HttpsConnectorFactory: Disabled protocols: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1]
3. curl --tlsv1.1 https://localhost - this actually works (using curl version: libcurl/7.29.0, NSS/3.44)

Further proof:

• Add a ServerLifecycleListener with the serverStarted method as: server -> LOGGER.info(Arrays.asList(server.getBean(SslContextFactory.class).getSelectedProtocols()))
• This will print TLSv1.1, TLSv1.2 and TLSv1.3

Notes:

• If I explicitly set excludedProtocols with TLSv1.1, it gets disabled.
• TLS 1.1 may still fail due to the default cipher suites prevent an algorithm agreement - but that is besides the point - the protocol is still enabled.

[joschi]

@shahr Thank you very much for reporting this!

That's an interesting find. We do indeed add TLSv1.1 to the list of excluded protocols:
https://github.com/dropwizard/dropwizard/blob/v2.0.14/dropwizard-jetty/src/main/java/io/dropwizard/jetty/HttpsConnectorFactory.java#L289-L290

This list of excluded protocols is then set on the SslContextFactory when it's being created:
https://github.com/dropwizard/dropwizard/blob/v2.0.14/dropwizard-jetty/src/main/java/io/dropwizard/jetty/HttpsConnectorFactory.java#L811-L813

A test like the following also dumps the correct selection of included and excluded protocols:

@Test
public void testDefaultExcludedProtocols() throws Exception {
  HttpsConnectorFactory factory = new HttpsConnectorFactory();
  factory.setKeyStorePassword("password"); // necessary to avoid a prompt for a password

  SslContextFactory sslContextFactory = factory.configureSslContextFactory(new SslContextFactory.Server());
  sslContextFactory.dump(System.out, "");
}

Output:

Server@13526e59[provider=null,keyStore=null,trustStore=null] - STOPPED
+> trustAll=false
+> Protocol Selections
|  +> Enabled size=2
|  |  +> TLSv1.2
|  |  +> TLSv1.3
|  +> Disabled size=4
|     +> SSLv2Hello - ConfigExcluded:'SSL.*'
|     +> SSLv3 - ConfigExcluded:'SSL.*' JVM:disabled
|     +> TLSv1 - ConfigExcluded:'TLSv1'
|     +> TLSv1.1 - ConfigExcluded:'TLSv1\.1'

And yet, any SslEngine created by this SslContextFactory will show TLSv1.1 in SslEngine#getEnabledProtocols(). 🤔

[shahr]

Yes, thank you for verifying - I was surprised by this because a cursory look at the code seemed like everything was configured correctly. For context, I was creating a verification that ensured servers were only using TLSv1.2 and when testing this I oddly discovered that the 1.1 protocol was still enabled.

I'm a bit time bound at the moment, but will try take a look into this a bit deeper to try understand where TLS 1.1 is bieng re-enabled.

[shahr]

As a side note - is it worth changing the logging to use SslEngine#getEnabledProtocols() (including cipher suites) to represent the real SSLEngine configuration?

[joschi]

This seems to be rooted in an inconsistency between SslContextFactory#dump() and which protocols are really selected in the built SSLContext and SSLEngine instances.

I've filed a bug report with the Jetty project for this:
jetty/jetty.project#5531

[shahr]

This explains why it seemed to be behaving correctly when I explicitly set the excludedProtocol list without using the regexp.

Thank you.