We’re seeing an SSL handshake error when testing out our Logstash + http drain:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
I’m wondering if there are any special configuration steps we’re missing.
Context: We have a Logstash instance (running the version of that Aptible published on Github) with an http output plugin configured to send a POST request to an endpoint on one of our apps. But I’m running into an SSL handshake error when trying to make this POST request . We’re running on an Alpine base image.
We’ve also made one small modification: the addition of RUN apk update && apk upgrade to the Dockerfile in order to update the dependencies for alpine:3.3 so that we can run openssl in the container.
Before jumping into what should be changed, a little background is needed:
There is a vulnerability in SSLv3 that affects AES-CBC called POODLE.
There are two main ways to mitigate POODLE:
Disable SSLv3
Disable AES-CBC ciphers
Now, there’s nothing inherently wrong about AES-CBC. In fact, AES-CBC is entirely fine if you’re using it over TLS 1.x. Unfortunately, you can’t instruct OpenSSL to allow AES-CBC over TLS 1.x but reject it over SSLv3.
So, if you want to support SSLv3 without being vulnerable to POODLE, you need to disable AES-CBC. This is what we do by default because supporting SSLv3 (unless you set DISABLE_WEAK_CIPHER_SUITES) allows for greater compatibility (usually — more on that below).
Now, this typically leaves your Nginx server configuration with two main “groups” of ciphersuites enabled:
RC4-based ciphersuites
AES-GCM-based ciphersuites
For your reference, the exact list should be more or less:
Allow RC4 in Java. This should be possible via a system property (https://bugs.openjdk.java.net/browse/JDK-8141050) and I’m going to look into whether we can do that in the image directly. NB: Not actually available right now because Alpine hasn’t packaged the Java version that introduces that system property yet
Disable SSLv3 on the server. This means we can allow AES-CBC over TLS 1.x, which Java can then use to connect. This is why setting DISABLE_WEAK_CIPHER_SUITES makes things work (which I grant is quite counter-intuitive).