search

envoyproxy / envoy

Cloud-native high-performance edge/middle/service proxy
https://www.envoyproxy.io
Apache License 2.0
24.91k stars 4.79k forks source link

Modernize TLS defaults #5401

Open PiotrSikora opened 5 years ago

PiotrSikora commented 5 years ago

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

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 commented 5 years ago

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

moderation commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

ggreenway commented 5 years ago

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 commented 5 years ago

@ggreenway it literally says "modernize TLS defaults"

ggreenway commented 5 years ago

@ggreenway it literally says "modernize TLS defaults"

I meant in all the sub-issues.

PiotrSikora commented 5 years ago

@ggreenway ah, that makes more sense! Thanks.

moderation commented 4 years ago

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 commented 3 years ago

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

sha-rath commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Any comments or updates on this one? @ggreenway

ggreenway commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

Clients should indeed be enabling TLS 1.3 at this point. All the browsers have done so for a while now. From https://github.com/envoyproxy/envoy/issues/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 commented 2 years ago

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