MySQL over ein VPN: stadfest serveren, ikkje berre krypteringa
Kryptering til feil vert er framleis feil. Samanlikn ssl-mode-verdiane, og køyr deretter ei tilkopling som namngjev serveren du meinte, og provar det.
Du lagrar ei tilkopling til 10.20.4.15, VPN-en fell, og klienten koplar framleis til. Det er ikkje gode nyhende. Ei privat adresse er ein stad innanfor kva som helst rutekontekst du er i, og mange nettverk brukar dei same områda. Klienten nådde ein MySQL-server, kanskje berre ikkje din.
Rettinga har to halvdelar, og berre éin av dei handlar om nettverket. Hald tilkoplinga på den tiltenkte vegen, og få klienten til å autentisere serveren han snakkar med. Den første halvdelen er der ein VPN hjelper; den andre halvdelen må konfigurerast.
Kryptert til kva, eigentleg?
TLS vernar samtalen mot alle i midten og seier ingenting om kven endepunktet påstår å vere, med mindre klienten sjekkar det. Eit sertifikat som validerer mot ei klarert styresmakt, provar at sertifikatet kom frå den styresmakta. Det provar ikkje at sertifikatet vart gjeve ut for vertsnamnet du ville nå, og det er ulike spørsmål.
Dette er ikkje eit teoretisk hol. Captive-portalar, feil med feil VRF og overlappande adresseplanar lagar alle ein server som er fullstendig viljug til å forhandle TLS med deg. Viss klienten berre krev kryptering, er økta privat og retta mot feil database.
Så det relevante spørsmålet er ikkje om tilkoplinga er kryptert, men om ho er kryptert til identiteten du meinte. I MySQL-klienten lever den skilnaden utelukkande i innstillinga ssl-mode.
Dei fem ssl-mode-verdiane i praksis
Det finst fem verdiar, og berre éin av dei svarar på spørsmålet i denne køyreboka. Tabellen listar opp kva kvar einskild faktisk garanterer, i staden for kva namnet antydar.
| 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 |
Berre den siste rada svarar på spørsmålet i denne artikkelen. PREFERRED er verdt å framheve for seg sjølv, fordi ein klient som stille fell tilbake til rein tekst er verre enn ein som nektar: du trur du har kryptering, og pakkeopptaket er usamd.
Ei tilkopling du kan køyre i dag
Kommandoen nedanfor er forma du skal bruke, med to plasshaldarar: det godkjende databasenamnet og ei CA-fil henta via ein godkjend kanal. Ingen av dei bør takast frå det serveren tilbyr deg ved første kontakt.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password
--password utan verdi spør, noko som held hemmelegheita utanfor prosesslista og utanfor shell-historia di. Det er ein liten vane med stor gevinst på delte jump-vertar, der ei kommandolinje er synleg for andre brukarar.
Når dette feilar, skil feilteksten tilfella betre enn intuisjon. Ein CA-feil tyder at kjeda ikkje validerer, og du bør sjå kva CA som signerte serverens sertifikat. Ein vertsnamnfeil tyder at kjeda er i orden og namnet ikkje stemmer, noko som vanlegvis tyder at du kopla til rett server under feil namn i staden for til feil server.
At ein prompt viser seg, er ikkje bevis for at eit passord alt er sendt, og ei mislukka tilkopling provar ikkje at ingenting forlét klienten. Viss du rekonstruerer ei tidlegare hending, identifiser klienten, konfigurasjonen, autentiseringspluginen og trinnet som feila. Å anslå eksponering frå den siste feilmeldinga er gissing.
Når namnet kjem frå ein tunnel
Vidaresending av lokal port bryt identitetskontrollen på ein måte som overraskar folk. Viss du vidaresender ein lokal port til databasen og koplar til localhost, validerer klienten sertifikatet mot localhost, og det vart ikkje gjeve ut noko sertifikat for det namnet. Tilkoplinga kan vere heilt trygg, og stadfestinga vil framleis feile, noko som er kontrollen som fungerer som tiltenkt.
Det finst to ærlege svar. Gje det vidaresende endepunktet eit namn som løyser til loopback-adressa og visest i serverens sertifikat, eller bruk vertsnamnet frå ende til annan slik at klienten stadfestar den ekte identiteten. Det første er praktisk for utviklarar og krev sertifikatarbeid; det andre er lettare å tenkje gjennom og ofte rett standard for automatisering. Å slå av stadfestinga for at vidaresendinga skal verke, kastar bort eigenskapen du prøvde å leggje til.
Godtaking er tre vilkår
Skriv godtakingstesten som tre separate utsegner: tilkoplinga brukte den tiltenkte ruta, kryptering var kravd i staden for føretrekt, og identiteten til serveren vart stadfesta mot klarert materiale. Eit grønt VPN-ikon etablerer ingen av dei.
For GUI-klientar og for MariaDB, sjekk dokumentasjonen til leverandøren sjølv i staden for å gå ut frå at stavemåten til flagget blir overført. MySQL-dokumentasjonen om krypterte tilkoplingar dekkjer skilnadene mellom modiane og kravet om CA-distribusjon, og det er referansen du bør sjekke før du endrar ein produksjonstilkoplingsstreng.