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

Add the ability to specify the maximum acceptable TLS version #414

Merged
merged 9 commits into from Dec 8, 2022

Conversation

lspiehler
Copy link
Contributor

Adding the ability to specify the maximum acceptable TLS version to granularly force a specific version. MaxVersion is documented in the TLS Config struct here https://pkg.go.dev/crypto/tls.

prombot and others added 2 commits November 22, 2022 06:26
Signed-off-by: prombot <prometheus-team@googlegroups.com>

Signed-off-by: prombot <prometheus-team@googlegroups.com>
Signed-off-by: Lyas Spiehler <lspiehler@gmail.com>
Signed-off-by: Lyas Spiehler <lspiehler@gmail.com>
Signed-off-by: Lyas Spiehler <lspiehler@gmail.com>
@roidelapluie
Copy link
Member

What is the motivation here? We did not enable that because it seems like bad practice to limit the max tls version and we want to encourage the use of TLS 1.3.

@lspiehler
Copy link
Contributor Author

lspiehler commented Nov 25, 2022

I'm trying to monitor certificates using the blackbox_exporter on servers running jetty web servers with support for TLS 1.2 and 1.3. I'm getting the error "remote error: tls: handshake failure" when the go TLS client attempts to connect using TLS 1.3. These are vendor managed servers and I have no access to the server side.

I've found I can successfully complete the TLS handshake if I add "MaxVersion: tls.VersionTLS12" to my TLS config. Interestingly, I am able to use TLS 1.3 with OpenSSL using the command openssl s_client -connect servername.example.com:443 -tls1_3. I'm also able to use TLS 1.3 when using a browser.

A similar issue was reported here https://stackoverflow.com/questions/41250665/go-https-client-issue-remote-error-tls-handshake-failure. Their issue was with TLS 1.2, but they used the same solution. I haven't found another way to get the handshake to succeed without forcing a specific TLS version using "MaxVersion." Thank you!

@roidelapluie
Copy link
Member

Okay, I think it's reasonable to add. However, this pull request appears to be a noop I think and does not achieve its goal. Would you add some tests? thanks

Signed-off-by: Lyas Spiehler <lspiehler@gmail.com>
Signed-off-by: Lyas Spiehler <lspiehler@gmail.com>
@lspiehler
Copy link
Contributor Author

You're right. e1fa703 should fix noop and tests have been added in fc15924. Thanks!

@@ -21,6 +21,7 @@ import (
"crypto/x509"
"encoding/json"
"fmt"
"io/ioutil"
Copy link
Contributor

Choose a reason for hiding this comment

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

this was recently fixed, this branch needs to be synced with main

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I resynced and removed the ioutil import in 9d070c0

@@ -779,6 +780,7 @@ func NewTLSConfig(cfg *TLSConfig) (*tls.Config, error) {
tlsConfig := &tls.Config{
InsecureSkipVerify: cfg.InsecureSkipVerify,
MinVersion: uint16(cfg.MinVersion),
MaxVersion: uint16(cfg.MaxVersion),
Copy link
Contributor

Choose a reason for hiding this comment

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

This is fine.

What I'm thinking is that we (maybe) should validate the following:

  • Both unset is fine
  • One set is fine
  • Both set should enforce MaxVersion >= MinVersion

I haven't followed all the use locations of the code, but if we don't check for this in NewTLSConfig, I think we might end up with some weird errors later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

a9a674f will generate an error if max and min version are both set and max is less than min. I added a bunch of tests in 5977368. Thanks!

Copy link
Member

Choose a reason for hiding this comment

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

Is there any guarantees that the underlying lib will follow the order ? I would let the underlying tls lib decide what to do.

… is greater than or equal to minversion

Signed-off-by: Lyas Spiehler <lspiehler@gmail.com>
Signed-off-by: Lyas Spiehler <lspiehler@gmail.com>
@roidelapluie roidelapluie merged commit 87b669d into prometheus:main Dec 8, 2022
@roidelapluie
Copy link
Member

Thanks!

roidelapluie added a commit to roidelapluie/prometheus that referenced this pull request Dec 8, 2022
- Check if TLS certificate and key file have been modified
  prometheus/common#345
- Add the ability to specify the maximum acceptable TLS version
  prometheus/common#414

Signed-off-by: Julien Pivotto <roidelapluie@o11y.eu>
radek-ryckowski pushed a commit to goldmansachs/common that referenced this pull request May 18, 2023
radek-ryckowski pushed a commit to goldmansachs/common that referenced this pull request May 22, 2023
radek-ryckowski pushed a commit to goldmansachs/common that referenced this pull request May 30, 2023
radek-ryckowski pushed a commit to goldmansachs/common that referenced this pull request Nov 9, 2023
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.

None yet

4 participants