☰

¿Cómo configuro SSL/TLS para conectarme a una instancia de Cloud SQL?

tag-icon • tag-icon ssl google-cloud-platform postgresql google-cloud-sql
¿Cómo configuro SSL/TLS para conectarme a una instancia de Cloud SQL?

Por lo que puedo ver, la conexión a través de SSL/TLS siempre está disponible con Cloud SQL. Si lo hago cumplir, se vuelve obligatorio. Pero el nivel máximo de protección que pude alcanzar es verify-cadesde la perspectiva tanto del cliente como del servidor. Eso es:

  • el servidorno se asegurará ( auth-options)el nombre común en el certificado del cliente coincide con el usuario con el que estoy intentando conectarme (se puede usar cualquier nombre común)
  • el clienteno se aseguraráel nombre común en el certificado del servidor coincide con el nombre de host al que me estoy conectando (se puede usar cualquier nombre de host)

Según los documentos quepuede conectarsecon sslmode=verify-fullpero no sé a qué nombre de instancia se refieren o la información en los documentos no está actualizada. (1) ¿Cómo me conecto verify-full?

los documentostambién dice:

verify-fullNo se requiere un modo SSL de ; verify-caes suficiente porque la CA es específica de la instancia.

Enlos pgdocumentosPuedo ver:

La diferencia entre verify-cay verify-fulldepende de la política de la CA raíz. Si se utiliza una CA pública, verify-capermite conexiones a un servidor que otra persona puede haber registrado en la CA. En este caso, verify-fullsiempre se debe utilizar. Si se utiliza una CA local, o incluso un certificado autofirmado, su uso verify-casuele proporcionar suficiente protección.

(2) ¿Qué significa esto? Si la CA es local, ¿solo las personas autorizadas pueden crear un certificado y una clave privada y firmar el certificado con el certificado raíz de la CA? Y aunque probablemente uno pueda obtener el certificado del servidor (si el servidor es público), ¿no puede obtener la clave privada? Como tal, ¿ninguna persona no autorizada puede tener un certificado válido? Como tal, si un certificado es válido, fue creado por una persona autorizada y no importa cuál sea el CN. ¿Por qué? Parece que estoy cerca, pero todavía hay algo que me falta.

(3) Si la CA es local, verify-ca== verify-full(sin escuchas, sin MITM)?

Se pueden encontrar más detalles sobre lo que hice exactamente.aquí.

Respuesta1

¿Cómo me conecto verify-full?

Primero debe averiguar el CN ​​del certificado del servidor:

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

Entonces puedes conectarte:

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

No conozco otras formas de resolverlo (el CN) aparte de usar este truco. Como tal, no parece que debas usarlo verify-fullni que tenga ningún sentido. La documentación sugiere que verify-fullal menos no es significativamente mejor que verify-ca.

¿Qué quiere decir esto?

Con una CA local sólo las personas autorizadas pueden obtener un certificado, por lo que ninguna persona no autorizada puede falsificar el servidor de destino.

¿Si la CA es local verify-ca == verify-full(sin escuchas ilegales, sin MITM)?

verify-ca != verify-full, pero supuestamente no hay mucha diferencia en términos de seguridad. En particular, no debería ser posible realizar MITM.

Puede encontrar un ejemplo de configuración de SSL/TLSaquí.

información relacionada