MySQL oer in VPN: ferifiearje de tsjinner, net allinnich de fersifering
Fersifering nei de ferkearde host is noch altyd ferkeard. Ferlykje de ssl-mode-wearden en rin dan in ferbining dy’t de bedoelde tsjinner neamt en dat bewiist.
Jo bewarje in ferbining nei 10.20.4.15, de VPN falt fuort, en de klant ferbynt noch altyd. Dat is gjin goed nijs. In privee-adres is in lokaasje binnen hokker routingkontekst jo ek binne, en in protte netwurken brûke deselde berikken. De klant berikte in MySQL-tsjinner, miskien gewoan net dy fan jo.
De oplossing hat twa helten, en mar ien dêrfan giet oer it netwurk. Hâld de ferbining op har bedoelde paad, en lit de klant de tsjinner ferifiearje wêrmei’t er praat. De earste helt is wêr’t in VPN helpt; de twadde helt moat konfigurearre wurde.
Fersifere nei wat, persiis?
TLS beskermet it petear tsjin elkenien yn ’t midden, en it seit neat oer wa’t it einpunt beweart te wêzen, útsein as de klant it kontrolearret. In sertifikaat dat falidearret tsjin in fertroude autoriteit bewiist dat it sertifikaat fan dy autoriteit kaam. It bewiist net dat it sertifikaat útjûn is foar de hostnamme dy’t jo berikke woene, en dat binne ferskillende fragen.
Dit is gjin teoretyske leechte. Captive-portalen, flaten mei ferkearde VRF en oerlaapjende adresplannen produsearje allegear in tsjinner dy’t folslein ree is om TLS mei jo te ûnderhanneljen. As de klant allinnich fersifering easket, is de sesje privee en rjochte op de ferkearde databank.
Dat is de relevante fraach net oft de ferbining fersifere is, mar oft se fersifere is nei de identiteit dy’t jo bedoelden. Yn ’e MySQL-klant libbet dat ûnderskie folslein yn ’e ynstelling ssl-mode.
De fiif ssl-mode-wearden yn ’e praktyk
Der binne fiif wearden, en mar ien fan har beantwurdet de fraach fan dit hânboek. De tabel listet wat elk eins garandearret, ynstee fan wat syn namme suggerearret.
| 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 |
Allinnich de lêste rigel beantwurdet de fraach yn dit artikel. PREFERRED is op himsels it neamen wurdich, want in klant dy’t stil weromfalt nei platte tekst is slimmer as ien dy’t wegeret: jo leauwe dat jo fersifering hawwe en de pakketopname is it net iens.
In ferbining dy’t jo hjoed útfiere kinne
It kommando hjirûnder is de foarm om te brûken, mei twa plakferfangers: de goedkarde databanknamme en in CA-bestân dat fia in goedkard kanaal krigen is. Gjin fan beide moat nommen wurde út wat de tsjinner jo by it earste kontakt oanbiedt.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sûnder wearde freget om ynfier, wat it geheim bûten de proslist en bûten jo shell-skiednis hâldt. Dat is in lytse gewoante mei in grut fertsjinste op dielde springhosts, wêr’t in kommando-rigel sichtber is foar oare brûkers.
As dit mislearret, ûnderskiedt de flouttekst de gefallen better as yntuysje. In CA-flater betsjut dat de keatling net falidearret en jo moatte sjen hokker CA it tsjinnersertifikaat ûndertekene hat. In hostnamme-flater betsjut dat de keatling yn oarder is en de namme net oerienkomt, wat meastentiids betsjut dat jo mei de juste tsjinner ûnder de ferkearde namme ferbûn binne, net mei de ferkearde tsjinner.
It ferskinen fan in oanfrege is gjin bewiis dat in wachtwurd al ferstjoerd is, en in mislearre ferbining bewiist net dat der neat fan ’e klant fuortgien is. As jo in earder barren rekonstruearje, identifisearje dan de klant, syn konfiguraasje, de autentikaasje-plugin en de faze dy’t mislearre. It bleatstellen skatte út ’e lêste floutmelding is gissen.
As de namme út in tunnel komt
Lokale poartefoarstjoering brekt de identiteitskontrôle op in manier dy’t minsken ferrast. As jo in lokale poarte nei de databank foarstjoere en ferbine mei localhost, falidearret de klant it sertifikaat tsjin localhost, en der is gjin sertifikaat foar dy namme útjûn. De ferbining kin folslein feilich wêze en de ferifikaasje sil dochs mislearje, wat de kontrôle is dy’t wurket sa’t bedoeld.
Der binne twa earlike antwurden. Jou it foarstjoerde einpunt in namme dy’t oplost nei it loopback-adres en yn it tsjinnersertifikaat ferskynt, of brûk de hostnamme fan begjin oant ein sadat de klant de echte identiteit ferifiearret. It earste is handich foar ûntwikkelers en fereasket sertifikaatwurk; it twadde is makliker te beredenearjen en faaks de juste standert foar automatisearring. Ferifikaasje útsette om de foarstjoering wurkje te litten smyt de eigenskip fuort dy’t jo besochten ta te foegjen.
Akseptaasje binne trije betingsten
Skriuw de akseptaasjetest as trije aparte bewearings: de ferbining brûkte de bedoelde rûte, fersifering waard easke en net foarkard, en de identiteit fan ’e tsjinner waard ferifiearre tsjin fertroud materiaal. In grien VPN-ikoan fêstiget gjinien fan har.
Foar GUI-klanten en foar MariaDB, kontrolearje de eigen dokumintaasje fan ’e leveransier ynstee fan oan te nimmen dat de stavering fan ’e flagge oerdroegen wurdt. De MySQL-dokumintaasje oer fersifere ferbiningen behannelt de ferskillen tusken modi en de eask fan CA-distribúsje, en it is de referinsje om te kontrolearjen foardat jo in produksjeferbiningstring feroarje.