Dropwizard 1.0 TLS ChecklistPublished on:
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 (
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)
validatePeers: falseare 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.
validateCertsis 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
These enabled options may cause the dreaded cryptic error messages:
the trustAnchors parameter must be non-empty
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
[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
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.
If you'd like to leave a comment, please email firstname.lastname@example.org