There are multiple drivers to get on OpenSSL-1.1 sooner rather than later:
- Sec cleanup in 1.1's code quality -> potentially fewer future bugs.
- Supports chacha20-poly1305 out of the box without the cloudflare patch we're using for 1.0.2
- Supports x25519 for ECDHE key exchange, including with mismatched ECDSA curve (e.g. our prime256v1 ECDSA cert for auth + x25519 ECDHE for key exchange)
- Removal of a lot of junk legacy stuff, including all of SSLv2.
- Lots of other misc improvements in the ChangeLog of course
With the first public release having happened back on August 25, we're now in a position where we could theoretically get this working quickly. I already have a test build of nginx-1.11 + openssl-1.1.0 on pinkunicorn and it seems to function as expected for TLS termination.
These are the potential holdups/issues:
- I'm still a little leery of the newness of this first major 1.1 release. We may want to wait a little longer to see if there's a first wave of public bug reports and fixups first.
- The ChaPoly support lacks the older non-RFC draft-mode that the cloudflare patch we're running today has. I think this is basically-acceptable today if not ideal, and only gets more-acceptable with each passing day as more Chrome installs update. Current stats on the draft chapoly negotiations are ~20% of all chapoly (~4.5% of all) and declining.
- The default openssl-1.1 build includes 3DES in the definition of "weak ssl ciphers" that are disabled-by-default at compile time, alongside RC4. This is a decision that was made at the last minute before 1.1's release, in response to the SWEET32 birthday attack stuff. We can re-enable them with a debian/rules patch that turns both 3DES and RC4 back on, and I've done so in my latest experimental patch. I'm not 100% sure that's the right thing to do, but on the balance of things it seems too early to abruptly deny access to IE-on-XP in production at this point.
- Stock nginx-1.11.3 basically supports OpenSSL-1.1, but has some minor incompatibilities with the official OpenSSL-1.1.0 release (which came after it). Current nginx master has fixups for this (applied to our experimental package) that should land in 1.11.4, but it would be nicer to wait for the real 1.11.4 release.
- While libssl1.1 can co-exist with libssl1.0 on the same machine, there's only one /usr/bin/openssl. I've checked that our ocsp stapling scripts (which invoke the openssl CLI) seem to still work with the new CLI tools, but we may have several other uses of the CLI tools that could face compatibility issues here that need addressing first (e.g. stuff in our sslcert puppet module). A possible middle path here is to build nginx against libssl1.1 and only deploy the library (not the CLI) for jessie in general.
- The debian packaging of nginx-1.11 includes some 3rd-party modules that basic upstream nginx doesn't. Two of these modules (upstream_fair, and http_lua) do not build correctly against 1.1.0 libssl headers. I've disabled both in our experimental build as our cache terminators don't use them, but @yuvipanda pointed out that some labs uses of nginx do use the Lua module. For all I know there may already be upstream fixes for this at the 3rd party module sources that haven't yet trickled through the debian nginx packaging, or local fixups might be trivial.