Comment QoreDB gère les connexions SSL/TLS selon le moteur

Chaque moteur de base de données a sa propre grammaire pour la couche TLS. PostgreSQL parle de sslmode avec six valeurs, MySQL propose cinq modes distincts, MongoDB pilote le TLS par le schéma d'URI, Redis fait de même avec rediss://, et SQL Server manipule des niveaux d'encryption via Tiberius. Ces différences ne sont pas cosmétiques : elles reflètent des modèles de menace différents et des implémentations de handshake incompatibles.

QoreDB ne cherche pas à unifier ces grammaires derrière une abstraction commune. Le principe est le même que pour la traduction de requêtes ou l'émulation de features : rester fidèle à la sémantique native de chaque moteur, quitte à faire circuler un peu plus d'information dans la configuration de connexion.

Un booléen et un mode textuel

La configuration d'une connexion, dans qore-core, porte trois champs qui touchent au TLS. Un ssl: bool historique, un ssl_mode: Option<String> plus expressif, et un ssl_ca_cert: Option<String> qui pointe vers un certificat CA au format PEM.

La règle de résolution est stable pour tous les drivers : quand ssl_mode est défini, il gagne. Sinon on retombe sur le booléen. Cette hiérarchie sert deux cas concrets. Le premier, la rétrocompatibilité : les connexions sauvegardées avant l'ajout du champ ssl_mode continuent à fonctionner. Le second, la précision : un utilisateur qui veut verify-full sur son cluster Postgres n'a pas à passer par une case booléenne qui n'exprime pas cette nuance.

PostgreSQL et la famille : sslmode en clair

Le driver PostgreSQL s'appuie sur SQLx et construit son URL de connexion via une fonction commune partagée avec CockroachDB, TimescaleDB, Supabase et Neon. La chaîne finale intègre toujours un paramètre sslmode explicite. Si l'utilisateur a fourni ssl_mode = "verify-full", cette valeur est injectée telle quelle. Sinon on retombe sur require quand ssl est activé, ou disable sinon. Les six modes standards de libpq restent utilisables : disable, allow, prefer, require, verify-ca, verify-full.

Ce choix a un avantage direct : la chaîne de connexion produite est celle que n'importe quel administrateur PostgreSQL reconnaît. Aucun traducteur intermédiaire, aucune couche de vocabulaire QoreDB à décoder. Un problème de handshake se debugge avec la doc officielle libpq, pas avec la doc QoreDB.

MySQL et MariaDB : un enum typé

Le driver MySQL passe par MySqlSslMode, l'enum fourni par SQLx : Disabled, Preferred, Required, VerifyCa, VerifyIdentity. Une petite fonction de résolution accepte les variantes courantes de nommage (tirets, underscores, verify-full comme alias de verify-identity) et applique la même règle de priorité : ssl_mode textuel d'abord, booléen ensuite.

Le mode Preferred est particulier : la tentative TLS est faite, mais l'échec est silencieux, ce qui rend la garantie de sécurité conditionnelle. C'est un mode utile en dev, dangereux en prod. QoreDB ne l'impose jamais par défaut : quand l'utilisateur active ssl = true sans autre précision, on obtient Required, pas Preferred.

MongoDB et Redis : le TLS piloté par l'URI

MongoDB expose le TLS par un paramètre de query string, ?tls=true, et l'active implicitement quand le schéma est mongodb+srv://. Le driver QoreDB traduit le booléen ssl en append de tls=true ou tls=false. Le parseur d'URL, côté qore-sql, reconnaît que mongodb+srv implique TLS et déduit correctement l'état par défaut, avec possibilité de le désactiver explicitement.

Redis suit la même logique de schéma : redis:// pour le canal clair, rediss:// pour TLS. Le driver construit l'URL en choisissant le schéma en fonction du booléen ssl. Il n'y a pas de mode intermédiaire à exposer : Redis ne connaît que le tout ou rien, et on reste transparent sur ce point.

SQL Server et ClickHouse : niveaux de chiffrement et refus du cleartext

SQL Server est piloté par Tiberius. Sa configuration prend un EncryptionLevel qui bascule entre Required et NotSupported selon le booléen ssl. La politique actuelle est de faire confiance au certificat serveur pour éviter les blocages sur les instances de développement, où les certificats auto-signés sont la norme. Ce mécanisme est conçu pour un usage desktop, où l'utilisateur maîtrise la cible de connexion et vérifie lui-même l'identité de l'hôte au niveau réseau.

ClickHouse est un cas intéressant. Le driver ne parle pas le protocole binaire natif, il utilise l'API HTTP. Le schéma d'URL bascule donc entre http:// et https:// en fonction du booléen ssl. Une garde spécifique a été ajoutée : quand le mode SSL revient à disable ou allow et qu'un mot de passe est présent, la connexion est refusée avant même la première requête. Envoyer un mot de passe en clair via HTTP est une classe d'incidents suffisamment fréquente pour justifier une préemption au niveau du driver, pas juste un avertissement quelque part dans les logs.

Elasticsearch et OpenSearch : un CA custom optionnel

Les drivers pour moteurs de recherche s'appuient sur reqwest compilé avec rustls-tls. C'est le seul endroit où le champ ssl_ca_cert est réellement honoré : quand un chemin est fourni, le PEM est lu, parsé via reqwest::Certificate::from_pem et injecté comme racine additionnelle du client HTTP. Sinon, le trust store système est utilisé.

Ce mécanisme couvre le cas fréquent des clusters Elasticsearch internes équipés d'une CA privée. Le certificat racine est un fichier PEM sur le disque, référencé par chemin absolu dans la configuration de connexion. Il n'est jamais copié dans le vault ni sérialisé dans les backups de configuration : c'est un lien vers un fichier local, pas un secret embarqué.

Le parseur d'URL qui reconstitue le mode

Un utilisateur qui colle une URL complète dans la modale de connexion s'attend à ce que le mode TLS soit lu correctement. Le module qore-sql/src/connection_url.rs gère cette extraction. La fonction extract_ssl_from_query reconnaît les clés de mode (sslmode, ssl-mode) en priorité, puis les booléens (ssl, usessl, tls), et enfin traite tout paramètre commençant par ssl ou tls comme une implication.

C'est ce dernier point qui évite une classe de bugs : coller une URL PostgreSQL avec ?sslrootcert=/path/ca.pem sans sslmode explicite active correctement le TLS. Fournir un certificat sans activer le TLS n'a aucun sens fonctionnel, et le parseur préfère lever le doute plutôt que produire une config incohérente. La couverture de tests unitaires de ce module est particulièrement dense : plus d'une vingtaine de cas figés pour chaque famille de moteur.

En pratique dans l'application

Dans la modale de connexion, deux surfaces cohabitent. Un champ URL, qui accepte une DSN complète et remplit les autres champs par introspection. Et une section avancée, qui expose le ssl_mode textuel et le chemin CA quand ils sont pertinents pour le driver sélectionné. Le formulaire ne prétend jamais offrir plus de granularité que ce que le moteur cible sait consommer.

Le vault, lui, ne stocke que la configuration : booléen, mode, chemin de fichier. Les certificats CA ne sont jamais copiés dans la base chiffrée. Ce choix simplifie deux aspects : la rotation d'un certificat racine ne nécessite pas de rééditer la connexion, et la portabilité d'un backup de configuration ne dépend pas de fichiers PEM absents sur la machine cible.

Conclusion

La gestion du TLS dans QoreDB reflète la ligne directrice du produit : ne pas abstraire ce qui ne se prête pas à l'abstraction. Chaque moteur garde sa grammaire, chaque driver traduit fidèlement le mode demandé, et le parseur d'URL préserve l'intention initiale même quand l'utilisateur passe par la voie DSN plutôt que par le formulaire. Le résultat est une couche de transport prévisible : ce qui est configuré dans la modale est exactement ce qui parvient au moteur, sans réinterprétation intermédiaire.