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

Client TLS: Add option to require a specific DNS name in Subject Alternate Name #126

Merged
merged 17 commits into from
Apr 7, 2023

Conversation

chodges15
Copy link
Contributor

This is a follow up to the work done in #97 which addresses the requested change by @roidelapluie and @SuperQ to go from CN to SAN verification. Closes #96.

Command used to update the certs can be found in the commit message.

@chodges15
Copy link
Contributor Author

@roidelapluie and @SuperQ this is ready for review when you get a chance, I'd like to get this into Loki for tighter security

@chodges15
Copy link
Contributor Author

@SuperQ - can you kick off CI for this PR again? Linter error that was causing previous error should be resolved.

web/tls_config.go Outdated Show resolved Hide resolved
web/tls_config.go Outdated Show resolved Hide resolved
@chodges15
Copy link
Contributor Author

@SuperQ - can I get another round of review for this?

@SuperQ
Copy link
Member

SuperQ commented Feb 11, 2023

Looks good, can you update the README docs?

@chodges15 chodges15 force-pushed the verify-cert-san branch 2 times, most recently from 2e40f19 to f58eb40 Compare March 1, 2023 04:26
@chodges15
Copy link
Contributor Author

@SuperQ - docs updated, ready for another review

Copy link
Member

@SuperQ SuperQ left a comment

Choose a reason for hiding this comment

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

Minor nit, otherwise LGTM.

VERSION Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
@chodges15 chodges15 requested a review from SuperQ March 1, 2023 04:36
Copy link
Member

@SuperQ SuperQ left a comment

Choose a reason for hiding this comment

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

LGTM

@SuperQ SuperQ requested a review from roidelapluie March 2, 2023 10:51
@roidelapluie
Copy link
Member

please remove the changelog

@chodges15
Copy link
Contributor Author

@roidelapluie - changelog removed.

@roidelapluie
Copy link
Member

I think we should force the regex to be anchored, as it is common in Prometheus.


// NewRegexp creates a new anchored Regexp and returns an error if the
// passed-in regular expression does not compile.
func NewRegexp(s string) (Regexp, error) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This struct borrowed from Prometheus
If needed, this can be refactored by moving into github.com/prometheus/common, though it would be nice if that could be done in a follow up PR.

# Verify that the client certificate has a Subject Alternate Name (SAN) which includes the following
# regex pattern, else terminate connection. SAN match can be one or multiple of the following:
# DNS, IP, e-mail, or URI address from https://pkg.go.dev/crypto/x509#Certificate.
[ client_allowed_san_regex: <string> | default ""]
Copy link
Member

Choose a reason for hiding this comment

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

This is documented twice

saroshali-dbx and others added 10 commits March 27, 2023 11:05
Signed-off-by: saroshali-dbx <[email protected]>
Signed-off-by: chodges15 <[email protected]>
Signed-off-by: saroshali-dbx <[email protected]>
Signed-off-by: chodges15 <[email protected]>
Signed-off-by: saroshali-dbx <[email protected]>
Signed-off-by: chodges15 <[email protected]>
Signed-off-by: saroshali-dbx <[email protected]>
Signed-off-by: chodges15 <[email protected]>
The changed certs were updated based on the command @WGH- in prometheus#61, just with an added SAN DNS. They were generated with this command:

openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout client2_selfsigned.key -out client2_selfsigned.pem -nodes -subj '/CN=test3' -days 36500 -addext "subjectAltName = DNS:test3" -addext "extendedKeyUsage = clientAuth"

Signed-off-by: chodges15 <[email protected]>
Signed-off-by: chodges15 <[email protected]>
Signed-off-by: chodges15 <[email protected]>
Signed-off-by: chodges15 <[email protected]>
Signed-off-by: chodges15 <[email protected]>
@chodges15
Copy link
Contributor Author

@roidelapluie - documentation fixed, not sure how I missed that.

@@ -163,6 +234,11 @@ func ConfigToTLSConfig(c *TLSConfig) (*tls.Config, error) {
cfg.ClientCAs = clientCAPool
}

if c.ClientAllowedSanRegex.Regexp != nil {
// verify that the client cert contains the allowed domain name
cfg.VerifyPeerCertificate = c.VerifyPeerCertificate
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need that if?

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 guess I'm not fully tracking the question, without the if the behavior would be to always require the client to verify SAN; unless you are thinking we could default the regex to be fully permissive with something like .*?

@roidelapluie
Copy link
Member

Shouldn't we use go upstream tls.VerifyOptions ?

Copy link
Member

@roidelapluie roidelapluie left a comment

Choose a reason for hiding this comment

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

Sorry, but I think we should use upstream go VerifyOptions

web/tls_config.go Show resolved Hide resolved
@chodges15
Copy link
Contributor Author

The upstream x509.VerifyHostname does not check all SAN fields, and for fields that it does check it does not support regex, only a wildcard. That being said, if we only care about DNS and IP addresses here (which would handle my use case) I'm fine going with the standard upstream verification.

@roidelapluie
Copy link
Member

Okay. You are correct about SAN's. I think we can move ahead, maybe we should explicltly call out in the documentation that dots must be escaped due to the nature of regexes, but I am also happy about removing support for regexes and working with an explicit list of sans instead.

Signed-off-by: chodges15 <[email protected]>
@chodges15
Copy link
Contributor Author

An explicit list feels better here from a simplicity point of view - and more secure to avoid user regex mistakes.

@SuperQ
Copy link
Member

SuperQ commented Apr 6, 2023

Sorry about the regex distraction. It seemed like a good idea at the time. :)

@roidelapluie
Copy link
Member

One CI lint issue.

Signed-off-by: chodges15 <[email protected]>
@roidelapluie roidelapluie merged commit 47811e7 into prometheus:master Apr 7, 2023
@roidelapluie
Copy link
Member

thanks!

@SuperQ
Copy link
Member

SuperQ commented Apr 7, 2023

Nice!

@chodges15
Copy link
Contributor Author

Thanks for the good feedback @roidelapluie and @SuperQ.

@chodges15 chodges15 deleted the verify-cert-san branch April 7, 2023 14:01
rzetelskik pushed a commit to rzetelskik/exporter-toolkit that referenced this pull request Apr 26, 2023
…rnate Name (prometheus#126)


Signed-off-by: saroshali-dbx <[email protected]>
Signed-off-by: chodges15 <[email protected]>
Co-authored-by: saroshali-dbx <[email protected]>
Co-authored-by: Chris Hodges <[email protected]>
Co-authored-by: chodges15 <[email protected]>
SuperQ added a commit that referenced this pull request May 1, 2023
* [FEATURE] Client TLS: Add option to require a specific Subject Alternate Names #126
* [FEATURE] Add a POST form to the landing page #144
* [FEATURE] Add generic customization to landing page #146
* [ENHANCEMENT] Add a Content-Type header to the landing page #142
* [BUGFIX] Fix Nil pointer references for WebSystemdSocket #127

Signed-off-by: SuperQ <[email protected]>
@SuperQ SuperQ mentioned this pull request May 1, 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.

Further secure TLS communications
4 participants