-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
crypto/tls: feature request: add option to JUST skip hostname verification #21971
Comments
CC @agl @FiloSottile |
You can currently do this by using go/src/crypto/tls/handshake_client.go Lines 315 to 344 in 39e5237
I don't think this is common enough to add another verification option to the already crowded |
Problem is I want to use a library (rafthttp) that only exposes a transport.TLSInfo (https://github.com/coreos/etcd/blob/master/pkg/transport/listener.go) , not a tls Config (https://golang.org/pkg/crypto/tls/#Config). So this sort of manual workaround would need to be plumbed up the stack for me to use it. If there was a simple option, it would be easier to plumb this through.
[https://avatars2.githubusercontent.com/u/3730757?v=4&s=400]<https://github.com/coreos/etcd/blob/master/pkg/transport/listener.go>
etcd/listener.go at master · coreos/etcd · GitHub<https://github.com/coreos/etcd/blob/master/pkg/transport/listener.go>
github.com
etcd - Distributed reliable key-value store for the most critical data of a distributed system
Package tls - The Go Programming Language<https://golang.org/pkg/crypto/tls/#Config>
golang.org
Constants. A list of cipher suite IDs that are, or have been, implemented by this package. Taken from http://www.iana.org/assignments/tls-parameters/tls-parameters.xml
…________________________________
From: Filippo Valsorda <notifications@github.com>
Sent: September 27, 2017 5:37 PM
To: golang/go
Cc: rsm10; Author
Subject: Re: [golang/go] crypto/tls: feature request: add option to JUST skip hostname verification (#21971)
You can currently do this by using VerifyPeerCertificate and (*Certificate).Verify (and remembering to put the remaining rawCerts into VerifyOptions.Intermediates).
https://github.com/golang/go/blob/39e523792e33a0bd9217161ca53c6c0cb2324a99/src/crypto/tls/handshake_client.go#L315-L344
[https://avatars3.githubusercontent.com/u/4314092?v=4&s=400]<https://github.com/golang/go/blob/39e523792e33a0bd9217161ca53c6c0cb2324a99/src/crypto/tls/handshake_client.go#L315-L344>
golang/go<https://github.com/golang/go/blob/39e523792e33a0bd9217161ca53c6c0cb2324a99/src/crypto/tls/handshake_client.go#L315-L344>
github.com
go - The Go programming language
I don't think this is common enough to add another verification option to the already crowded tls.Config.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#21971 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAvL8o2bbdzxc8ptfc343eWUqY16IHmQks5smupMgaJpZM4Pf-6w>.
|
As to your original suggestion, curious why on lines 334-336 we seem to skip the first cert in the chain?
|
The first cert is the leaf, and it’s used on line 339. All the others are intermediates and are used on line 337. |
This is a very special case. I would suggest working with the library maintainers (or just having your own fork) to expose the tls.Config. We shouldn't add a second way to do something in the standard library (especially a somewhat confusing security knob) just because one downstream package hides the first way. |
I am also interested in skipping the hostname verification only. The problem is that if the ServerName is unset, it ill be inferred. As stated above, one way to achieve it is to set InsecureSkipVerify to true and copy/paste the code from the stdlib to config.VerifyPeerCertificate, but that is suboptimal, as one would miss fixes done to this part of the code in the stdlib. 👍 for a |
👍 for a SkipHostnameVerification option as well. Trying to get client authentication working with MySQL. Using a self-signed cert because I'm running everything out of VPS machines. Everything is IP based. Has anyone built the code for the suggested work around? I don't want to reinvent the wheel. |
Awesome, thanks for the quick response. |
Should line 109 set the verified chains? Or does it not matter? Now:
Then:
|
That was too quick. I looked again, and verifiedChains is input to the function, not output. The api/callback doesn't support setting verifiedChains (which should probably be fixed upstream). |
Agree, everything seems to work without it getting returned. Thanks for your help. |
Change https://golang.org/cl/193620 mentions this issue: |
Setting InsecureSkipVerify and VerifyPeerCertificate is the recommended way to customize and override certificate validation. However, there is boilerplate involved and it usually requires first reimplementing the default validation strategy to then customize it. Provide an example that does the same thing as the default as a starting point. Examples of where we directed users to do something similar are in issues #35467, #31791, #28754, #21971, and #24151. Fixes #31792 Change-Id: Id033e9fa3cac9dff1f7be05c72dfb34b4f973fd4 Reviewed-on: https://go-review.googlesource.com/c/go/+/193620 Reviewed-by: Adam Langley <agl@golang.org>
ParseConfig currently treats the libpq "verify-ca" SSL mode as "verify-full". This is okay from a security standpoint because "verify-full" performs certificate verification and hostname verification, whereas "verify-ca" only performs certificate verification. The downside to this approach is that checking the hostname is unnecessary when the server's certificate has been signed by a private CA. It can also cause the SSL handshake to fail when connecting to an instance by IP. For example, a Google Cloud SQL instance typically doesn't have a hostname and uses its own private CA to sign its server and client certs. This change uses the tls.Config.VerifyPeerCertificate function to perform certificate verification without checking the hostname when the "verify-ca" SSL mode is set. This brings pgconn's behavior closer to that of libpq. See golang/go#21971 (comment) and https://pkg.go.dev/crypto/tls?tab=doc#example-Config-VerifyPeerCertificate for more details on how this is implemented.
I understand in "fca335e" we made changes to enforce either requiring ServerName or InsecureSkipVerify to be set in our tls libraries.
What about making this the default behaviour but having a "SkipHostnameVerification" option? I have a situation where we are using certs signed by our own private CA. The hostname verification won't work since we pre-generate certs using a CN that isn't an actual DSN/Host name. I still want to validate that other servers certs are at least signed by the same private CA as the client but JUST want to skip the hostnameVerify check. Today that doesn't seem possible.
The text was updated successfully, but these errors were encountered: