tls: remove deprecated cipher suites from client defaults.#13850
tls: remove deprecated cipher suites from client defaults.#13850mattklein123 merged 4 commits intoenvoyproxy:masterfrom
Conversation
Fixes envoyproxy#5396, envoyproxy#5397. Signed-off-by: Piotr Sikora <[email protected]>
mattklein123
left a comment
There was a problem hiding this comment.
Thanks for keeping is up to date. Should this have a release note?
/wait
Signed-off-by: Piotr Sikora <[email protected]>
| client.mutable_common_tls_context()->mutable_tls_params(); | ||
|
|
||
| // Note: There aren't any valid TLSv1.0 or TLSv1.1 cipher suites enabled by default, | ||
| // so enable them to avoid false positives. |
There was a problem hiding this comment.
Sorry what do you mean false positives? Do you just mean the test requires the use of non-default ciphers? Should we actually verify somehow that we don't negotiate with the new removed ciphers?
/wait
There was a problem hiding this comment.
This particular test (ProtocolVersions) verifies that we always negotiate the correct protocol version, and it enables/disables the non-default protocol versions in order to cover all variants.
However, now that we disabled all deprecated cipher suites, enabling TLSv1.0 or TLSv1.1 is no longer sufficient, since none of the new default cipher suites work for those older protocol versions, so the list of available cipher suites for them is effectively empty, and we need to enable older cipher suites in order to successfully negotiate those older protocol versions.
By "false positives" I mean that enabling those cipher suites let's us verify that those older protocol versions are rejected because of the protocol version negotiation, and not because no cipher suites can be negotiated.
I can add few cases to verify that we don't negotiate removed ciphers when using default config in a bit.
There was a problem hiding this comment.
OK I see. Would it be better to split this out into multiple tests, one for each protocol version? It's kind of confusing that this is all mixed together? WDYT?
/wait-any
There was a problem hiding this comment.
There are 16 cases in the ProtocolVersions test that are well commented and very readable, IMHO:
envoy/test/extensions/transport_sockets/tls/ssl_socket_test.cc
Lines 3692 to 3864 in 0922233
I don't think that splitting this test into 16 tiny tests with a ton of boilerplate would improve readability. We'd also need to do the same for other tests that follow this pattern.
If your issue is with the older cipher suite being enabled for all 16 tests cases ahead of time, then I could potentially set and unset them in each case that enables TLSv1.0 or TLSv1.1 and needs it, but that's more error-prone, and since we don't test negotiated cipher suites in this test, I'm not sure it's worth the noise.
There was a problem hiding this comment.
If your issue is with the older cipher suite being enabled for all 16 tests cases ahead of time, then I could potentially set and unset them in each case that enables TLSv1.0 or TLSv1.1 and needs it, but that's more error-prone, and since we don't test negotiated cipher suites in this test, I'm not sure it's worth the noise.
Yes this was my concern. I trust your judgement on this so if you think this is best fine with me! Thank you for looking.
Signed-off-by: Piotr Sikora <[email protected]>
Fixes #5396, #5397.
Signed-off-by: Piotr Sikora [email protected]