MySQL prek VPN: preverite strežnik, ne le šifriranje
Šifriranje do napačnega gostitelja je še vedno napačno. Primerjajte vrednosti ssl-mode in nato zaženite povezavo, ki poimenuje predvideni strežnik in to dokaže.
Shranite povezavo na 10.20.4.15, VPN pade in odjemalec se še vedno povezuje. To ni dobra novica. Zasebni naslov je lokacija v katerem koli kontekstu usmerjanja, v katerem ste, in mnoga omrežja uporabljajo iste razpone. Odjemalec je dosegel strežnik MySQL, morda samo ne vašega.
Popravek ima dve polovici in le ena od njiju je o omrežju. Držite povezavo na predvideni poti in prisilite odjemalca, da preveri strežnik, s katerim govori. Prva polovica je tam, kjer pomaga VPN; drugo je treba konfigurirati.
Šifrirano v kaj, natančno?
TLS ščiti pogovor pred komer koli v sredini in ne pove ničesar o tem, kdo se končna točka razglaša, da je, razen če odjemalec to preveri. Potrdilo, ki se overi pri zaupanja vrednem organu, dokazuje, da potrdilo prihaja od tega organa. Ne dokazuje, da je bilo potrdilo izdano za ime gostitelja, ki ste ga želeli doseči, in to so različna vprašanja.
To ni teoretična vrzel. Captive portali, napake z napačnim VRF in prekrivajoči se načrti naslovov vsi ustvarijo strežnik, ki je popolnoma pripravljen z vami pogajati o TLS. Če odjemalec zahteva samo šifriranje, je seja zasebna in usmerjena v napačno podatkovno bazo.
Torej relevantno vprašanje ni, ali je povezava šifrirana, ampak ali je šifrirana do identitete, ki ste jo nameravali. V odjemalcu MySQL ta razlika živi v celoti v nastavitvi ssl-mode.
Pet vrednosti ssl-mode v praksi
Obstaja pet vrednosti in le ena od njih odgovori na vprašanje tega priročnika. Tabela navaja, kaj vsaka dejansko zagotavlja, ne pa, kaj nakazuje njeno ime.
| 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 |
Na vprašanje v tem članku odgovori le zadnja vrstica. PREFERRED si zasluži posebno omembo, ker je odjemalec, ki tiho preide na čisto besedilo, slabši od tistega, ki zavrne: verjamete, da imate šifriranje, zajem paketov pa se ne strinja.
Povezava, ki jo lahko izvedete danes
Ukaz spodaj je oblika, ki jo uporabite, z dvema nadomestnima mestoma: odobreno ime podatkovne baze in datoteka CA, pridobljena po odobrenem kanalu. Nobeno od obeh ne sme biti vzeto iz tega, kar vam strežnik ponudi ob prvem stiku.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password brez vrednosti pozove k vnosu, kar ohrani skrivnost zunaj seznama procesov in zunaj zgodovine vaše lupine. To je majhna navada z velikim donosom na skupnih skakalnih gostiteljih, kjer je ukazna vrstica vidna drugim uporabnikom.
Ko to ne uspe, besedilo napake loči primere bolje kot intuicija. Napaka CA pomeni, da se veriga ne overi, in pogledati morate, kateri CA je podpisal potrdilo strežnika. Napaka imena gostitelja pomeni, da je veriga v redu in ime se ne ujema, kar običajno pomeni, da ste se povezali s pravim strežnikom pod napačnim imenom, ne pa z napačnim strežnikom.
Pojav poziva ni dokaz, da je bilo geslo že poslano, in neuspešna povezava ne dokazuje, da iz odjemalca ni nič odšlo. Če rekonstruirate pretekli dogodek, določite odjemalca, njegovo konfiguracijo, vtičnik za preverjanje pristnosti in fazo, ki ni uspela. Ocena izpostavljenosti iz zadnjega sporočila o napaki je ugibanje.
Ko ime prihaja iz tunela
Preusmerjanje lokalnih vrat pokvari preverjanje identitete na način, ki ljudi preseneti. Če preusmerite lokalna vrata v podatkovno bazo in se povežete z localhost, odjemalec overi potrdilo proti localhost, in za to ime ni bilo izdano nobeno potrdilo. Povezava je lahko popolnoma varna in preverjanje bo vseeno spodletelo, kar pomeni, da preverjanje deluje, kot je predvideno.
Obstajata dva poštena odgovora. Preusmerjeni končni točki dajte ime, ki se razreši v naslov povratne zanke in se pojavi v potrdilu strežnika, ali uporabite ime gostitelja od začetka do konca, da odjemalec preveri resnično identiteto. Prvo je priročno za razvijalce in zahteva delo s potrdili; drugo je lažje premisliti in je pogosto pravilna privzeta nastavitev za avtomatizacijo. Izklop preverjanja, da bi preusmerjanje delovalo, zavrže lastnost, ki ste jo poskušali dodati.
Sprejem so trije pogoji
Napišite sprejemni test kot tri ločene trditve: povezava je uporabila predvideno pot, šifriranje je bilo zahtevano in ne prednostno, in identiteta strežnika je bila preverjena proti zaupanja vrednemu gradivu. Zelena ikona VPN ne vzpostavi nobene od njih.
Pri odjemalcih GUI in pri MariaDB preverite lastno dokumentacijo ponudnika, namesto da predpostavite, da se črkovanje zastavice prenese. Dokumentacija MySQL o šifriranih povezavah pokriva razlike med načini in zahtevo po distribuciji CA, in to je referenca, ki jo je treba preveriti, preden spremenite produkcijski niz povezave.