Bump minimum TLS protocol to TLSv1.2#1392
Conversation
There was a problem hiding this comment.
This appeared to be the case in the existing code so I've kept it in place; however, I wasn't sure whether it was intentional or not.
There was a problem hiding this comment.
🤔 Interesting. Might be a useful follow-up PR to move that out of this if branch. Unless someone remembers the rationale for this...
|
Instead of making this configurable, I'm fine enforcing TLS 1.2 and up |
That would also meet my personal needs. Happy to modify this PR to do that if y'all are OK with the reduced client compatibility. |
|
TLS 1.0 and 1.1 are being phased out. I don't feel that dex needs to support them, particularly for any protocol like gRPC. Backend LDAP servers might be the one exception here, since some of that tech tends to be older. Let's enforce TLS 1.2 for now. |
|
👍 I've pushed a commit that bumps the minimum to TLSv1.2 and removes the configurability. |
|
There's a pretty big diff here. I'd only expect the tls.Config to change. |
Most of the changes are moving code around such that I could make sure we are using the tls.Config without too much duplication across different code branches. In the old code, when not using a ClientCA we didn't generate our own tls.Config. https://github.com/dexidp/dex/blob/master/cmd/dex/serve.go#L147 The majority of the diff is a result of changing it so that we are using a tls.Config in that case. If you'd prefer, I can make the diff smaller, the result will just be an opportunity for the tls.Config to drift between those two branches. |
srenatus
left a comment
There was a problem hiding this comment.
Thank you. 🎈 (🔔 we're coworkers)
There was a problem hiding this comment.
Seems like a decent streamlining of the TLS config to me. Instead of using credentials.NewServerTLSFromFile for one path (without the client CA cert) and credentials.NewTLS for the other (where we do have the client CA cert), we now only do the latter; and handle the client CA as part of what's passed to NewTLS. 👍
There was a problem hiding this comment.
🤔 Interesting. Might be a useful follow-up PR to move that out of this if branch. Unless someone remembers the rationale for this...
…ites Some environments are subject to strict rules about the permitted TLS protocol verion and available ciphers. Setting TLSv1.2 as the minimum version ensures we do not use weaker protocols. We've opted against making this configurable given the age of TLSv1.2 and the increasing push to deprecate TLSv1.1 and older. The PreferServerCipherSuites setting is also commonly flagged by SSL quality scanning tools. Since Go provides a relatively modern set of default ciphers by default, defaulting this to true is unlikely to make much practical difference. Signed-off-by: Steven Danna <[email protected]>
dd0bd53 to
59f8b02
Compare
|
Thank you! I'll merge this. A potential follow-up would be to have gRPC and HTTPS share a |
Bump minimum TLS protocol to TLSv1.2
Some environments are subject to strict rules about the permitted TLS
protocol verion and available ciphers. This change makes the former
configurable for both HTTPS and gRPC.
The gRPC protocol rejects anything under TLSv1.2; however, it is still
useful to configure the tls protocol version explicitly because many
automated scanners do not recognize gRPC.
Signed-off-by: Steven Danna [email protected]