MySQL via een VPN: verifieer de server, niet alleen de versleuteling
Versleuteling naar de verkeerde host is nog steeds verkeerd. Vergelijk de ssl-mode-waarden en voer dan een verbinding uit die de bedoelde server noemt en dat bewijst.
U slaat een verbinding op naar 10.20.4.15, de VPN valt weg en de client maakt nog steeds verbinding. Dat is geen goed nieuws. Een privéadres is een locatie binnen welke routeringscontext u zich ook bevindt, en veel netwerken gebruiken dezelfde bereiken. De client bereikte een MySQL-server, misschien alleen niet de uwe.
De oplossing heeft twee helften, en slechts één daarvan gaat over het netwerk. Houd de verbinding op het beoogde pad en laat de client de server authenticeren waarmee hij praat. De eerste helft is waar een VPN helpt; de tweede helft moet worden geconfigureerd.
Versleuteld naar wat, precies?
TLS beschermt het gesprek tegen iedereen in het midden en zegt niets over wie het eindpunt beweert te zijn, tenzij de client dat controleert. Een certificaat dat valideert tegen een vertrouwde autoriteit bewijst dat het certificaat van die autoriteit afkomstig is. Het bewijst niet dat het certificaat is uitgegeven voor de hostnaam die u wilde bereiken, en dat zijn verschillende vragen.
Dit is geen theoretisch gat. Captive portals, fouten met de verkeerde VRF en overlappende adresplannen produceren allemaal een server die volstrekt bereid is om TLS met u te onderhandelen. Als de client alleen versleuteling eist, is de sessie privé en op de verkeerde database gericht.
De relevante vraag is dus niet of de verbinding versleuteld is, maar of die is versleuteld naar de identiteit die u bedoelde. In de MySQL-client leeft dat onderscheid volledig in de instelling ssl-mode.
De vijf ssl-mode-waarden in de praktijk
Er bestaan vijf waarden, en slechts één ervan beantwoordt de vraag van deze handleiding. De tabel vermeldt wat elk werkelijk garandeert, in plaats van wat de naam suggereert.
| 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 |
Alleen de laatste rij beantwoordt de vraag in dit artikel. PREFERRED is op zichzelf het vermelden waard, want een client die stil terugvalt op platte tekst is erger dan een die weigert: u gelooft dat u versleuteling hebt en de pakketopname is het daar niet mee eens.
Een verbinding die u vandaag kunt uitvoeren
De opdracht hieronder is de vorm die u moet gebruiken, met twee plaatsaanduidingen: de goedgekeurde databasenaam en een CA-bestand dat via een goedgekeurd kanaal is verkregen. Geen van beide mag worden overgenomen uit wat de server u bij het eerste contact aanbiedt.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password zonder waarde vraagt om invoer, wat het geheim buiten de processenlijst en buiten uw shellgeschiedenis houdt. Dat is een kleine gewoonte met een grote opbrengst op gedeelde jumphosts, waar een opdrachtregel zichtbaar is voor andere gebruikers.
Wanneer dit mislukt, onderscheidt de fouttekst de gevallen beter dan intuïtie. Een CA-fout betekent dat de keten niet valideert en u moet kijken welke CA het servercertificaat heeft ondertekend. Een hostnaamfout betekent dat de keten in orde is en de naam niet overeenkomt, wat meestal betekent dat u verbinding maakte met de juiste server onder de verkeerde naam in plaats van met de verkeerde server.
Dat een prompt verschijnt, is geen bewijs dat een wachtwoord al is verzonden, en een mislukte verbinding bewijst niet dat er niets de client heeft verlaten. Als u een eerdere gebeurtenis reconstrueert, identificeer dan de client, de configuratie, de authenticatieplugin en de fase die mislukte. Blootstelling schatten op basis van de laatste foutmelding is gissen.
Wanneer de naam uit een tunnel komt
Lokale port forwarding breekt de identiteitscontrole op een manier die mensen verrast. Als u een lokale poort naar de database doorstuurt en verbinding maakt met localhost, valideert de client het certificaat tegen localhost, en er is geen certificaat voor die naam uitgegeven. De verbinding kan volkomen veilig zijn en de verificatie zal toch mislukken, wat de controle is die werkt zoals bedoeld.
Er zijn twee eerlijke antwoorden. Geef het doorgestuurde eindpunt een naam die naar het loopbackadres resolvet en in het servercertificaat voorkomt, of gebruik de hostnaam van begin tot eind zodat de client de echte identiteit verifieert. Het eerste is handig voor ontwikkelaars en vereist certificaatwerk; het tweede is eenvoudiger te beredeneren en vaak de juiste standaard voor automatisering. Verificatie uitschakelen om de doorsturing te laten werken gooit de eigenschap weg die u probeerde toe te voegen.
Acceptatie is drie voorwaarden
Schrijf de acceptatietest als drie afzonderlijke uitspraken: de verbinding gebruikte de beoogde route, versleuteling was vereist en niet preferent, en de identiteit van de server werd geverifieerd tegen vertrouwd materiaal. Een groen VPN-pictogram stelt geen van alle vast.
Controleer voor GUI-clients en voor MariaDB de eigen documentatie van de leverancier in plaats van aan te nemen dat de spelling van de vlag overkomt. De MySQL-documentatie over versleutelde verbindingen behandelt de verschillen tussen modi en de eis van CA-distributie, en het is de referentie die u controleert voordat u een productieverbindingsreeks wijzigt.