Cloud SQL上的证书验证 [英] Certificate Validation on Cloud SQL
问题描述
我发现，如果您通过SSL连接到Cloud SQL实例，则服务器证书中提供的CommonName是 my-project-123456:myinstance ，这会使证书无效.客户希望CN是主机名或IP.
I've found that if you connect to a Cloud SQL instance over SSL the CommonName provided in the server's certificate is my-project-123456:myinstance which renders the certificate un-validatable, as the client expects that the CN to be either the hostname or IP.
该问题的每种解决方案似乎都等于只是禁用验证"，这对我来说是不可接受的，因为:
Every solution to this problem seems to amount to "just disable validation", which is not acceptable to me because:
-
为什么GCP决定正确地做其他所有事情，提供CA证书和客户端证书，而只是放弃身份验证?通过禁用验证，您基本上是说我可以在某个时候被MITM接受".
Why has GCP decided to do everything else correctly, providing a CA cert and client certificates, only to drop the ball on identity validation? By disabling validation you're basically saying "I'm OK with being MITMed at some point".
对于那些由于PIPA/HIPAA而无法通过验证进行快速松散的项目呢?
What about projects where we can't play fast and loose with validation because of PIPA/HIPAA?
不支持关闭验证的mySQL客户端呢?例如:在即将发布的5.6.16发行版之前，所有使用mysqlnd的PHP 5.6 mysql库.
What about mySQL clients that don't support turning validation off? eg: All PHP 5.6 mysql libs using mysqlnd prior to the upcoming 5.6.16 release.
有什么方法可以使SSL在Cloud SQL上正常工作?
Is there any way to make SSL work correctly on Cloud SQL?
推荐答案
在服务器证书的通用名称中没有实例IP地址的原因之一是因为这些IP可以更改.今天实例A的IP地址可以是明天实例B的IP地址，因为删除了A，或者A决定不再使用该IP地址.因此，实例名称被确定为实例的唯一标识.
One of the reasons for not having the IP address of the instance in the common name of the server certificate is because these IPs can change. What is the IP address of instance A today can be the IP address of instance B tomorrow, because A was deleted, or A decided that it doesn't want the IP address anymore. So, the instance name was decided as being a more unique identification of the instance.
此外，默认情况下，mysql客户端库禁用了主机名验证. http://dev.mysql.com/doc/refman/5.7/en/ssl-options.html
Also, the mysql client libraries by default have hostname verification disabled. http://dev.mysql.com/doc/refman/5.7/en/ssl-options.html
关于MITM攻击，由于服务器证书和每个客户端证书都是由唯一的自签名CA签名的，因此永远无法对Cloud SQL实例进行MITM攻击，而CA永远不会用于签名多个证书.服务器仅信任由这些CA之一签名的证书.每个客户端证书使用唯一的CA的原因是因为MySQL 5.5不支持证书吊销列表，我们也不想处理CRL，但是希望支持客户端证书的删除.
With regards to MITM attacks, it is not possible to MITM attack a Cloud SQL instance because the server certificate and the each of the client certificates are signed by unique self-signed CAs which are never used to sign more than one cert. The server only ever trusts certificates signed by one of these CAs. The reason for using unique CAs per client cert was because MySQL 5.5 did not support certificate revocation lists, and we also did not want to deal CRLs, but wanted to support deletion of client certs.
我们将研究无法关闭主机名验证的客户端支持SSL的方法.但是我不能保证会为此提供ETA.
We will look into ways of supporting SSL for clients which cannot turn off hostname validation. But I cannot promise an ETA on this.
Cloud SQL团队.
Cloud SQL Team.
这篇关于Cloud SQL上的证书验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
