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

Support hostname verification to allow verify-full SSL/TLS connections #1087

Open
hessjcg opened this issue May 23, 2024 · 3 comments
Open
Assignees
Labels
priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@hessjcg
Copy link
Contributor

hessjcg commented May 23, 2024

Feature Description

The Cloud SQL Python Connector currently only supports verify-ca
as it's highest level of SSL/TLS client verification.

verify-ca: verify that the server is trustworthy by checking the certificate chain up to the root certificate

We are only getting verify-ca level of security due to hostname verification
being disabled currently .

# update ssl.PROTOCOL_TLS_CLIENT default
context.check_hostname = False

We should support verify-full as it is the highest level of security.

verify-full: will also verify that the server host name matches the name stored in the server certificate

To do so we must support hostname verification.

For Public IP and PSA Private IP connections, the server certificate's
subject CN field in the server certificate will contain the instance name
in the form "{project}:{instance}". The python connector should validate
that this is correctly set during the TLS handshake. The connector should
reject the connection if this the server CN is not set correctly.

Unfortunately for PSC enabled and CAS-based instances hostname
verification is not possible. This is due to the server certificates including
the DNS name as a SAN which include a trailing dot ("."). Python's SSL does
not allow trailing dots
during hostname verification, it requires stripping them.
This leads to hostname mismatch errors as the SAN is expecting a trailing dot.

See also: GoogleCloudPlatform/cloud-sql-jdbc-socket-factory#1995

@hessjcg hessjcg added the type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. label May 23, 2024
@hessjcg hessjcg self-assigned this May 23, 2024
@jackwotherspoon jackwotherspoon added the priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. label May 23, 2024
@jackwotherspoon
Copy link
Collaborator

jackwotherspoon commented May 31, 2024

This is going to be slightly complex to validate during the TLS handshake.

For pg8000, pymysql and pytds it is easy as we can change the server_hostname to project:instance for old instances and to the DNS name for CAS and PSC (barring the SAN issue gets fixed).

But for asyncpg we don't have control over the handshake at all as it is done in the asyncpg code, we just pass it the SSL/TLS context object.

return await asyncpg.connect(
user=user,
database=db,
password=passwd,
host=ip_address,
port=SERVER_PROXY_PORT,
ssl=ctx,
direct_tls=True,
**kwargs,
)

@jackwotherspoon
Copy link
Collaborator

Adding context link for DNS name with trailing dot: openssl/openssl#11560

@jackwotherspoon jackwotherspoon changed the title Check that server certificate contains instance name during TLS handshake Support hostname verification to allow verify-full SSL/TLS connections Sep 13, 2024
@jackwotherspoon
Copy link
Collaborator

Will need to make sure we have this cover CAS based Ca's where the DNS name should be set as the server hostname to verify, will be CUSTOMER_MANAGED_CAS_CA and GOOGLE_MANAGED_CAS_CA

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

2 participants