Only TLS 1.2 Supported

[nickbabcock]

By default Jetty seems to support TLS 1.2 with no way to configure this.

• Download jetty distribution 9.3.11.v20160721
• java -jar $JETTY_HOME/start.jar --add-to-startd=https
• Run sslyze (or your favorite ssl analyzer) and notice that only TLS 1.2 is supported
• edit ${jetty.base}/jetty-distribution-9.3.11.v20160721/etc/jetty-ssl-context.xml and add

<Call name="setIncludeProtocols">
  <Arg>
    <Array type="String">
      <Item>TLSv1</Item>
      <Item>TLSv1.1</Item>
      <Item>TLSv1.2</Item>
    </Array>
  </Arg>
</Call>
<Call name="addExcludeCipherSuites">
  <Arg>
    <Array type="String">
      <Item>.*NULL.*</Item>
      <Item>.*RC4.*</Item>
      <Item>.*MD5.*</Item>
      <Item>.*DES.*</Item>
      <Item>.*DSS.*</Item>
    </Array>
  </Arg>
</Call>

• Restart jetty and notice that this doesn't change anything (though mistyping a protocol will make jetty print a warning, so jetty is picking up the protocols)
• Try and disable TLS 1.2

  <Call name="setIncludeProtocols">
    <Arg>
      <Array type="String">
        <Item>TLSv1</Item>
        <Item>TLSv1.1</Item>
      </Array>
    </Arg>
  </Call>
  <Call name="setExcludeProtocols">
    <Arg>
      <Array type="String">
        <Item>TLSv1.2</Item>
      </Array>
    </Arg>
  </Call>

• Jetty will start but will refuse to complete any request with an error detailing that no cipher suite in common

I'm assuming this is a bug as the documentation states that

Both TLS v1.0 and SSL v3 are no longer supported by default.

Which leads me to believe that TLS v1.1 would be on by default and that TLS v1.0 could be enabled through configuration.

Originally reported dropwizard/dropwizard#1700

EDIT: env info:

java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"

EDIT: after additional searching: I've come across a post that mentions a post on the mailing list saying that this behavior is desired. If this is the case, this issue may be closed at the team's discretion, but the docs that I linked to must be updated to note that only TLS 1.2 is supported without specifying excludeCipherSuites

EDIT: For those that want Jetty 9.3.7+ but want TLS 1 and TLS 1.1, which Jetty has excluded known vulnerable cipher suites, I can confirm that setting the excluded cipher suites to the following list works.

  <Call name="setExcludeCipherSuites">
    <Arg>
      <Array type="String">
        <Item>SSL_RSA_WITH_DES_CBC_SHA</Item>
        <Item>SSL_DHE_RSA_WITH_DES_CBC_SHA</Item>
        <Item>SSL_DHE_DSS_WITH_DES_CBC_SHA</Item>
        <Item>SSL_RSA_EXPORT_WITH_RC4_40_MD5</Item>
        <Item>SSL_RSA_EXPORT_WITH_DES40_CBC_SHA</Item>
        <Item>SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA</Item>
        <Item>SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA</Item>
      </Array>
    </Arg>
  </Call>

[sbordet]

@WalkerWatch can you update the documentation ?

The status is the following: we had first disabled SSLv3 and TLS 1.0 because they were found vulnerable, and updated the docs accordingly.
Time passed, and more ciphers were found vulnerable, so they were excluded by default.
Turns out that now all the ciphers that were valid for TLS 1.1 are excluded because found vulnerable, which prevents the TLS 1.1 protocol to be chosen by default (it's like having a car that goes on a fuel that you can't find anymore - you can choose the car (TLS 1.1) but you have no fuel to make it run (ciphers), and that's what the original issue reporter also found); only by explicitly re-enabling vulnerable ciphers TLS 1.1 can be chosen (as reported by the original issue reporter in the last edit).
Therefore we are left with only TLS 1.2 be a negotiable protocol, and of the ciphers that TLS 1.2 defines, only few are left and non vulnerable.

The documentation should be updated to say that also TLS 1.1 is excluded by default; correct the ciphers that are excluded by default (the current ones in the documentation are incorrect; perhaps we should directly reference the code, rather than copy the list in the documentation - asciidoc allows to reference just a code snippet using tags).

[joakime]

The reason TLS/1.1 and TLS/1.0 are not available to you, is because there's no ciphers that support TLS/1.1 and TLS/1.0 available on your system.

Those protocols are not disabled, and on some system configurations you can still use TLS/1.1 as there are some Cipher Suites left in the TLS/1.1 camp still available.

While its true that on an unconfigured Oracle OpenJDK, there will be no ciphers available to service TLS/1.1, there are reports that alternative cryptographic configurations (unlimited strength JCE, Bouncy Castle, etc) do allow TLS/1.1 and TLS/1.0 to function without altering the JVM level security.properties.

[nickbabcock]

Good point, I will have to report back if I can replicate the following stackoverflow answer.

But that is a Java only solution. I do find it peculiar that I am unable to get OpenSSL 1.0.2e to successfully negotiate a TLS/1.1 connection with the default excluded cipher suites. openssl s_client -prexit -tls1_1 -connect <host>:<port> fails to return the server's certificate.

[joakime]

There's no cipher suites in common between Java and openssl.

You'll have to address the java side to make TLS/1.1 function for you.

Option #1: Configure Jetty's SslContextFactory to expose the vulnerable ciphers you are needing

This requires you to redefine the .setExcludedCiphers() to the set that applies to you.

Option #2: Configure the Java JVM to not exclude the specific TLS/1.1 ciphers suites you need

Option #3: Configure the Java Runtime for more Cipher suites

This can sometimes be as simple as installing the unlimited strength JCE, or using alternative crypto providers like Bouncy Castle.

Note: The use of these vulnerable cipher suites is to be considered a short term solution, as they are highly likely to be removed everywhere once the TLS/1.3 spec and implementations are deployed. This is because the current iteration of the (unfinished) TLS/1.3 spec is going to ban those cipher suites from existing for any TLS support level, with no option to enable them (as they wont exist on the systems anymore).

[nickbabcock]

Thanks for the info. I'm very much satisfied with the solutions presented. I'm closing this issue.

Through this exercise, I learned that I shouldn't treat openssl as the end-all-be-all for supported suites 😛