☰

Как настроить SSL/TLS для подключения к экземпляру Cloud SQL?

tag-icon • tag-icon ssl google-cloud-platform postgresql google-cloud-sql
Как настроить SSL/TLS для подключения к экземпляру Cloud SQL?

Насколько я могу судить, соединение через SSL/TLS всегда доступно с Cloud SQL. Если я его принудительно применяю, оно становится обязательным. Но максимальный уровень защиты, которого мне удалось достичь, — это verify-caс точки зрения как клиента, так и сервера. То есть:

  • серверне буду уверен ( auth-options)общее имя в клиентском сертификате соответствует пользователю, от имени которого я пытаюсь подключиться (можно использовать любое общее имя)
  • клиентне будет уверенобщее имя в сертификате сервера совпадает с именем хоста, к которому я подключаюсь (можно использовать любое имя хоста)

Согласно документам яможет подключитьсяс, sslmode=verify-fullно либо я не знаю, какое имя экземпляра они имеют в виду, либо информация в документации устарела. (1) Как мне подключиться к verify-full?

Документытакже говорит:

Режим SSL verify-fullне требуется; verify-caего достаточно, поскольку ЦС специфичен для конкретного экземпляра.

Вдокументыpg​Я вижу:

Разница между verify-caи verify-fullзависит от политики корневого CA. Если используется публичный CA, verify-caразрешает подключения к серверу, который кто-то другой мог зарегистрировать в CA. В этом случае verify-fullвсегда следует использовать. Если используется локальный CA или даже самоподписанный сертификат, использование verify-caчасто обеспечивает достаточную защиту.

(2) Что это значит? Если CA локальный, только уполномоченные лица могут создать сертификат и закрытый ключ, а также подписать сертификат корневым сертификатом CA? И хотя, вероятно, можно получить сертификат сервера (если сервер публичный), но нельзя получить закрытый ключ? Таким образом, ни одно неуполномоченное лицо не может иметь действительный сертификат? Таким образом, если сертификат действителен, он был создан уполномоченным лицом, и неважно, какой у него CN? Почему? Кажется, я близок к разгадке, но все еще что-то упускаю.

(3) Если CA локальный, verify-ca== verify-full(без подслушивания, без MITM)?

Более подробную информацию о том, что именно я сделал, можно найти здесь.здесь.

решение1

Как мне связаться с verify-full?

Сначала вам необходимо выяснить CN-номер сертификата сервера:

$ psql -h xx.yyy.xx.yyy -U postgres sslmode=verify-full
psql: error: connection to server at "xx.yyy.xx.yyy", port 5432 failed: server certificate for "31-0628fb91-0e3b-4c89-adca-ad557023a699.europe-central2.sql.goog" (and 1 other name) does not match host name "xx.yyy.xx.yyy"

Затем вы можете подключить:

$ psql -U postgres 'sslmode=verify-full hostaddr=xx.yyy.xx.yyy host=xx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.europe-central2.sql.goog'
Password for user postgres: 
psql (15.4, server 11.19)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=>

Я не знаю других способов выяснить это (CN), кроме как с помощью этого трюка. Таким образом, это не похоже на то, что вы должны использовать verify-fullили что это имеет какой-либо смысл. Документация предполагает, что verify-fullпо крайней мере не значительно лучше, чем verify-ca.

Что это значит?

При использовании локального центра сертификации получить сертификат могут только уполномоченные лица, поэтому ни одно неуполномоченное лицо не сможет подделать целевой сервер.

Если CA локальный verify-ca == verify-full(без подслушивания, без MITM)?

verify-ca != verify-full, но, предположительно, в плане безопасности особой разницы нет. В частности, не должно быть возможности MITM.

Пример настройки SSL/TLS можно найти здесь.здесь.

Связанный контент