MySQL over en VPN: bekræft serveren, ikke bare krypteringen
Kryptering til den forkerte vært er stadig forkert. Sammenlign ssl-mode-værdierne, og kør derefter en forbindelse, der navngiver den server, du mente, og beviser det.
Du gemmer en forbindelse til 10.20.4.15, VPN’en falder, og klienten forbinder stadig. Det er ikke godt nyt. En privat adresse er en placering inde i hvilken som helst routingkontekst, du befinder dig i, og mange netværk bruger de samme intervaller. Klienten nåede en MySQL-server, måske bare ikke din.
Rettelsen har to halvdele, og kun den ene handler om netværket. Hold forbindelsen på dens tilsigtede vej, og få klienten til at godkende den server, den taler med. Den første halvdel er, hvor en VPN hjælper; den anden halvdel skal konfigureres.
Krypteret til hvad, præcis?
TLS beskytter samtalen mod enhver i midten og siger intet om, hvem endepunktet påstår at være, medmindre klienten kontrollerer det. Et certifikat, der valideres mod en betroet myndighed, beviser, at certifikatet kom fra den myndighed. Det beviser ikke, at certifikatet blev udstedt til det værtsnavn, du ville nå, og det er forskellige spørgsmål.
Det er ikke et teoretisk hul. Captive-portaler, fejl med forkert VRF og overlappende adresseplaner skaber alle en server, der er fuldstændig villig til at forhandle TLS med dig. Hvis klienten kun kræver kryptering, er sessionen privat og peget på den forkerte database.
Så det relevante spørgsmål er ikke, om forbindelsen er krypteret, men om den er krypteret til den identitet, du havde til hensigt. I MySQL’s klient ligger denne forskel udelukkende i indstillingen ssl-mode.
De fem ssl-mode-værdier i praksis
Der findes fem værdier, og kun én af dem besvarer spørgsmålet i denne kørebog. Tabellen angiver, hvad hver især faktisk garanterer, snarere end hvad navnet antyder.
| 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 |
Kun den sidste række besvarer spørgsmålet i denne artikel. PREFERRED er værd at fremhæve i sig selv, fordi en klient, der lydløst falder tilbage til klartekst, er værre end en, der afviser: du tror, du har kryptering, og pakkeoptagelsen er uenig.
En forbindelse, du kan køre i dag
Kommandoen nedenfor er den form, du skal bruge, med to pladsholdere: det godkendte databasenavn og en CA-fil hentet via en godkendt kanal. Ingen af dem bør tages fra det, serveren tilbyder dig ved første kontakt.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password uden værdi spørger, hvilket holder hemmeligheden ude af proceslisten og ude af din shell-historik. Det er en lille vane med stor gevinst på delte jump-hosts, hvor en kommandolinje er synlig for andre brugere.
Når dette fejler, skelner fejlteksten tilfældene bedre end intuitionen. En CA-fejl betyder, at kæden ikke validerer, og du bør se på, hvilken CA der signerede servercertifikatet. En værtsnavnefejl betyder, at kæden er fin, og navnet ikke stemmer, hvilket normalt betyder, at du oprettede forbindelse til den rigtige server under det forkerte navn snarere end til den forkerte server.
At en prompt vises, er ikke bevis for, at en adgangskode allerede er sendt, og en mislykket forbindelse beviser ikke, at intet forlod klienten. Hvis du rekonstruerer en tidligere hændelse, skal du identificere klienten, dens konfiguration, godkendelsespluginnet og det trin, der fejlede. At estimere eksponering ud fra den endelige fejlmeddelelse er gætværk.
Når navnet kommer fra en tunnel
Videresendelse af lokale porte bryder identitetskontrollen på en måde, der overrasker folk. Hvis du videresender en lokal port til databasen og forbinder til localhost, validerer klienten certifikatet mod localhost, og der blev ikke udstedt noget certifikat til det navn. Forbindelsen kan være helt sikker, og verifikationen vil stadig fejle, hvilket er kontrollen, der virker som tilsigtet.
Der er to ærlige svar. Giv det videresendte endepunkt et navn, der opløses til loopback-adressen og optræder i servercertifikatet, eller brug værtsnavnet fra ende til anden, så klienten bekræfter den rigtige identitet. Det første er praktisk for udviklere og kræver certifikatarbejde; det andet er lettere at tænke over og ofte den rigtige standard for automatisering. At slå verifikation fra for at få videresendelsen til at virke smider den egenskab væk, du prøvede at tilføje.
Accept er tre betingelser
Skriv accepttesten som tre separate udsagn: forbindelsen brugte den tilsigtede rute, kryptering var krævet snarere end foretrukket, og serverens identitet blev bekræftet mod betroet materiale. Et grønt VPN-ikon etablerer ingen af dem.
For GUI-klienter og for MariaDB skal du tjekke leverandørens egen dokumentation i stedet for at antage, at flagets stavemåde overføres. MySQL-dokumentationen om krypterede forbindelser dækker forskellene mellem tilstandene og kravet om CA-distribution, og det er den reference, du skal tjekke, før du ændrer en produktionsforbindelsesstreng.