MySQL per VPN: verifiqueu el servidor, no només el xifratge
Xifrar cap a l’amfitrió equivocat continua sent un error. Compareu els valors d’ssl-mode i després executeu una connexió que anomeni el servidor que volíeu i ho demostri.
Deseu una connexió a 10.20.4.15, la VPN cau i el client continua connectant-se. Això no és una bona notícia. Una adreça privada és una ubicació dins de qualsevol context d’encaminament en què us trobeu, i moltes xarxes utilitzen els mateixos rangs. El client ha arribat a un servidor MySQL, només potser no al vostre.
La solució té dues meitats, i només una tracta de la xarxa. Manteniu la connexió en el camí previst i feu que el client autentiqui el servidor amb qui parla. La primera meitat és on ajuda una VPN; la segona s’ha de configurar.
Xifrat cap a què, exactament?
TLS protegeix la conversa de qualsevol que hi hagi al mig i no diu res sobre qui diu ser el punt final, tret que el client ho comprovi. Un certificat que valida contra una autoritat de confiança demostra que el certificat prové d’aquesta autoritat. No demostra que el certificat s’hagi emès per al nom d’amfitrió que volíeu assolir, i aquestes són preguntes diferents.
No és una escletxa teòrica. Els portals captius, els errors de VRF equivocat i els plans d’adreces superposats produeixen tots un servidor perfectament disposat a negociar TLS amb vosaltres. Si el client només exigeix xifratge, la sessió és privada i apunta a la base de dades equivocada.
Així, la pregunta rellevant no és si la connexió està xifrada, sinó si ho està cap a la identitat que volíeu. Al client de MySQL, aquesta distinció viu completament al paràmetre ssl-mode.
Els cinc valors d’ssl-mode a la pràctica
Hi ha cinc valors, i només un d’ells respon la pregunta d’aquest manual. La taula llista què garanteix realment cadascun, no què suggereix el seu nom.
| 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 |
Només l’última fila respon la pregunta d’aquest article. PREFERRED val la pena destacar-lo per si mateix, perquè un client que baixa silenciosament a text pla és pitjor que un que refusa: creieu que teniu xifratge i la captura de paquets no hi està d’acord.
Una connexió que podeu executar avui
L’ordre de sota és la forma que cal utilitzar, amb dos marcadors: el nom de base de dades aprovat i un fitxer CA obtingut per un canal aprovat. Cap dels dos no s’ha de prendre del que el servidor us ofereixi en el primer contacte.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sense valor demana entrada, cosa que manté el secret fora de la llista de processos i de l’historial de l’intèrpret. És un costum petit amb un gran rendiment en amfitrions de salt compartits, on la línia d’ordres és visible per a altres usuaris.
Quan això falla, el text de l’error distingeix els casos millor que la intuïció. Una fallada de CA vol dir que la cadena no valida i cal mirar quina CA ha signat el certificat del servidor. Una fallada de nom d’amfitrió vol dir que la cadena està bé i el nom no coincideix, cosa que normalment vol dir que us heu connectat al servidor correcte amb el nom equivocat, no al servidor equivocat.
Que aparegui un avís no és prova que una contrasenya ja s’hagi transmès, i una connexió fallida no demostra que no hagi sortit res del client. Si reconstruïu un esdeveniment passat, identifiqueu el client, la seva configuració, el connector d’autenticació i l’etapa que va fallar. Estimar l’exposició a partir del missatge d’error final és endevinar.
Quan el nom ve d’un túnel
El reenviament de port local trenca la comprovació d’identitat d’una manera que sorprèn la gent. Si reenvieu un port local a la base de dades i us connecteu a localhost, el client valida el certificat contra localhost, i no es va emetre cap certificat per a aquest nom. La connexió pot ser perfectament segura i la verificació fallarà igualment, que és la comprovació funcionant com cal.
Hi ha dues respostes honestes. Donar al punt final reenviat un nom que resolgui a l’adreça de bucle local i aparegui al certificat del servidor, o utilitzar el nom d’amfitrió d’extrem a extrem perquè el client verifiqui la identitat real. La primera és convenient per als desenvolupadors i requereix feina de certificats; la segona és més fàcil de raonar i sovint és el valor per defecte correcte per a l’automatització. Desactivar la verificació perquè el reenviament funcioni llença la propietat que intentàveu afegir.
L’acceptació són tres condicions
Escriviu la prova d’acceptació com tres afirmacions separades: la connexió va utilitzar la ruta prevista, el xifratge era obligatori i no preferit, i la identitat del servidor es va verificar contra material de confiança. Una icona verda de VPN no n’estableix cap.
Per als clients amb GUI i per a MariaDB, consulteu la documentació del mateix proveïdor en lloc de suposar que l’ortografia del paràmetre es trasllada. La documentació de MySQL sobre connexions xifrades cobreix les diferències entre modes i el requisit de distribució de CA, i és la referència que cal consultar abans de canviar una cadena de connexió de producció.