MySQL por VPN: verifique o servidor, non só o cifrado
Cifrar cara ao host equivocado segue estando mal. Compare os valores de ssl-mode e logo execute unha conexión que nomee o servidor que pretendía e o demostre.
Vostede garda unha conexión a 10.20.4.15, a VPN cae e o cliente segue conectando. Iso non é unha boa noticia. Un enderezo privado é unha localización dentro de calquera contexto de enrutamento no que se atope, e moitas redes usan os mesmos rangos. O cliente chegou a un servidor MySQL, só que quizais non ao seu.
A solución ten dúas metades, e só unha trata da rede. Manteña a conexión na súa ruta prevista e faga que o cliente autentique o servidor co que fala. A primeira metade é onde axuda unha VPN; a segunda metade hai que configurala.
Cifrado cara a que, exactamente?
TLS protexe a conversa de calquera que estea no medio e non di nada sobre quen di ser o extremo, a non ser que o cliente o comprobe. Un certificado que valida contra unha autoridade de confianza demostra que o certificado provén desa autoridade. Non demostra que o certificado se emitise para o nome de host que vostede pretendía alcanzar, e esas son preguntas distintas.
Non é unha lagoa teórica. Os portais cativos, os erros de VRF equivocado e os plans de enderezos solapados producen todos un servidor perfectamente disposto a negociar TLS con vostede. Se o cliente só esixe cifrado, a sesión é privada e apunta á base de datos equivocada.
Así que a pregunta pertinente non é se a conexión está cifrada, senón se o está cara á identidade que vostede pretendía. No cliente de MySQL, esa distinción vive por completo no axuste ssl-mode.
Os cinco valores de ssl-mode na práctica
Existen cinco valores, e só un deles responde á pregunta deste manual. A táboa enumera o que cada un garante en realidade, en lugar do que suxire o seu nome.
| 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 |
Só a última fila responde á pregunta deste artigo. PREFERRED merece sinalarse por si só, porque un cliente que cae en silencio a texto plano é peor que un que se nega: vostede cre ter cifrado e a captura de paquetes non está de acordo.
Unha conexión que pode executar hoxe
O comando de abaixo é a forma que debe usar, con dous marcadores: o nome de base de datos aprobado e un ficheiro CA obtido por unha canle aprobada. Ningún dos dous debería tomarse do que o servidor lle ofreza no primeiro contacto.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sen valor pide entrada, o que mantén o segredo fóra da lista de procesos e fóra do historial da súa shell. É un hábito pequeno cun gran beneficio en hosts de salto compartidos, onde unha liña de comandos é visible para outros usuarios.
Cando isto falla, o texto do erro distingue os casos mellor que a intuición. Un fallo de CA significa que a cadea non valida e debería mirar que CA asinou o certificado do servidor. Un fallo de nome de host significa que a cadea está ben e o nome non coincide, o que normalmente significa que se conectou ao servidor correcto co nome equivocado, non ao servidor equivocado.
Que apareza unha solicitude non é proba de que un contrasinal xa se transmitise, e unha conexión fallida non demostra que nada saíse do cliente. Se reconstrúe un suceso pasado, identifique o cliente, a súa configuración, o complemento de autenticación e a etapa que fallou. Estimar a exposición a partir da mensaxe de erro final é adiviñar.
Cando o nome vén dun túnel
O reenvío de porto local rompe a comprobación de identidade dun xeito que sorprende á xente. Se reenvía un porto local á base de datos e se conecta a localhost, o cliente valida o certificado contra localhost, e non se emitiu ningún certificado para ese nome. A conexión pode ser perfectamente segura e a verificación fallará igualmente, que é a comprobación funcionando como se pretende.
Hai dúas respostas honestas. Déalle ao extremo reenviado un nome que resolva ao enderezo de bucle local e apareza no certificado do servidor, ou use o nome de host de extremo a extremo para que o cliente verifique a identidade real. A primeira é cómoda para os desenvolvedores e require traballo de certificados; a segunda é máis fácil de razoar e a miúdo o valor predeterminado correcto para a automatización. Desactivar a verificación para que funcione o reenvío tira pola borda a propiedade que intentaba engadir.
A aceptación son tres condicións
Escriba a proba de aceptación como tres afirmacións separadas: a conexión usou a ruta prevista, o cifrado era obrigatorio e non preferido, e a identidade do servidor verificouse contra material de confianza. Unha icona verde de VPN non establece ningunha delas.
Para clientes con GUI e para MariaDB, consulte a documentación do propio provedor en lugar de supor que a ortografía do indicador se traslada. A documentación de MySQL sobre conexións cifradas cobre as diferenzas entre modos e o requisito de distribución de CA, e é a referencia que debe consultar antes de cambiar unha cadea de conexión de produción.