Implement "verify-ca" SSL mode #32
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I came across a situation with Google Cloud SQL where I needed the behavior of "verify-ca" because "verify-full" was too strict. Specifically, Postgres instances on GCP typically don't have a hostname and use their own private CA when signing certs. This causes the TLS handshake to fail if you attempt to connect via IP:
Since the CA is private, checking the server name is unnecessary, and Google's docs recommend using "verify-ca".
I found a solution by setting InsecureSkipVerify to true and setting a VerifyPeerCertificate function in the tls.Config returned by ParseConfig. Basically, VerifyPeerCertificate manually verifies the cert chain, but skips checking the hostname. You can see golang/go#21971 (comment) and the crypto/tls package example for more details on how this is implemented.
Since this wasn't super straightforward to figure out, I thought I'd see if you wanted it upstream. I also poked around and couldn't find a way to write a test the new SSL behavior, but I did test everything manually for my use-case.