MySQL prin VPN: verificați serverul, nu doar criptarea
Criptarea către gazda greșită rămâne greșită. Comparați valorile ssl-mode, apoi executați o conexiune care numește serverul dorit și demonstrează acest lucru.
Salvați o conexiune către 10.20.4.15, VPN-ul cade, iar clientul se conectează în continuare. Aceasta nu este o veste bună. O adresă privată este o locație în orice context de rutare în care vă aflați, iar multe rețele folosesc aceleași intervale. Clientul a ajuns la un server MySQL, doar că poate nu la al dumneavoastră.
Corectarea are două jumătăți, iar doar una dintre ele este despre rețea. Păstrați conexiunea pe calea dorită și faceți clientul să autentifice serverul cu care vorbește. Prima jumătate este locul unde un VPN ajută; a doua trebuie configurată.
Criptat către ce, mai exact?
TLS protejează conversația de oricine se află la mijloc și nu spune nimic despre cine susține că este punctul final, decât dacă clientul verifică. Un certificat care se validează față de o autoritate de încredere dovedește că certificatul provine de la acea autoritate. Nu dovedește că certificatul a fost emis pentru numele de gazdă pe care doreați să îl atingeți, iar acestea sunt întrebări diferite.
Nu este o lacună teoretică. Portalurile captive, erorile cu VRF greșit și planurile de adrese suprapuse produc toate un server perfect dispus să negocieze TLS cu dumneavoastră. Dacă clientul cere doar criptare, sesiunea este privată și îndreptată către baza de date greșită.
Deci întrebarea relevantă nu este dacă conexiunea este criptată, ci dacă este criptată către identitatea pe care ați intenționat-o. În clientul MySQL, această distincție trăiește în întregime în setarea ssl-mode.
Cele cinci valori ssl-mode în practică
Există cinci valori, iar doar una dintre ele răspunde la întrebarea acestui ghid. Tabelul enumeră ce garantează de fapt fiecare, nu ce sugerează numele său.
| 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 |
Doar ultimul rând răspunde la întrebarea din acest articol. PREFERRED merită evidențiat separat, pentru că un client care cade în liniște pe text simplu este mai rău decât unul care refuză: credeți că aveți criptare, iar captura de pachete nu este de acord.
O conexiune pe care o puteți executa astăzi
Comanda de mai jos este forma de utilizat, cu două substituente: numele bazei de date aprobat și un fișier CA obținut printr-un canal aprobat. Niciunul nu trebuie luat din ce vă oferă serverul la primul contact.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password fără valoare cere introducere, ceea ce ține secretul în afara listei de procese și în afara istoricului shell-ului. Este un obicei mic cu un câștig mare pe gazdele de salt partajate, unde linia de comandă este vizibilă pentru alți utilizatori.
Când acest lucru eșuează, textul erorii distinge cazurile mai bine decât intuiția. O eroare CA înseamnă că lanțul nu se validează și ar trebui să verificați ce CA a semnat certificatul serverului. O eroare de nume de gazdă înseamnă că lanțul este în regulă, iar numele nu corespunde, ceea ce de obicei înseamnă că v-ați conectat la serverul corect sub numele greșit, nu la serverul greșit.
Apariția unui prompt nu este dovada că o parolă a fost deja transmisă, iar o conexiune eșuată nu dovedește că nimic nu a părăsit clientul. Dacă reconstituiți un eveniment trecut, identificați clientul, configurația acestuia, pluginul de autentificare și etapa care a eșuat. Estimarea expunerii din mesajul de eroare final este o presupunere.
Când numele vine dintr-un tunel
Redirecționarea portului local strică verificarea identității într-un mod care surprinde oamenii. Dacă redirecționați un port local către baza de date și vă conectați la localhost, clientul validează certificatul față de localhost, iar pentru acel nume nu a fost emis niciun certificat. Conexiunea poate fi perfect sigură, iar verificarea va eșua totuși, ceea ce înseamnă că verificarea funcționează conform intenției.
Există două răspunsuri oneste. Dați punctului final redirecționat un nume care se rezolvă la adresa de buclă locală și apare în certificatul serverului, sau folosiți numele de gazdă de la un capăt la altul, astfel încât clientul să verifice identitatea reală. Primul este comod pentru dezvoltatori și necesită muncă la certificate; al doilea este mai ușor de raționat și adesea valoarea implicită corectă pentru automatizare. Dezactivarea verificării pentru ca redirecționarea să funcționeze aruncă proprietatea pe care încercați să o adăugați.
Acceptarea înseamnă trei condiții
Scrieți testul de acceptare ca trei afirmații separate: conexiunea a folosit ruta dorită, criptarea a fost cerută și nu preferată, iar identitatea serverului a fost verificată față de material de încredere. O pictogramă VPN verde nu stabilește niciuna dintre ele.
Pentru clienții GUI și pentru MariaDB, consultați documentația furnizorului însuși în loc să presupuneți că ortografia steagului se transferă. Documentația MySQL despre conexiunile criptate acoperă diferențele dintre moduri și cerința de distribuire a CA, și este referința de verificat înainte de a modifica un șir de conexiune de producție.