MySQL over en VPN: verifiser serveren, ikke bare krypteringen

Du lagrer en tilkobling til 10.20.4.15, VPN-en faller, og klienten kobler fortsatt til. Det er ikke gode nyheter. En privat adresse er et sted innenfor hvilken som helst rutingkontekst du befinner deg i, og mange nettverk bruker de samme områdene. Klienten nådde en MySQL-server, kanskje bare ikke din.

Rettelsen har to halvdeler, og bare én av dem handler om nettverket. Hold tilkoblingen på den tiltenkte veien, og få klienten til å autentisere serveren den snakker med. Den første halvdelen er der en VPN hjelper; den andre halvdelen må konfigureres.

Kryptert til hva, egentlig?

TLS beskytter samtalen mot alle i midten og sier ingenting om hvem endepunktet påstår å være, med mindre klienten sjekker det. Et sertifikat som valideres mot en klarert myndighet, beviser at sertifikatet kom fra den myndigheten. Det beviser ikke at sertifikatet ble utstedt for vertsnavnet du ville nå, og det er forskjellige spørsmål.

Dette er ikke et teoretisk hull. Captive-portaler, feil med feil VRF og overlappende adresseplaner lager alle en server som er fullstendig villig til å forhandle TLS med deg. Hvis klienten bare krever kryptering, er økten privat og rettet mot feil database.

Så det relevante spørsmålet er ikke om tilkoblingen er kryptert, men om den er kryptert til identiteten du mente. I MySQL-klienten lever den forskjellen utelukkende i innstillingen ssl-mode.

De fem ssl-mode-verdiene i praksis

Det finnes fem verdier, og bare én av dem svarer på spørsmålet i denne kjøreboken. Tabellen lister opp hva hver enkelt faktisk garanterer, i stedet for hva navnet antyder.

Bare den siste raden svarer på spørsmålet i denne artikkelen. PREFERRED er verdt å fremheve for seg selv, fordi en klient som stille faller tilbake til ren tekst er verre enn en som nekter: du tror du har kryptering, og pakkeopptaket er uenig.

En tilkobling du kan kjøre i dag

Kommandoen nedenfor er formen du skal bruke, med to plassholdere: det godkjente databasenavnet og en CA-fil hentet via en godkjent kanal. Ingen av dem bør tas fra 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 uten verdi spør, noe som holder hemmeligheten utenfor prosesslisten og utenfor shell-historikken din. Det er en liten vane med stor gevinst på delte jump-verter, der en kommandolinje er synlig for andre brukere.

Når dette feiler, skiller feilteksten tilfellene bedre enn intuisjon. En CA-feil betyr at kjeden ikke validerer, og du bør se på hvilken CA som signerte serverens sertifikat. En vertsnavnfeil betyr at kjeden er i orden og navnet ikke stemmer, noe som vanligvis betyr at du koblet til riktig server under feil navn i stedet for til feil server.

At en prompt vises, er ikke bevis for at et passord allerede er sendt, og en mislykket tilkobling beviser ikke at ingenting forlot klienten. Hvis du rekonstruerer en tidligere hendelse, identifiser klienten, konfigurasjonen, autentiseringspluginen og trinnet som feilet. Å anslå eksponering fra den siste feilmeldingen er gjetning.

Når navnet kommer fra en tunnel

Videresending av lokal port bryter identitetskontrollen på en måte som overrasker folk. Hvis du videresender en lokal port til databasen og kobler til localhost, validerer klienten sertifikatet mot localhost, og det ble ikke utstedt noe sertifikat for det navnet. Tilkoblingen kan være helt trygg, og verifiseringen vil fortsatt feile, noe som er kontrollen som fungerer som tiltenkt.

Det finnes to ærlige svar. Gi det videresendte endepunktet et navn som løses til loopback-adressen og vises i serverens sertifikat, eller bruk vertsnavnet fra ende til annen slik at klienten verifiserer den ekte identiteten. Det første er praktisk for utviklere og krever sertifikatarbeid; det andre er lettere å tenke gjennom og ofte riktig standard for automatisering. Å slå av verifiseringen for at videresendingen skal virke, kaster bort egenskapen du prøvde å legge til.

Aksept er tre betingelser

Skriv aksepttesten som tre separate utsagn: tilkoblingen brukte den tiltenkte ruten, kryptering var krevd i stedet for foretrukket, og serverens identitet ble verifisert mot klarert materiale. Et grønt VPN-ikon etablerer ingen av dem.

For GUI-klienter og for MariaDB, sjekk leverandørens egen dokumentasjon i stedet for å anta at flaggets stavemåte overføres. MySQL-dokumentasjonen om krypterte tilkoblinger dekker forskjellene mellom modiene og kravet om CA-distribusjon, og det er referansen du bør sjekke før du endrer en produksjonstilkoblingsstreng.