Wie konfiguriere ich SSL/TLS für die Verbindung mit einer Cloud SQL-Instanz?

Question

Soweit ich sehe, ist eine Verbindung über SSL/TLS mit Cloud SQL immer verfügbar. Wenn ich sie erzwinge, wird sie erforderlich. Aber das maximale Schutzniveau, das ich erreichen konnte, gilt verify-casowohl aus der Perspektive des Clients als auch des Servers. Das ist:

• der Kellnerwerde nicht sicherstellen ( auth-options)Der allgemeine Name im Client-Zertifikat stimmt mit dem Benutzer überein, mit dem ich eine Verbindung herstellen möchte (jeder allgemeine Name kann verwendet werden).
• der Kundewird nicht sicherstellenDer allgemeine Name im Serverzertifikat stimmt mit dem Hostnamen überein, mit dem ich mich verbinde (jeder Hostname kann verwendet werden).

Laut den Dokumentenkann verbindenmit sslmode=verify-full, aber entweder weiß ich nicht, welchen Instanznamen sie meinen, oder die Informationen in den Dokumenten sind veraltet. (1) Wie verbinde ich mich mit verify-full?

Die Dokumentesagt auch:

Ein SSL-Modus verify-fullist nicht erforderlich; verify-careicht aus, da die CA instanzenspezifisch ist.

Indie pgDokumenteIch kann sehen:

Der Unterschied zwischen verify-caund verify-fullhängt von der Richtlinie der Stammzertifizierungsstelle ab. Wenn eine öffentliche Zertifizierungsstelle verwendet wird, verify-caerlaubt Verbindungen zu einem Server, den jemand anderes möglicherweise bei der Zertifizierungsstelle registriert hat. In diesem Fall verify-fullsollte immer verwendet werden. Wenn eine lokale Zertifizierungsstelle oder sogar ein selbstsigniertes Zertifikat verwendet wird, verify-cabietet die Verwendung von oft ausreichend Schutz.

(2) Was bedeutet das? Wenn die Zertifizierungsstelle lokal ist, können nur autorisierte Personen ein Zertifikat und einen privaten Schlüssel erstellen und das Zertifikat mit dem Stammzertifikat der Zertifizierungsstelle signieren? Und obwohl man wahrscheinlich das Zertifikat des Servers erhalten kann (wenn der Server öffentlich ist), kann man den privaten Schlüssel nicht erhalten? Somit kann keine unbefugte Person ein gültiges Zertifikat haben? Wenn ein Zertifikat gültig ist, wurde es also von einer autorisierten Person erstellt und der CN spielt keine Rolle? Warum? Ich scheine nah dran zu sein, aber mir fehlt noch etwas.

(3) Wenn die CA lokal ist, verify-ca== verify-full(kein Abhören, kein MITM)?

Weitere Einzelheiten zu dem, was ich genau getan habe, finden SieHier.

Answer 1

Wie verbinde ich mich mit verify-full?

Sie müssen zuerst den CN des Serverzertifikats herausfinden:

$ 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"

Anschließend können Sie eine Verbindung herstellen:

$ 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=>

Ich kenne keine anderen Möglichkeiten, es (den CN) herauszufinden, als diesen Trick zu verwenden. Daher scheint es nicht so, als ob Sie es verwenden sollten verify-fulloder dass es irgendeinen Sinn ergibt. Die Dokumentation legt nahe, dass es verify-fullzumindest nicht wesentlich besser ist als verify-ca.

Was bedeutet das?

Bei einer lokalen Zertifizierungsstelle können nur autorisierte Personen ein Zertifikat erhalten. Somit kann kein Unbefugter den Zielserver vortäuschen.

Wenn die CA lokal ist verify-ca == verify-full(kein Abhören, kein MITM)?

verify-ca != verify-full, aber sicherheitstechnisch soll es da keinen großen Unterschied geben. Insbesondere sollen keine MITMs möglich sein.

Beispiele für die Konfiguration von SSL/TLS finden SieHier.