MySQL via un VPN : vérifiez le serveur, pas seulement le chiffrement
Chiffrer vers le mauvais hôte reste une erreur. Comparez les valeurs de ssl-mode, puis exécutez une connexion qui nomme le serveur voulu et le prouve.
Vous enregistrez une connexion vers 10.20.4.15, le VPN tombe, et le client se connecte quand même. Ce n’est pas une bonne nouvelle. Une adresse privée est un emplacement dans le contexte de routage où vous vous trouvez, et beaucoup de réseaux utilisent les mêmes plages. Le client a atteint un serveur MySQL, peut-être simplement pas le vôtre.
Le correctif a deux moitiés, et une seule concerne le réseau. Maintenez la connexion sur son chemin prévu et faites authentifier par le client le serveur auquel il parle. La première moitié est là où un VPN aide ; la seconde doit être configurée.
Chiffré vers quoi, exactement ?
TLS protège la conversation contre quiconque se trouve au milieu et ne dit rien sur l’identité que revendique le point de terminaison, sauf si le client le vérifie. Un certificat qui se valide auprès d’une autorité de confiance prouve que le certificat vient de cette autorité. Il ne prouve pas que le certificat a été émis pour le nom d’hôte que vous vouliez atteindre, et ce sont des questions différentes.
Ce n’est pas une faille théorique. Les portails captifs, les erreurs de mauvais VRF et les plans d’adressage qui se chevauchent produisent tous un serveur parfaitement disposé à négocier TLS avec vous. Si le client n’exige que le chiffrement, la session est privée et pointée vers la mauvaise base de données.
La question pertinente n’est donc pas de savoir si la connexion est chiffrée, mais si elle est chiffrée vers l’identité que vous vouliez. Dans le client MySQL, cette distinction réside entièrement dans le réglage ssl-mode.
Les cinq valeurs de ssl-mode en pratique
Il existe cinq valeurs, et une seule répond à la question de ce guide. Le tableau liste ce que chacune garantit réellement, plutôt que ce que son nom suggère.
| 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 |
Seule la dernière ligne répond à la question de cet article. PREFERRED mérite d’être signalé à part, car un client qui retombe silencieusement en clair est pire qu’un client qui refuse : vous croyez avoir du chiffrement et la capture de paquets n’est pas d’accord.
Une connexion que vous pouvez exécuter aujourd’hui
La commande ci-dessous est la forme à utiliser, avec deux espaces réservés : le nom de base de données approuvé et un fichier CA obtenu par un canal approuvé. Ni l’un ni l’autre ne doit être pris dans ce que le serveur vous propose au premier contact.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password sans valeur demande une saisie, ce qui garde le secret hors de la liste des processus et hors de l’historique de votre shell. C’est une petite habitude au rendement élevé sur les hôtes de saut partagés, où une ligne de commande est visible par d’autres utilisateurs.
Quand cela échoue, le texte de l’erreur distingue les cas mieux que l’intuition. Un échec de CA signifie que la chaîne ne se valide pas et que vous devez regarder quelle CA a signé le certificat du serveur. Un échec de nom d’hôte signifie que la chaîne est correcte et que le nom ne correspond pas, ce qui veut généralement dire que vous vous êtes connecté au bon serveur sous le mauvais nom plutôt qu’au mauvais serveur.
L’apparition d’une invite ne prouve pas qu’un mot de passe a déjà été transmis, et une connexion échouée ne prouve pas que rien n’a quitté le client. Si vous reconstituez un événement passé, identifiez le client, sa configuration, le greffon d’authentification et l’étape qui a échoué. Estimer l’exposition à partir du message d’erreur final relève de la devinette.
Quand le nom vient d’un tunnel
Le transfert de port local casse la vérification d’identité d’une manière qui surprend. Si vous transférez un port local vers la base de données et vous connectez à localhost, le client valide le certificat contre localhost, et aucun certificat n’a été émis pour ce nom. La connexion peut être parfaitement sûre et la vérification échouera quand même, ce qui est la vérification fonctionnant comme prévu.
Il y a deux réponses honnêtes. Donnez au point de terminaison transféré un nom qui résout vers l’adresse de bouclage et figure dans le certificat du serveur, ou utilisez le nom d’hôte de bout en bout pour que le client vérifie la véritable identité. La première est pratique pour les développeurs et demande un travail sur les certificats ; la seconde est plus simple à raisonner et souvent le bon choix par défaut pour l’automatisation. Désactiver la vérification pour faire fonctionner le transfert jette la propriété que vous cherchiez à ajouter.
L’acceptation tient à trois conditions
Écrivez le test d’acceptation comme trois affirmations distinctes : la connexion a utilisé l’itinéraire prévu, le chiffrement était exigé et non préféré, et l’identité du serveur a été vérifiée contre du matériel de confiance. Une icône VPN verte n’en établit aucune.
Pour les clients GUI et pour MariaDB, consultez la documentation de l’éditeur plutôt que de supposer que l’orthographe du drapeau se transpose. La documentation MySQL sur les connexions chiffrées couvre les différences entre modes et l’exigence de distribution de l’autorité de certification, et c’est la référence à consulter avant de modifier une chaîne de connexion de production.