MySQL VPN-en keresztül: ellenőrizze a kiszolgálót, ne csak a titkosítást
A rossz gazdagéphez titkosítás is hiba. Hasonlítsa össze az ssl-mode értékeit, majd futtasson olyan kapcsolatot, amely megnevezi a szándékolt kiszolgálót, és ezt bizonyítja.
Elment egy kapcsolatot a következőhöz: 10.20.4.15, a VPN megszakad, és az ügyfél továbbra is kapcsolódik. Ez nem jó hír. A privát cím egy hely azon belül a routingkörnyezeten belül, amelyben éppen van, és sok hálózat használja ugyanazokat a tartományokat. Az ügyfél elért egy MySQL-kiszolgálót, csak talán nem az önét.
A javításnak két fele van, és csak az egyik szól a hálózatról. Tartsa a kapcsolatot a szándékolt útvonalon, és késztesse az ügyfelet arra, hogy hitelesítse a kiszolgálót, amellyel beszél. Az első fele az, ahol a VPN segít; a második felét konfigurálni kell.
Titkosítva mihez, pontosan?
A TLS védi a beszélgetést bárkitől, aki középen van, és semmit sem mond arról, kinek állítja magát a végpont, hacsak az ügyfél nem ellenőrzi. A megbízható hatósággal szemben érvényesülő tanúsítvány bizonyítja, hogy a tanúsítvány attól a hatóságtól származik. Nem bizonyítja, hogy a tanúsítványt a szándékolt gazdagépnévhez adták ki, és ezek különböző kérdések.
Ez nem elméleti hiányosság. A captive portálok, a rossz VRF-es hibák és az átfedő címtervek mind olyan kiszolgálót eredményeznek, amely teljesen kész TLS-t tárgyalni önnel. Ha az ügyfél csak titkosítást követel, a munkamenet privát, de a rossz adatbázisra mutat.
Tehát a releváns kérdés nem az, hogy titkosított-e a kapcsolat, hanem hogy a szándékolt identitáshoz titkosított-e. A MySQL ügyfélprogramjában ez a különbség teljes egészében az ssl-mode beállításban él.
Az öt ssl-mode érték a gyakorlatban
Öt érték létezik, és közülük csak egy válaszol a kézikönyv kérdésére. A táblázat azt sorolja fel, hogy mit garantál valójában mindegyik, nem pedig azt, amit a neve sugall.
| 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 |
Csak az utolsó sor válaszol a cikk kérdésére. PREFERRED önmagában is említést érdemel, mert az az ügyfél, amely csendben sima szövegre esik vissza, rosszabb, mint amelyik megtagadja: azt hiszi, van titkosítása, és a csomagrögzítés nem ért egyet.
Egy kapcsolat, amelyet ma futtathat
Az alábbi parancs a használandó forma, két helyőrzővel: a jóváhagyott adatbázisnév és egy jóváhagyott csatornán beszerzett CA-fájl. Egyiket sem szabad abból venni, amit a kiszolgáló az első kapcsolatfelvételkor kínál.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password érték nélkül bekérést indít, ami a titkot a folyamatlistán kívül és a shell-előzményein kívül tartja. Ez egy kis szokás nagy haszonnal a megosztott ugróhosztokon, ahol a parancssor más felhasználók számára látható.
Amikor ez meghiúsul, a hibaüzenet jobban megkülönbözteti az eseteket, mint az intuíció. A CA-hiba azt jelenti, hogy a lánc nem érvényesül, és meg kell nézni, melyik CA írta alá a kiszolgáló tanúsítványát. A gazdagépnév-hiba azt jelenti, hogy a lánc rendben van, és a név nem egyezik, ami általában azt jelenti, hogy a helyes kiszolgálóhoz csatlakozott rossz néven, nem pedig a rossz kiszolgálóhoz.
Egy kérés megjelenése nem bizonyítéka annak, hogy a jelszó már elküldésre került, és egy sikertelen kapcsolat nem bizonyítja, hogy semmi sem hagyta el az ügyfelet. Ha egy múltbeli eseményt rekonstruál, azonosítsa az ügyfelet, annak konfigurációját, a hitelesítési beépülőt és a sikertelen szakaszt. A kitettség becslése a végső hibaüzenetből találgatás.
Amikor a név alagútból jön
A helyi porttovábbítás olyan módon töri meg az identitásellenőrzést, amely meglepi az embereket. Ha egy helyi portot továbbít az adatbázisra, és a következőhöz csatlakozik: localhost, az ügyfél a tanúsítványt a következőhöz érvényesíti: localhost, és erre a névre nem adtak ki tanúsítványt. A kapcsolat teljesen biztonságos lehet, és az ellenőrzés mégis meghiúsul, ami azt jelenti, hogy az ellenőrzés a szándék szerint működik.
Két őszinte válasz van. Adjon a továbbított végpontnak egy nevet, amely a loopback-címre oldódik fel, és megjelenik a kiszolgáló tanúsítványában, vagy használja a gazdagépnevet végig, hogy az ügyfél ellenőrizze a valódi identitást. Az első kényelmes a fejlesztőknek, és tanúsítványmunkát igényel; a második könnyebben átgondolható, és gyakran a helyes alapértelmezés az automatizáláshoz. Az ellenőrzés kikapcsolása, hogy a továbbítás működjön, eldobja azt a tulajdonságot, amelyet hozzá akart adni.
Az elfogadás három feltétel
Írja meg az elfogadási tesztet három külön állításként: a kapcsolat a szándékolt útvonalat használta, a titkosítás kötelező volt, nem preferált, és a kiszolgáló identitását megbízható anyaggal szemben ellenőrizték. Egy zöld VPN-ikon egyiket sem alapozza meg.
GUI-ügyfelek és a MariaDB esetében a szállító saját dokumentációját ellenőrizze, ahelyett hogy feltételezné, hogy a kapcsoló írásmódja átvihető. A MySQL dokumentációja a titkosított kapcsolatokról lefedi a módok közötti különbségeket és a CA terjesztésének követelményét, és ez az a hivatkozás, amelyet a gyártási kapcsolati karakterlánc módosítása előtt ellenőrizni kell.