MySQL VPN:n yli: varmenna palvelin, älä vain salausta
Salaaminen väärään isäntään on edelleen väärin. Vertaa ssl-mode-arvoja ja aja sitten yhteys, joka nimeää tarkoitetun palvelimen ja todistaa sen.
Tallennat yhteyden osoitteeseen 10.20.4.15, VPN katkeaa ja asiakas yhdistää silti. Se ei ole hyvä uutinen. Yksityinen osoite on sijainti missä tahansa reitityskontekstissa, jossa satut olemaan, ja monet verkot käyttävät samoja alueita. Asiakas tavoitti MySQL-palvelimen, vain ehkä ei sinun.
Korjauksessa on kaksi puoliskoa, ja vain toinen niistä koskee verkkoa. Pidä yhteys aiotulla polulla ja saa asiakas todentamaan palvelin, jonka kanssa se puhuu. Ensimmäinen puolisko on se, missä VPN auttaa; toinen puolisko on määritettävä.
Salattu mihin, tarkalleen?
TLS suojaa keskustelun jokaiselta välissä olevalta eikä kerro mitään siitä, kuka päätepiste väittää olevansa, ellei asiakas tarkista sitä. Sertifikaatti, joka validoituu luotettua tahoa vastaan, todistaa, että sertifikaatti tuli siltä taholta. Se ei todista, että sertifikaatti myönnettiin isäntänimelle, jonka halusit saavuttaa, ja ne ovat eri kysymyksiä.
Tämä ei ole teoreettinen aukko. Captive-portaalit, väärän VRF:n virheet ja päällekkäiset osoitesuunnitelmat tuottavat kaikki palvelimen, joka on täysin valmis neuvottelemaan TLS:stä kanssasi. Jos asiakas vaatii vain salauksen, istunto on yksityinen ja osoittaa väärään tietokantaan.
Olennaista ei siis ole, onko yhteys salattu, vaan onko se salattu siihen identiteettiin, jonka tarkoitit. MySQL:n asiakasohjelmassa tämä ero asuu kokonaan ssl-mode-asetuksessa.
Viisi ssl-mode-arvoa käytännössä
Arvoja on viisi, ja vain yksi niistä vastaa tämän käsikirjan kysymykseen. Taulukko luettelee, mitä kukin todella takaa, ei mitä sen nimi antaa ymmärtää.
| 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 |
Vain viimeinen rivi vastaa tämän artikkelin kysymykseen. PREFERRED kannattaa nostaa esiin erikseen, koska asiakas, joka putoaa hiljaa selkokieleen, on huonompi kuin se, joka kieltäytyy: uskot, että sinulla on salaus, ja pakettikaappaus on eri mieltä.
Yhteys, jonka voit ajaa tänään
Alla oleva komento on muoto, jota käytetään, kahdella paikkamerkillä: hyväksytty tietokannan nimi ja hyväksyttyä kanavaa pitkin hankittu CA-tiedosto. Kumpaakaan ei pidä ottaa siitä, mitä palvelin tarjoaa ensimmäisellä yhteydellä.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password ilman arvoa kysyy syötettä, mikä pitää salaisuuden poissa prosessilistalta ja shell-historiastasi. Se on pieni tapa, jolla on suuri hyöty jaetuilla hyppypalvelimilla, joissa komentorivi näkyy muille käyttäjille.
Kun tämä epäonnistuu, virheteksti erottaa tapaukset paremmin kuin intuitio. CA-virhe tarkoittaa, että ketju ei validoi ja sinun pitäisi katsoa, mikä CA allekirjoitti palvelimen sertifikaatin. Isäntänimivirhe tarkoittaa, että ketju on kunnossa ja nimi ei täsmää, mikä yleensä tarkoittaa, että yhdistit oikeaan palvelimeen väärällä nimellä etkä väärään palvelimeen.
Kehoteen ilmestyminen ei ole todiste siitä, että salasana on jo lähetetty, eikä epäonnistunut yhteys todista, ettei asiakkaasta lähtenyt mitään. Jos rekonstruoit mennyttä tapahtumaa, tunnista asiakas, sen kokoonpano, todennuslisäosa ja epäonnistunut vaihe. Altistuksen arvioiminen viimeisestä virheilmoituksesta on arvailua.
Kun nimi tulee tunnelista
Paikallisen portin edelleenohjaus rikkoo identiteettitarkistuksen tavalla, joka yllättää ihmiset. Jos ohjaat paikallisen portin tietokantaan ja yhdistät osoitteeseen localhost, asiakas validoi sertifikaatin osoitetta localhost vastaan, eikä kyseiselle nimelle myönnetty sertifikaattia. Yhteys voi olla täysin turvallinen ja tarkistus epäonnistuu silti, mikä on tarkistus, joka toimii tarkoitetulla tavalla.
On kaksi rehellistä vastausta. Anna edelleenohjatulle päätepisteelle nimi, joka ratkeaa loopback-osoitteeseen ja esiintyy palvelimen sertifikaatissa, tai käytä isäntänimeä päästä päähän, jotta asiakas varmistaa todellisen identiteetin. Ensimmäinen on kätevä kehittäjille ja vaatii sertifikaattityötä; toinen on helpompi ajatella ja usein oikea oletus automaatiolle. Tarkistuksen poistaminen käytöstä, jotta edelleenohjaus toimisi, heittää pois ominaisuuden, jota yritit lisätä.
Hyväksyntä on kolme ehtoa
Kirjoita hyväksyntätesti kolmena erillisenä väitteenä: yhteys käytti aiottua reittiä, salaus vaadittiin eikä ollut ensisijainen, ja palvelimen identiteetti varmennettiin luotettua materiaalia vastaan. Vihreä VPN-kuvake ei vahvista yhtäkään niistä.
Tarkista GUI-asiakkaiden ja MariaDB:n osalta toimittajan oma dokumentaatio sen sijaan, että olettaisit lipun kirjoitusasun siirtyvän. MySQL:n dokumentaatio salatuista yhteyksistä kattaa tilojen erot ja CA:n jakeluvaatimuksen, ja se on viite, joka tarkistetaan ennen tuotantoyhteysmerkkijonon muuttamista.