MySQL oor 'n VPN: verifieer die bediener, nie net die enkripsie nie
Om na die verkeerde gasheer te enkripteer bly verkeerd. Vergelyk die ssl-mode-waardes en voer dan 'n verbinding uit wat die bediener noem wat jy bedoel het en dit bewys.
Jy stoor 'n verbinding na 10.20.4.15, die VPN val weg, en die kliënt maak steeds verbinding. Dit is nie goeie nuus nie. 'n Privaat adres is 'n plek binne watter roeteringskonteks jy ook al is, en baie netwerke gebruik dieselfde reekse. Die kliënt het 'n MySQL-bediener bereik, dit het net dalk nie joune bereik nie.
Die oplossing het twee helftes, en net een daarvan gaan oor die netwerk. Hou die verbinding op sy beoogde pad, en laat die kliënt die bediener verifieer waarmee hy praat. Die eerste helfte is waar 'n VPN help; die tweede helfte moet opgestel word.
Geënkripteer na wat, presies?
TLS beskerm die gesprek teen enigiemand in die middel, en dit sê niks oor wie die eindpunt beweer hy is nie, tensy die kliënt dit nagaan. 'n Sertifikaat wat teen 'n vertroude owerheid valideer, bewys dat die sertifikaat van daardie owerheid kom. Dit bewys nie dat die sertifikaat uitgereik is vir die gasheernaam wat jy wou bereik nie, en dit is verskillende vrae.
Dit is nie 'n teoretiese leemte nie. Captive portals, verkeerde-VRF-foute en oorvleuelende adresplanne lewer almal 'n bediener wat heeltemal gewillig is om TLS met jou te onderhandel. As die kliënt net enkripsie vereis, is die sessie privaat en op die verkeerde databasis gerig.
Die relevante vraag is dus nie of die verbinding geënkripteer is nie, maar of dit na die identiteit geënkripteer is wat jy bedoel het. In MySQL se kliënt woon daardie onderskeid heeltemal in die ssl-mode-instelling.
Die vyf ssl-mode-waardes in die praktyk
Vyf waardes bestaan, en net een van hulle beantwoord die vraag waaroor hierdie runbook gaan. Die tabel lys wat elkeen werklik waarborg eerder as wat sy naam voorstel.
| 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 |
Net die laaste ry beantwoord die vraag in hierdie artikel. PREFERRED is op sy eie die moeite werd om uit te lig, want 'n kliënt wat stilweg na gewone teks terugval, is erger as een wat weier: jy glo jy het enkripsie en die pakkie-opname stem nie saam nie.
'n Verbinding wat jy vandag kan uitvoer
Die opdrag hieronder is die vorm om te gebruik, met twee plekhouers: die goedgekeurde databasenaam en 'n CA-lêer wat deur 'n goedgekeurde kanaal verkry is. Nie een moet geneem word uit wat die bediener jou by die eerste kontak aanbied nie.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sonder 'n waarde vra om invoer, wat die geheim uit die proseslys en uit jou dopgeskiedenis hou. Dit is 'n klein gewoonte met 'n groot opbrengs op gedeelde spronggashere, waar 'n opdraglyn vir ander gebruikers sigbaar is.
Wanneer dit misluk, onderskei die foutteks die gevalle beter as intuïsie. 'n CA-fout beteken die ketting valideer nie, en jy moet kyk watter CA die bedienaarsertifikaat onderteken het. 'n Gasheernaamfout beteken die ketting is reg en die naam stem nie ooreen nie, wat gewoonlik beteken jy het die regte bediener onder die verkeerde naam bereik eerder as die verkeerde bediener.
'n Aanvraag wat verskyn, is nie bewys dat 'n wagwoord reeds gestuur is nie, en 'n mislukte verbinding bewys nie dat niks die kliënt verlaat het nie. As jy 'n vorige gebeurtenis rekonstrueer, identifiseer die kliënt, sy konfigurasie, die verifikasie-inprop en die stadium wat gefaal het. Om blootstelling uit die finale foutboodskap te skat, is giswerk.
Wanneer die naam uit 'n tonnel kom
Plaaslike poortaanstuur breek die identiteitskontrole op 'n manier wat mense verras. As jy 'n plaaslike poort na die databasis aanstuur en aan localhost, valideer die kliënt die sertifikaat teen localhost, en geen sertifikaat is vir daardie naam uitgereik nie. Die verbinding kan heeltemal veilig wees en die verifikasie sal steeds misluk, wat die kontrole is wat werk soos bedoel.
Daar is twee eerlike antwoorde. Gee die aangestuurde eindpunt 'n naam wat na die loopback-adres oplos en in die bedienaarsertifikaat voorkom, of gebruik die gasheernaam van begin tot eind sodat die kliënt die werklike identiteit verifieer. Die eerste is gerieflik vir ontwikkelaars en vereis sertifikaatwerk; die tweede is makliker om oor te redeneer en dikwels die regte verstek vir outomatisering. Om verifikasie te deaktiveer om die aanstuur te laat werk, gooi die eienskap weg wat jy probeer byvoeg het.
Aanvaarding is drie voorwaardes
Skryf die aanvaardingstoets as drie afsonderlike stellings: die verbinding het die beoogde roete gebruik, enkripsie was vereis eerder as verkies, en die bedieneridentiteit is teen vertroude materiaal geverifieer. 'n Groen VPN-ikoon vestig nie een daarvan nie.
Vir GUI-kliënte en vir MariaDB, kyk na die verskaffer se eie dokumentasie eerder as om aan te neem die vlagspelling dra oor. Die MySQL-dokumentasie oor geënkripteerde verbindings dek die modusverskille en die CA-verspreidingsvereiste, en dit is die verwysing om na te gaan voordat jy 'n produksieverbindingstring verander.