MySQL per VPN: patikrinkite serverį, o ne tik šifravimą
Šifravimas prie netinkamo kompiuterio vis tiek yra klaida. Palyginkite ssl-mode reikšmes, tada paleiskite ryšį, kuris įvardija numatytą serverį ir tai įrodo.
Jūs išsaugote ryšį su 10.20.4.15, VPN nutrūksta, o klientas vis tiek jungiasi. Tai nėra gera žinia. Privatus adresas yra vieta bet kuriame maršrutizavimo kontekste, kuriame esate, ir daugelis tinklų naudoja tas pačias sritis. Klientas pasiekė MySQL serverį, tik galbūt ne jūsų.
Taisymas turi dvi puses, ir tik viena iš jų apie tinklą. Laikykite ryšį numatytame kelyje ir priverskite klientą autentifikuoti serverį, su kuriuo jis kalba. Pirmoji pusė yra ten, kur padeda VPN; antroji turi būti sukonfigūruota.
Šifruota į ką, tiksliai?
TLS apsaugo pokalbį nuo bet ko, kas yra viduryje, ir nieko nesako apie tai, kuo galinis taškas teigia esąs, nebent klientas tai patikrina. Sertifikatas, kuris patvirtinamas patikimos institucijos atžvilgiu, įrodo, kad sertifikatas išėjo iš tos institucijos. Tai neįrodo, kad sertifikatas buvo išduotas to kompiuterio vardo, kurį norėjote pasiekti, ir tai yra skirtingi klausimai.
Tai ne teorinė spraga. Captive portalai, klaidos su netinkamu VRF ir persidengiantys adresų planai visi sukuria serverį, kuris yra visiškai pasirengęs derėtis su jumis dėl TLS. Jei klientas reikalauja tik šifravimo, sesija yra privati, bet nukreipta į netinkamą duomenų bazę.
Taigi svarbus klausimas yra ne tai, ar ryšys šifruotas, o tai, ar jis šifruotas tapatybei, kurią turėjote omenyje. MySQL kliente tas skirtumas gyvena visiškai ssl-mode nuostatoje.
Penkios ssl-mode reikšmės praktikoje
Yra penkios reikšmės, ir tik viena iš jų atsako į šio vadovo klausimą. Lentelė išvardija, ką kiekviena iš tikrųjų garantuoja, o ne ką siūlo jos pavadinimas.
| 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 |
Į šio straipsnio klausimą atsako tik paskutinė eilutė. PREFERRED verta paminėti atskirai, nes klientas, kuris tyliai pereina prie paprasto teksto, yra blogesnis už tą, kuris atsisako: jūs manote, kad turite šifravimą, o paketų įrašymas tam prieštarauja.
Ryšys, kurį galite paleisti šiandien
Žemiau pateikta komanda yra forma, kurią naudoti, su dviem vietos žymekliais: patvirtintu duomenų bazės pavadinimu ir CA failu, gautu patvirtintu kanalu. Nė vieno iš jų nereikėtų imti iš to, ką serveris siūlo pirmojo kontakto metu.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password be reikšmės prašo įvesties, o tai saugo paslaptį nuo procesų sąrašo ir jūsų apvalkalo istorijos. Tai mažas įprotis, duodantis didelę naudą bendruose šuolio kompiuteriuose, kur komandinė eilutė matoma kitiems naudotojams.
Kai tai nepavyksta, klaidos tekstas atskiria atvejus geriau nei intuicija. CA klaida reiškia, kad grandinė nepatvirtinama, ir turėtumėte pažiūrėti, kuri CA pasirašė serverio sertifikatą. Kompiuterio vardo klaida reiškia, kad grandinė tvarkinga, o vardas nesutampa, o tai paprastai reiškia, kad prisijungėte prie teisingo serverio neteisingu vardu, o ne prie neteisingo serverio.
Užklausos pasirodymas nėra įrodymas, kad slaptažodis jau buvo perduotas, o nepavykęs ryšys neįrodo, kad niekas nepaliko kliento. Jei rekonstruojate praeities įvykį, nustatykite klientą, jo konfigūraciją, autentifikavimo papildinį ir nepavykusį etapą. Poveikio vertinimas iš paskutinio klaidos pranešimo yra spėjimas.
Kai vardas ateina iš tunelio
Vietinio prievado peradresavimas sulaužo tapatybės patikrinimą taip, kad žmonės nustemba. Jei peradresuojate vietinį prievadą į duomenų bazę ir prisijungiate prie localhost, klientas patvirtina sertifikatą localhost atžvilgiu, o tam vardui sertifikatas nebuvo išduotas. Ryšys gali būti visiškai saugus, o patikrinimas vis tiek nepavyks, ir tai yra patikrinimas, veikiantis taip, kaip numatyta.
Yra du sąžiningi atsakymai. Suteikite peradresuotam galiniam taškui vardą, kuris išsprendžiamas į loopback adresą ir pasirodo serverio sertifikate, arba naudokite kompiuterio vardą nuo pradžios iki pabaigos, kad klientas patikrintų tikrąją tapatybę. Pirmasis patogus kūrėjams ir reikalauja sertifikatų darbo; antrasis lengviau apgalvojamas ir dažnai tinkama numatytoji reikšmė automatizavimui. Patikrinimo išjungimas, kad peradresavimas veiktų, išmeta savybę, kurią bandėte pridėti.
Priėmimas yra trys sąlygos
Parašykite priėmimo testą kaip tris atskirus teiginius: ryšys naudojo numatytą maršrutą, šifravimas buvo reikalaujamas, o ne pageidaujamas, ir serverio tapatybė buvo patikrinta patikimos medžiagos atžvilgiu. Žalias VPN ženklas nenustato nė vieno iš jų.
GUI klientams ir MariaDB patikrinkite paties tiekėjo dokumentaciją, o ne darykite prielaidą, kad vėliavėlės rašyba persikelia. MySQL dokumentacija apie šifruotus ryšius apima režimų skirtumus ir CA platinimo reikalavimą, ir tai yra nuoroda, kurią reikia patikrinti prieš keičiant produkcinę ryšio eilutę.