Modernize TLS defaults

[PiotrSikora]

Tracking bug for modernization of the TLS defaults, which will span multiple releases:

• - tls: split client/server defaults. #5392 - split client/server defaults (1.10)
• - tls: enable TLS 1.3 on the server-side (non-FIPS builds). #5459 - enable TLS 1.3 on the server-side (1.10)
• - enable TLS 1.3 0-RTT / early data on the server-side (???)
• - Enable TLS 1.3 on the client-side by default #9300 - enable TLS 1.3 on the client-side (???)
• - enable TLS 1.3 0-RTT / early data on the client-side (???)
• - Remove TLS 1.0 and 1.1 from the defaults on the client-side #5395 - remove TLS 1.0 and 1.1 from the defaults on the client-side (1.13)
• - Remove RSA key transport from the defaults on the client-side #5396 - remove RSA key transport from the defaults on the client-side (1.17)
• - Remove SHA-1 cipher suites from the defaults on the client-side #5397 - remove SHA-1 cipher suites from the defaults on the client-side (1.17)
• - Remove TLS 1.0 and 1.1 from the defaults on the server-side #5398 - remove TLS 1.0 and 1.1 from the defaults on the server-side (1.18)
• - Remove RSA key transport from the defaults on the server-side #5399 - remove RSA key transport from the defaults on the server-side (1.18)
• - Remove SHA-1 cipher suites from the defaults on the server-side #5400 - remove SHA-1 cipher suites from the defaults on the server-side (1.18)

Deprecations on the client-side are pretty safe, because virtually all servers are using modern TLS stack (thanks to Heartbleed et al), but I suggest staging changes over multiple releases anyway to avoid changing too many things at once, and to allow people in the community to scream if any of those changes are going to break them, before they happen.

Deprecations on the server-side are slightly more dangerous, because of the sheer amount of outdated clients and devices. Namely, Android didn't have TLS 1.2 enabled by default until Android 5.0 (Lollipop), and older devices still account for ~5% of traffic, which is a bit too high to break by default, IMHO.

[htuch]

@PiotrSikora can you please check in with dependent Google teams via the appropriate channels and confirm that these deprecations make sense?

[moderation]

@PiotrSikora I thought I'd try out the modernization changes you are proposing above. Is the following list of modernized defaults for a non-FIPS build correct?

  "cipher_suites": [
    "[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]",
    "[ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]",
    "ECDHE-ECDSA-AES256-GCM-SHA384",
    "ECDHE-RSA-AES256-GCM-SHA384"
  ]

Current defaults at https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto.html#auth-tlsparameters

[PiotrSikora]

@moderation yes, although I'd recommend that you verify that you don't need any of the cipher suites that you're removing (see /stats queries in the relevant issues - #5396 & #5397 for the outgoing connections and #5399 & #5400 for the incoming connections).

Also, per the opening comment, there is still plenty of outdated clients and devices out there, and changing the defaults on the server-side for the incoming connections might make your services unreachable for them (that's why the the suggested server-side changes are a year away).

[moderation]

Thanks @PiotrSikora. I have control over what is connecting to my private service and so far everything is working. I'm wondering if the TLS 1.3 ciphers should also be specified?

https://github.com/google/boringssl/blob/master/include/openssl/tls1.h#L606-L609

// TLS 1.3 ciphersuites from RFC 8446.
#define TLS1_TXT_AES_128_GCM_SHA256 "AEAD-AES128-GCM-SHA256"
#define TLS1_TXT_AES_256_GCM_SHA384 "AEAD-AES256-GCM-SHA384"
#define TLS1_TXT_CHACHA20_POLY1305_SHA256 "AEAD-CHACHA20-POLY1305-SHA256"

I have the following in /stats even without explicitly adding to my ciphers config
listener.[__1]_9006.ssl.ciphers.AEAD-AES128-GCM-SHA256: 1

[PiotrSikora]

TLS 1.3 cipher suites use built-in preference order and are not affected by the cipher_suites setting.

[ggreenway]

I think it is worth clarifying in the title of the issues that we are not deprecating support for these versions, cipher-suites, etc, just changing the default for when the user does not specify their own settings.

[PiotrSikora]

@ggreenway it literally says "modernize TLS defaults"

[ggreenway]

@ggreenway it literally says "modernize TLS defaults"

I meant in all the sub-issues.

[PiotrSikora]

@ggreenway ah, that makes more sense! Thanks.

[moderation]

It might be interesting to have Envoy added to https://ssl-config.mozilla.org/. No directions on the page of how to go about doing this.

[derekargueta]

@moderation there's a github repo for the project, and an open issue for Envoy support mozilla/ssl-config-generator#29

[sha-rath]

Any inputs or progress on enabling TLSv1.3 on the client-side by default? It is a 3GPP 5G specific requirement and our customers are eagerly waiting for this feature.

[ggreenway]

I don't think anyone is working on changing the defaults right now. But why are the defaults causing your customers to wait? You can configure the allowed TLS versions currently (and have been able for many releases). See https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto#envoy-v3-api-msg-extensions-transport-sockets-tls-v3-tlsparameters

[sha-rath]

Yes, I have checked this doc before and this is exactly what we are doing currently. The link here clearly mentions, TLSv1.2 is the default for clients and TLSv1.3 is the default for servers. So far, no major issues with setting the client-side to TLSv1.3, but there are some circumstances under which this might fail. Isn't that the reason for not recommending this TLS version or making it as default yet?

[sha-rath]

Any comments or updates on this one? @ggreenway

[ggreenway]

As I said above, I don't think anyone is working on changing the defaults, but if the defaults aren't adequate, you can explicitly configure your TLS versions/ciphers to suit your needs.

[sha-rath]

Yes, I got that @ggreenway and that's what I'm doing currently. So far, I haven't bumped into any issues using TLS 1.3 on the
client-side. One of the tasks here under "Modernize TLS defaults" is to "enable TLS 1.3 on the client-side by default" and I felt it is not solved for a very long time.

Piotr earlier mentioned that this is not as simple as upgrading the "default maximum version for client to TLS 1.3" due to some corner cases involving interactions with TCP resets, delivery of the alerts etc. Are some changes needed in Envoy's implementation regarding the handling of TLS 1.3 or does the protocol itself need some changes that have to be reported? I'm wondering how to proceed with this.

@lizan @mattklein123 It would be great to have your opinion as well on this.

[mattklein123]

@lizan @mattklein123 It would be great to have your opinion as well on this.

I don't know any particular reason why TLS 1.3 couldn't be the default maximum for client connections but I'm not an expert in this space. I would defer to others like @lizan @davidben @ggreenway @PiotrSikora on this.

[davidben]

Clients should indeed be enabling TLS 1.3 at this point. All the browsers have done so for a while now. From #9300, it sounds like you all have some Envoy-specific issues to resolve around it, but I don't work on Envoy, so I don't know the details.

[mattklein123]

Clients should indeed be enabling TLS 1.3 at this point. All the browsers have done so for a while now. From #9300, it sounds like you all have some Envoy-specific issues to resolve around it, but I don't work on Envoy, so I don't know the details.

Thanks @davidben, I just looked at #9300 and I now better understand @PiotrSikora concerns. Let's discuss further in that issue. Thank you.

[sha-rath]

Thank you @mattklein123 for taking a quick look. Looking forward to further discussions on this topic.