MySQL por VPN: verifique el servidor, no solo el cifrado
Cifrar hacia el host equivocado sigue estando mal. Compare los valores de ssl-mode y luego ejecute una conexión que nombre el servidor que pretendía y lo demuestre.
Usted guarda una conexión a 10.20.4.15, la VPN cae y el cliente sigue conectando. Eso no es una buena noticia. Una dirección privada es una ubicación dentro de cualquier contexto de enrutamiento en el que se encuentre, y muchas redes usan los mismos rangos. El cliente llegó a un servidor MySQL, solo que quizá no al suyo.
La solución tiene dos mitades, y solo una trata de la red. Mantenga la conexión en su ruta prevista y haga que el cliente autentique el servidor con el que habla. La primera mitad es donde ayuda una VPN; la segunda mitad hay que configurarla.
¿Cifrado hacia qué, exactamente?
TLS protege la conversación frente a cualquiera que esté en medio y no dice nada sobre quién dice ser el extremo, a menos que el cliente lo compruebe. Un certificado que valida contra una autoridad de confianza demuestra que el certificado provino de esa autoridad. No demuestra que el certificado se emitiera para el nombre de host que usted pretendía alcanzar, y esas son preguntas distintas.
No es una laguna teórica. Los portales cautivos, los errores de VRF equivocado y los planes de direcciones solapados producen todos un servidor perfectamente dispuesto a negociar TLS con usted. Si el cliente solo exige cifrado, la sesión es privada y apunta a la base de datos equivocada.
Así que la pregunta pertinente no es si la conexión está cifrada, sino si lo está hacia la identidad que usted pretendía. En el cliente de MySQL, esa distinción vive por completo en el ajuste ssl-mode.
Los cinco valores de ssl-mode en la práctica
Existen cinco valores, y solo uno de ellos responde a la pregunta de este manual. La tabla enumera lo que cada uno garantiza en realidad, en lugar de lo que su nombre sugiere.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Solo la última fila responde a la pregunta de este artículo. PREFERRED merece señalarse por sí solo, porque un cliente que cae en silencio a texto plano es peor que uno que se niega: usted cree tener cifrado y la captura de paquetes no está de acuerdo.
Una conexión que puede ejecutar hoy
El comando de abajo es la forma que debe usar, con dos marcadores: el nombre de base de datos aprobado y un archivo CA obtenido por un canal aprobado. Ninguno debería tomarse de lo que el servidor le ofrezca en el primer contacto.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sin valor pide entrada, lo que mantiene el secreto fuera de la lista de procesos y fuera del historial de su shell. Es un hábito pequeño con un gran beneficio en hosts de salto compartidos, donde una línea de comandos es visible para otros usuarios.
Cuando esto falla, el texto del error distingue los casos mejor que la intuición. Un fallo de CA significa que la cadena no valida y debería mirar qué CA firmó el certificado del servidor. Un fallo de nombre de host significa que la cadena está bien y el nombre no coincide, lo que normalmente significa que se conectó al servidor correcto con el nombre equivocado, no al servidor equivocado.
Que aparezca un aviso no es prueba de que una contraseña ya se haya transmitido, y una conexión fallida no demuestra que nada haya salido del cliente. Si reconstruye un suceso pasado, identifique el cliente, su configuración, el complemento de autenticación y la etapa que falló. Estimar la exposición a partir del mensaje de error final es adivinar.
Cuando el nombre viene de un túnel
El reenvío de puerto local rompe la comprobación de identidad de una forma que sorprende a la gente. Si reenvía un puerto local a la base de datos y se conecta a localhost, el cliente valida el certificado contra localhost, y no se emitió ningún certificado para ese nombre. La conexión puede ser perfectamente segura y la verificación fallará igualmente, que es la comprobación funcionando como se pretende.
Hay dos respuestas honestas. Dé al extremo reenviado un nombre que resuelva a la dirección de bucle local y aparezca en el certificado del servidor, o use el nombre de host de extremo a extremo para que el cliente verifique la identidad real. La primera es cómoda para los desarrolladores y requiere trabajo de certificados; la segunda es más fácil de razonar y a menudo el valor predeterminado correcto para la automatización. Desactivar la verificación para que funcione el reenvío tira por la borda la propiedad que intentaba añadir.
La aceptación son tres condiciones
Escriba la prueba de aceptación como tres afirmaciones separadas: la conexión usó la ruta prevista, el cifrado era obligatorio y no preferido, y la identidad del servidor se verificó contra material de confianza. Un icono verde de VPN no establece ninguna de ellas.
Para clientes con GUI y para MariaDB, consulte la documentación del propio proveedor en lugar de suponer que la ortografía del indicador se traslada. La documentación de MySQL sobre conexiones cifradas cubre las diferencias entre modos y el requisito de distribución de CA, y es la referencia que debe consultar antes de cambiar una cadena de conexión de producción.