tls: enable the selection of more TLS settings

[roidelapluie]

This is my attempt to unblock prometheus/docs#1611

This pull request provides the ability for our users to select the TLS version and cipher suites, therefor partially lifting the concerns about the TLS policy, as users will be able to do a lot by themselves.

I did not include the following settings:

• NextProtos we can disable http2 for the whole server
• Renegotiation this is basically obsolete

As they are really niche. If we have users coming with this, we can discuss with them about those settings.

I hope that this pull request will move the debate forward.

Signed-off-by: Julien Pivotto [email protected]

[brian-brazil]

Setting policy questions aside, how would you plan to keep this working given that anything in common needs to be compatible with and have tests passing on (currently) Go 1.9 through Go 1.14? At the least, listing all ciphers in the docs seems challenging in that regard.

[brian-brazil]

And it occurs to me that we'd only need to limit the files to Go 1.14+ in order to compile/tests passing, as we don't actually need it to work on older versions.

[roidelapluie]

We have tests for go1.9 on procfs and client_golang, which don't need this

[brian-brazil]

This PR however depends on APIs that were only added in 1.14.

[roidelapluie]

I have fixed the dependencies to go 1.14 API's

[brian-brazil]

I think it's fine to require 1.14 this and it'll make things simpler, you just need to do it in a way that won't break compiles on other versions - such as build tags.

[roidelapluie]

I think it's fine to require 1.14 this and it'll make things simpler, you just need to do it in a way that won't break compiles on other versions - such as build tags.

If you look at both commits now, the first one use go 1.14 apis when available.

The second one removes the fallback mechanism. I would say we can stick to the first one, which only requires go 1.12 (because we list tls1.3 ciphers).

In which case would we need this package in go < 1.12 ?

[roidelapluie]

I have re-added my go 1.12 fallback ; with a final fallback to just numbers with go < 1.12

[brian-brazil]

We don't need the code to run in Go pre-1.14, we only need it not to indirectly break builds for client_golang. It's only our own code that'll be running this, so we can ensure we upgrade our repos 1.14 first.

Manually updating a list of ciphers isn't very maintainable.

[roidelapluie]

We don't need the code to run in Go pre-1.14, we only need it not to indirectly break builds for client_golang. It's only our own code that'll be running this, so we can ensure we upgrade our repos 1.14 first.

Manually updating a list of ciphers isn't very maintainable.

crypto/tls ciphers are not changing. They added tls1.3 ciphers and renamed 2 ciphers in go 1.14, but that's all from what I see back from go1.9.

Overall, the options of the crypto/tls are by purpose only a subset of what the TLS protocol can offer; a maintainer calls it "only useful options" which means that it is probably useful to drag those options in out https package.

[brian-brazil]

They've definitely changed in the past, go1.8 for example, it's safer to use the functions provided to introspect than to hardcode.

[discordianfish]

Implementation wise, this LGTM. But I'm not sure why we changed from 'using defaults, require TLS >=1.2' to all these options. Because we need(??) to support curl based debugging, when TLS is enabled on RHEL versions that only support 1.0? I'm not convinced. People who have to use super old distributions can still compile/install newer curl if they want to use TLS).
But I'm also not against this, so if @SuperQ is fine with this, we can merge it.

[roidelapluie]

Well I want to move forward with the general security policy change which is blocked on finding a clear policy to say yes/no on pull requests.

This pull request aims at avoiding having a strict/complex policy by allowing users to make their own choices outside of the project policy (which is then based on "just" lazy consensus).

(To be clear the curl issue would only be if we pick tls1.3 only. tls1.2 is supported in rhel for a loooong time).

[brian-brazil]

People who have to use super old distributions can still compile/install newer curl if they want to use TLS

The issue isn't a single isolated binary which is easy to resolve as you say, but more complex applications and situations where upgrading a dependency may not be practical. For example as the conversation stands it looks like the proposal is to by default break Go binaries compiled before Feb 2019 in Feb 2021, as that's 2 years since TLS1.3 support came out. 2 years isn't that long to go without recompiling a binary, particularly if it's from a 3rd party.

we can merge it.

It can be merged iff there is a consensus.

[discordianfish]

Well I want to move forward with the general security policy change which is blocked on finding a clear policy to say yes/no on pull requests.

Just to be clear and consider all available options, the issue here is that Brian blocks the plan of just requiring at least TLS 1.2 and sticking with go's defaults?

Is there anyone else who feels that way or is it just Brian? @roidelapluie @SuperQ @gouthamve

[brian-brazil]

Brian blocks the plan of just requiring at least TLS 1.2

I'm not against requiring at least TLS 1.2, I'm against requiring TLS 1.2 without a policy to explain why we require at least TLS 1.2 and deviate from defaults only in that detail.

[brian-brazil]

👍

[SuperQ]

LGTM

[roidelapluie]

For completeness, I have added a test for PreferServerCipherSuites. We are good to go.

[brian-brazil]

👍