MySQL preko VPN-a: provjerite server, a ne samo enkripciju
Enkripcija prema pogrešnom hostu i dalje je pogrešna. Uporedite vrijednosti ssl-mode, zatim pokrenite vezu koja imenuje server koji ste željeli i to dokazuje.
Spremate vezu na 10.20.4.15, VPN se prekida, a klijent se i dalje povezuje. To nije dobra vijest. Privatna adresa je mjesto unutar bilo kojeg konteksta usmjeravanja u kojem se nalazite, a mnoge mreže koriste iste raspone. Klijent je stigao do MySQL servera, samo možda ne do vašeg.
Popravka ima dvije polovine, a samo jedna je o mreži. Držite vezu na predviđenoj putanji i natjerajte klijenta da provjeri server s kojim razgovara. Prva polovina je mjesto gdje VPN pomaže; druga se mora konfigurirati.
Enkriptirano prema čemu, tačno?
TLS štiti razgovor od svakoga u sredini i ne govori ništa o tome kim se krajnja točka predstavlja, osim ako klijent to ne provjeri. Certifikat koji se validira kod pouzdanog tijela dokazuje da certifikat dolazi od tog tijela. Ne dokazuje da je certifikat izdan za ime hosta koje ste htjeli dosegnuti, a to su različita pitanja.
To nije teoretska praznina. Captive portali, greške s pogrešnim VRF-om i preklapajući planovi adresa svi stvaraju server koji je potpuno spreman pregovarati TLS s vama. Ako klijent zahtijeva samo enkripciju, sesija je privatna i usmjerena na pogrešnu bazu podataka.
Dakle, relevantno pitanje nije je li veza enkriptirana, nego je li enkriptirana prema identitetu koji ste namjeravali. U MySQL klijentu ta razlika u potpunosti živi u postavci ssl-mode.
Pet vrijednosti ssl-mode u praksi
Postoji pet vrijednosti, a samo jedna od njih odgovara na pitanje ovog priručnika. Tabela navodi šta svaka zapravo garantuje, a ne šta njeno ime sugerira.
| 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 |
Samo posljednji red odgovara na pitanje u ovom članku. PREFERRED vrijedi posebno istaknuti, jer klijent koji tiho prelazi na običan tekst gori je od onog koji odbija: vjerujete da imate enkripciju, a snimak paketa se ne slaže.
Veza koju možete izvršiti danas
Naredba ispod je oblik koji treba koristiti, s dva rezervisana mjesta: odobreno ime baze podataka i CA datoteka dobijena kroz odobreni kanal. Nijedno se ne smije uzeti iz onoga što vam server ponudi pri prvom kontaktu.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password bez vrijednosti traži unos, što čuva tajnu izvan liste procesa i izvan vaše historije ljuske. To je mala navika s velikom koristi na dijeljenim jump hostovima, gdje je komandna linija vidljiva drugim korisnicima.
Kada to ne uspije, tekst greške razlikuje slučajeve bolje od intuicije. Greška CA znači da se lanac ne validira i treba gledati koji CA je potpisao certifikat servera. Greška imena hosta znači da je lanac u redu, a ime se ne poklapa, što obično znači da ste se povezali na ispravan server pod pogrešnim imenom, a ne na pogrešan server.
Pojava upita nije dokaz da je lozinka već poslana, a neuspješna veza ne dokazuje da ništa nije napustilo klijenta. Ako rekonstruišete prošli događaj, identificirajte klijenta, njegovu konfiguraciju, dodatak za autentifikaciju i fazu koja je neuspjela. Procjena izloženosti iz konačne poruke o grešci je nagađanje.
Kada ime dolazi iz tunela
Lokalno prosljeđivanje portova kvari provjeru identiteta na način koji iznenađuje ljude. Ako proslijedite lokalni port na bazu podataka i povežete se na localhost, klijent validira certifikat prema localhost, a certifikat nije izdan za to ime. Veza može biti potpuno sigurna, a provjera će ipak neuspjeti, što znači da provjera radi kako je predviđeno.
Postoje dva iskrena odgovora. Dajte proslijeđenoj krajnjoj točki ime koje se razrješava na loopback adresu i pojavljuje se u certifikatu servera, ili koristite ime hosta od početka do kraja kako bi klijent provjerio stvarni identitet. Prvo je zgodno za programere i zahtijeva rad na certifikatima; drugo je lakše promisliti i često je ispravan zadani izbor za automatizaciju. Isključivanje provjere da bi prosljeđivanje radilo odbacuje svojstvo koje ste pokušavali dodati.
Prihvatanje je tri uslova
Napišite test prihvatanja kao tri odvojene tvrdnje: veza je koristila predviđenu putanju, enkripcija je bila zahtijevana, a ne preferirana, i identitet servera je provjeren prema pouzdanom materijalu. Zelena VPN ikona ne uspostavlja nijednu od njih.
Za GUI klijente i za MariaDB provjerite vlastitu dokumentaciju dobavljača umjesto da pretpostavite da se pisanje zastavice prenosi. MySQL dokumentacija o enkriptiranim vezama pokriva razlike između načina rada i zahtjev za distribuciju CA, i to je referenca koju treba provjeriti prije nego što promijenite proizvodni niz veze.