Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tls: remove 1.0 and 1.1 from client defaults #8755

Merged
merged 5 commits into from
Nov 5, 2019

Conversation

derekargueta
Copy link
Member

@derekargueta derekargueta commented Oct 24, 2019

Description: Remove TLS 1.0 and 1.1 from the default client TLS versions. Users can still explicitly opt-in to 1.0 and 1.1 using tls_minimum_protocol_version.
Risk Level: Low (as #5401 explains, client-side is generally safer, but still a possible risk that it breaks someone somewhere)
Testing: updated
Docs Changes: updated
Release Notes: added
Fixes: #5395 and checks off one box for #5401

cc @PiotrSikora

Signed-off-by: Derek Argueta [email protected]

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.

🐱

Caused by: #8755 was opened by derekargueta.

see: more, trace.

Signed-off-by: Derek Argueta <[email protected]>
htuch
htuch previously approved these changes Oct 25, 2019
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, would be nice to have @PiotrSikora provide an additional sanity check on whether we've missed anything.

@@ -35,7 +35,8 @@ message TlsParameters {
TLSv1_3 = 4;
}

// Minimum TLS protocol version. By default, it's ``TLSv1_0``.
// Minimum TLS protocol version. By default, it's ``TLSv1_2`` for clients and ``TLSv1_0`` for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, this is cool by the Envoy stable API versioning guidelines, since defaults are client specific; control planes that need stability must set explicit values.

@htuch htuch self-assigned this Oct 25, 2019
lizan
lizan previously approved these changes Oct 25, 2019
PiotrSikora
PiotrSikora previously approved these changes Oct 25, 2019
Copy link
Contributor

@PiotrSikora PiotrSikora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks good, thanks! However, we might want to hold off with merging it post 1.12.0 release, so that there is some bake-in time, since it's a potentially disruptive feature.

What do you think @lizan?

/wait

@lizan
Copy link
Member

lizan commented Oct 26, 2019

@PiotrSikora bake-in for? isn't it just push back the disruptive part to 1.13?

@PiotrSikora
Copy link
Contributor

@lizan I meant that if we make this change now, days(?) before the release is cut, then it doesn't give enough time for it to be tested in production in various deployments by people running master, whereas if we make this change right after the release is cut, then it gives months of testing before it makes its way to the next release.

But making those changes right at the beginning of each release cycle was my plan for each of the changes described in #5401, so I'm obviously biased, and you might want to ignore it... It's just something to think about.

@mattklein123
Copy link
Member

I'm mildly +1 on waiting to ship this until after we snap 1.12.0 which is probably going to be Monday or Tuesday.

@lizan
Copy link
Member

lizan commented Oct 28, 2019

I don't have strong opinion, so it's fine either way. My thought was people running master will see them after PR merge anyway, and people running stable will see during new release. There's no much case that master testing can help on stable side and it is easy to override by config.

@mattklein123 mattklein123 self-assigned this Nov 1, 2019
@mattklein123
Copy link
Member

Can you merge master and move the release note to 1.13 and we can ship?

/wait

@derekargueta derekargueta dismissed stale reviews from PiotrSikora, lizan, and htuch via d3e465d November 5, 2019 07:39
@repokitteh-read-only repokitteh-read-only bot added api and removed waiting labels Nov 5, 2019
Signed-off-by: Derek Argueta <[email protected]>
@repokitteh-read-only repokitteh-read-only bot removed the api label Nov 5, 2019
@mattklein123 mattklein123 merged commit d9fc7f7 into envoyproxy:master Nov 5, 2019
@derekargueta derekargueta deleted the dereka/tls-defaults branch November 5, 2019 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove TLS 1.0 and 1.1 from the defaults on the client-side
5 participants