MySQL över en VPN: verifiera servern, inte bara krypteringen
Kryptering till fel värd är fortfarande fel. Jämför ssl-mode-värdena och kör sedan en anslutning som namnger den avsedda servern och bevisar det.
Du sparar en anslutning till 10.20.4.15, VPN:en faller och klienten ansluter ändå. Det är inte goda nyheter. En privat adress är en plats inom vilken routingkontext du än befinner dig i, och många nätverk använder samma intervall. Klienten nådde en MySQL-server, kanske bara inte din.
Rättningen har två halvor, och bara en av dem handlar om nätverket. Håll anslutningen på sin avsedda väg och låt klienten autentisera servern den pratar med. Den första halvan är där en VPN hjälper; den andra måste konfigureras.
Krypterat till vad, exakt?
TLS skyddar samtalet från alla i mitten och säger ingenting om vem slutpunkten påstår sig vara, om inte klienten kontrollerar det. Ett certifikat som validerar mot en betrodd myndighet bevisar att certifikatet kom från den myndigheten. Det bevisar inte att certifikatet utfärdades för det värdnamn du ville nå, och det är olika frågor.
Detta är inte en teoretisk lucka. Captive-portaler, fel med fel VRF och överlappande adressplaner skapar alla en server som är helt villig att förhandla TLS med dig. Om klienten bara kräver kryptering är sessionen privat och riktad mot fel databas.
Så den relevanta frågan är inte om anslutningen är krypterad, utan om den är krypterad till den identitet du avsåg. I MySQL-klienten lever den skillnaden helt och hållet i inställningen ssl-mode.
De fem ssl-mode-värdena i praktiken
Det finns fem värden, och bara ett av dem svarar på frågan i den här handboken. Tabellen listar vad vart och ett faktiskt garanterar, i stället för vad namnet 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 |
Bara den sista raden svarar på frågan i den här artikeln. PREFERRED är värt att lyfta fram för sig, eftersom en klient som tyst faller tillbaka till klartext är sämre än en som vägrar: du tror att du har kryptering och paketinsamlingen håller inte med.
En anslutning du kan köra i dag
Kommandot nedan är formen att använda, med två platshållare: det godkända databasnamnet och en CA-fil som hämtats via en godkänd kanal. Ingen av dem bör tas från det servern erbjuder vid första kontakten.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password utan värde frågar efter inmatning, vilket håller hemligheten utanför processlistan och utanför din skalhistorik. Det är en liten vana med stor vinst på delade jump-värdar, där en kommandorad är synlig för andra användare.
När detta misslyckas skiljer feltexten fallen bättre än intuition. Ett CA-fel betyder att kedjan inte validerar och du bör titta på vilken CA som signerade serverns certifikat. Ett värdnamnsfel betyder att kedjan är i ordning och namnet inte stämmer, vilket oftast betyder att du anslöt till rätt server under fel namn i stället för till fel server.
Att en prompt visas är inte bevis för att ett lösenord redan sänts, och en misslyckad anslutning bevisar inte att ingenting lämnade klienten. Om du rekonstruerar en tidigare händelse, identifiera klienten, dess konfiguration, autentiseringspluginen och steget som misslyckades. Att uppskatta exponering från det sista felmeddelandet är gissningar.
När namnet kommer från en tunnel
Lokal portvidarebefordran bryter identitetskontrollen på ett sätt som överraskar folk. Om du vidarebefordrar en lokal port till databasen och ansluter till localhost, validerar klienten certifikatet mot localhost, och det utfärdades inget certifikat för det namnet. Anslutningen kan vara helt säker och verifieringen kommer ändå att misslyckas, vilket är kontrollen som fungerar som avsett.
Det finns två ärliga svar. Ge den vidarebefordrade slutpunkten ett namn som löses till loopback-adressen och förekommer i serverns certifikat, eller använd värdnamnet från början till slut så att klienten verifierar den verkliga identiteten. Det första är bekvämt för utvecklare och kräver certifikatarbete; det andra är lättare att resonera om och ofta rätt standard för automatisering. Att stänga av verifieringen för att vidarebefordran ska fungera kastar bort egenskapen du försökte lägga till.
Acceptans är tre villkor
Skriv acceptanstestet som tre separata påståenden: anslutningen använde den avsedda vägen, kryptering krävdes i stället för föredrogs, och serverns identitet verifierades mot betrott material. En grön VPN-ikon etablerar ingen av dem.
För GUI-klienter och för MariaDB, kontrollera leverantörens egen dokumentation i stället för att anta att flaggans stavning överförs. MySQL-dokumentationen om krypterade anslutningar täcker skillnaderna mellan lägena och kravet på CA-distribution, och det är referensen du bör kontrollera innan du ändrar en produktionsanslutningssträng.