MySQL tramite VPN: verificate il server, non solo la crittografia
Cifrare verso l’host sbagliato resta sbagliato. Confrontate i valori di ssl-mode, poi eseguite una connessione che nomini il server che intendevate e lo dimostri.
Salvate una connessione verso 10.20.4.15, la VPN cade e il client si connette comunque. Non è una buona notizia. Un indirizzo privato è una posizione all’interno di qualunque contesto di routing in cui vi troviate, e molte reti usano gli stessi intervalli. Il client ha raggiunto un server MySQL, forse solo non il vostro.
La correzione ha due metà, e solo una riguarda la rete. Mantenete la connessione sul percorso previsto e fate autenticare al client il server con cui parla. La prima metà è dove una VPN aiuta; la seconda va configurata.
Cifrato verso cosa, esattamente?
TLS protegge la conversazione da chiunque stia nel mezzo e non dice nulla su chi dichiari di essere l’endpoint, a meno che il client non lo verifichi. Un certificato che si convalida contro un’autorità fidata dimostra che il certificato proviene da quell’autorità. Non dimostra che il certificato sia stato emesso per il nome host che volevate raggiungere, e queste sono domande diverse.
Non è una lacuna teorica. I portali captive, gli errori di VRF sbagliato e i piani di indirizzamento sovrapposti producono tutti un server perfettamente disposto a negoziare TLS con voi. Se il client richiede solo la crittografia, la sessione è privata e punta al database sbagliato.
Quindi la domanda pertinente non è se la connessione sia cifrata, ma se sia cifrata verso l’identità che intendevate. Nel client di MySQL, quella distinzione vive interamente nell’impostazione ssl-mode.
I cinque valori di ssl-mode in pratica
Esistono cinque valori, e solo uno risponde alla domanda di questo manuale. La tabella elenca ciò che ciascuno garantisce davvero, invece di ciò che il nome suggerisce.
| 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 |
Solo l’ultima riga risponde alla domanda di questo articolo. PREFERRED merita una segnalazione a sé, perché un client che scivola silenziosamente in chiaro è peggio di uno che rifiuta: credete di avere la crittografia e la cattura dei pacchetti non è d’accordo.
Una connessione che potete eseguire oggi
Il comando qui sotto è la forma da usare, con due segnaposto: il nome del database approvato e un file CA ottenuto tramite un canale approvato. Nessuno dei due va preso da ciò che il server vi offre al primo contatto.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password senza valore chiede un input, il che tiene il segreto fuori dall’elenco dei processi e fuori dalla cronologia della shell. È una piccola abitudine con un grande ritorno sugli host di salto condivisi, dove una riga di comando è visibile agli altri utenti.
Quando questo fallisce, il testo dell’errore distingue i casi meglio dell’intuito. Un errore CA significa che la catena non si convalida e dovreste guardare quale CA ha firmato il certificato del server. Un errore di nome host significa che la catena è a posto e il nome non corrisponde, il che di solito significa che vi siete connessi al server giusto con il nome sbagliato, non al server sbagliato.
La comparsa di un prompt non è prova che una password sia già stata trasmessa, e una connessione fallita non dimostra che nulla abbia lasciato il client. Se ricostruite un evento passato, identificate il client, la sua configurazione, il plugin di autenticazione e la fase che ha fallito. Stimare l’esposizione dal messaggio di errore finale è un’ipotesi.
Quando il nome arriva da un tunnel
L’inoltro della porta locale rompe il controllo dell’identità in un modo che sorprende. Se inoltrate una porta locale al database e vi collegate a localhost, il client convalida il certificato contro localhost, e nessun certificato è stato emesso per quel nome. La connessione può essere perfettamente sicura e la verifica fallirà comunque, il che è il controllo che funziona come previsto.
Ci sono due risposte oneste. Date all’endpoint inoltrato un nome che si risolva all’indirizzo di loopback e compaia nel certificato del server, oppure usate il nome host da un capo all’altro perché il client verifichi l’identità reale. Il primo è comodo per gli sviluppatori e richiede lavoro sui certificati; il secondo è più semplice da ragionare e spesso l’impostazione predefinita corretta per l’automazione. Disattivare la verifica per far funzionare l’inoltro butta via la proprietà che stavate cercando di aggiungere.
L’accettazione è tre condizioni
Scrivete il test di accettazione come tre affermazioni separate: la connessione ha usato il percorso previsto, la crittografia era richiesta e non preferita, e l’identità del server è stata verificata contro materiale fidato. Un’icona VPN verde non ne stabilisce nessuna.
Per i client GUI e per MariaDB, controllate la documentazione del fornitore stesso invece di supporre che l’ortografia del flag si trasferisca. La documentazione MySQL sulle connessioni cifrate copre le differenze tra modalità e il requisito di distribuzione della CA, ed è il riferimento da controllare prima di cambiare una stringa di connessione di produzione.