Dropwizard 1.0 TLS Checklist

• Follow Jetty’s instructions on creating a certificate (either self signed or generating a CSR). Tip: when securing a key with a password via the PKCS12 mechanism, ensure that the keystore and PKCS12 file share the same password.

• Stop reading when you hit the Configuring the Jetty SslContextFactory

• You should now have a keystore that you can play around with keytool. The Most Common Java Keytool Keystore Commands

• Let’s update our dropwizard configuration to reference our keystore (my-server.jks):

server:
  applicationConnectors:
    - type: https
      port: 9443
      keyStorePath: 'my-server.jks'
      keyStorePassword: 12bucklemyshoe
      validateCerts: false
      validatePeers: false

  adminConnectors:
    - type: https
      port: 9444
      keyStorePath: 'my-server.jks'
      keyStorePassword: 12bucklemyshoe
      validateCerts: false
      validatePeers: false

• For Dropwizard 1.0 (but not 1.1) validateCerts: false and validatePeers: false are required. The behavior of these settings have changed from earlier versions of Dropwizard, due to a Jetty upgrade. If you would like to enable validatePeers, then create a trust store with just the root certificate of your chain, so if the certificate is self signed, it would be the certificate itself. validateCerts is broken, so shouldn’t be used. By default, Jetty even has these options disabled, so Dropwizard may reevaluate the defaults. There should be no reservations about setting them to false

These enabled options may cause the dreaded cryptic error messages:

the trustAnchors parameter must be non-empty

and

unable to find valid certification path to requested target

• Validate TLS configuration using the comprehensive sslyze. It’ll let you know the protocols and a subset of cipher suites supported by the server.

• The protocols and cipher suites have changed since Dropwizard 0.9 to be more strict (and secure) by default, thanks to Jetty 9.3. If you need to enable old clients (Java 7, internet explorer, etc), it’s done through the configuration:

  server:
    applicationConnectors:
      - type: https
        port: 9443
        excludedCipherSuites:
          - SSL_RSA_WITH_DES_CBC_SHA
          - SSL_DHE_RSA_WITH_DES_CBC_SHA
          - SSL_DHE_DSS_WITH_DES_CBC_SHA
          - SSL_RSA_EXPORT_WITH_RC4_40_MD5
          - SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
          - SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
          - SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

        # snip

• For more information on the changes, see the corresponding dropwizard issue

Not a checklist item, but an interesting observation. According to both the official Jetty documentation and blog:

[S]calable deployments have offloaded SSL/TLS to the load balancer and the pure java server has been more than sufficient to receive the unencrypted traffic from the load balancer

and

Typical website deployments have Apache (or Nginx) configured as reverse proxy to talk to one or more backend Jetty instances.

I’ll wager for the average reader this will be premature optimization. If 2,000 requests a second is a fine number then you’ll be fine using the native SSL implementation instead of a reverse proxy. It also sounds like Jetty 9.4 will improve on the default implementation.