La majorit des serveurs PostgreSQL sur Internet ne seraient pas scuriss, selon Jonathan Mortensen, Alors qu’il est souvent considr comme un systme plus fiable et plus robuste que MySQL

Lorsque vous devez dplacer des informations sur un rseau de manire scurise, une connexion non crypte est inacceptable. Pour rendre tout type de donnes illisibles, utilisez le chiffrement. De lavis de Jonathan Mortensen, tout au plus 15 % des quelque 820 000 serveurs PostgreSQL qui coutent sur Internet ont besoin de chiffrement. En fait, seuls 36 % d’entre eux supporteraient le chiffrement. Cela place les serveurs PostgreSQL loin derrire ces concurrents en termes de scurit. En comparaison, selon Google, plus de 96 % des chargements de pages dans Chrome sur un Mac sont chiffrs. Les 100 premiers sites Web prennent en charge le chiffrement et 97 d’entre eux l’utilisent par dfaut.

La situation ne s’arrte pas aux serveurs PostgreSQL : la plupart des clients SQL populaires sont plus qu’heureux d’accepter des connexions non chiffres sans avertissement. Jonathan Mortensen et son quipe ont men une enqute informelle auprs de 22 clients SQL populaires et ont constat que seuls deux d’entre eux exigent des connexions chiffres par dfaut. Six autres demandent le chiffrement mais acceptent en sourdine une connexion non chiffre. Les 14 clients restants demandent l’utilisateur d’opter pour l’utilisation de SSL ; les connexions sont non chiffres par dfaut.

Lorsque vous vous connectez un site web via votre navigateur, les donnes que vous envoyez et recevez sont probablement chiffres. Il est donc tonnant que les donnes envoyes vers et depuis les serveurs PostgreSQL connects Internet soient trs probablement non chiffres. C’est un problme , crit Jonathan Mortensen. Nous avons vu des millions de tentatives de connexion bit.io au cours du mois dernier. La raison principale pour laquelle ces tentatives chouent est qu’elles n’utilisent pas de chiffrement (ce que nous exigeons) , poursuit-il.

Il y a beaucoup de serveurs PostgreSQL connects l’Internet : une recherche sur shodan.io montre un chantillon de plus de 820 000 serveurs PostgreSQL connects l’Internet entre le 1er et le 29 septembre. Seuls 36 % des serveurs examins disposaient de certificats SSL. Plus de 523 000 serveurs PostgreSQL en coute sur Internet n’utilisaient pas SSL (64 %), laissant ouverte la possibilit d’une lecture indsirable des donnes transmises vers et depuis le serveur. Pire encore, 41 serveurs PostgreSQL en ligne n’taient absolument pas protgs, ne disposant mme pas d’un mot de passe.

Certificats auto-signs et expirs

Il ne suffit pas d’avoir un certificat. Prs de 12 000 (4,0 %) des certificats taient expirs. En outre, plus de 128 000 (43,3 %) des certificats taient auto-signs. Les connexions aux serveurs avec des certificats auto-signs sont chiffres, mais les certificats ne confrent souvent pas de confiance : gnralement, ils ne sont ni mis ni valids par une autorit de certification, ils n’expirent pas et ne peuvent pas tre rvoqus. La plupart des clients ne disposent pas d’un certificat racine pour un certificat auto-sign donn, ils ne peuvent donc pas se connecter en utilisant verify-full, sans lequel les clients sont sujets des attaques de type man-in-the-middle.

La majorit des serveurs PostgreSQL connects Internet ne prennent pas en charge le chiffrement

Cela nous laisse 160 310 serveurs PostgreSQL avec des certificats qui ne sont ni expirs ni auto-signs. Le chiffrement des connexions ces serveurs n’est toujours pas garanti, car de nombreux clients PostgreSQL n’activent pas les connexions SSL par dfaut, et ceux qui le font ne valideront pas ncessairement le certificat du serveur par dfaut. De mme, les serveurs PostgreSQL qui prennent en charge SSL et disposent de certificats SSL valides n’exigent pas toujours que ces certificats soient utiliss. La prise en charge du chiffrement semble tre mieux que rien, mais tant donn les valeurs par dfaut non scurises des clients, ce n’est pas beaucoup mieux que l’absence de chiffrement.

Dduire si SSL est ncessaire partir des messages d’erreur de connexion

Nous pouvons en apprendre un peu plus sur les exigences de chiffrement des serveurs PostgreSQL en examinant les messages d’erreur renvoys lorsqu’un client tente de se connecter chaque serveur. Shodan scanne chaque IP avec un client libpq configur pour « prfrer » SSL (mais en passant un nom de base de donnes de template0, un nom d’utilisateur de postgres, et aucun mot de passe). Lorsqu’il est configur en mode « prefer », le client essaiera de se connecter nouveau si la premire tentative qui demandait le SSL donne lieu une erreur. Nous avons utilis le contenu des erreurs, en combinaison avec la prsence/absence d’un certificat, pour dduire le statut de support SSL de ces serveurs PostgreSQL.

[CENTER]Au maximum, environ 14 % des serveurs PostgreSQL connects Internet requirent le SSL. 23% supportent le chiffrement mais ne l’exigent pas[/CENTER

Nous avons constat que, sur les quelque 820 000 serveurs PostgreSQL de l’enqute, 64 % ne prenaient pas en charge SSL. Un autre 23 % supportait mais n’exigeait pas l’utilisation de SSL. Seuls 7 % d’entre eux exigeaient probablement ou certainement le cryptage. Pour les autres 7 %, nous avons pu tablir que SSL tait support mais nous n’avons pas pu faire d’autres dductions quant la ncessit de son utilisation.

C’est un triste tat de fait. La grande majorit des serveurs PostgreSQL qui coutent sur Internet ne prennent pas du tout en charge les connexions cryptes ou bien ils prennent en charge le cryptage mais acceptent le trafic non crypt. Il y a pire : les clients SQL ont le choix d’utiliser ou non le chiffrement lorsqu’ils se connectent un serveur PostgreSQL, et la plupart d’entre eux sont plus qu’heureux de ne pas le faire. Pour comprendre ce comportement peu sr, nous devons prendre un moment pour comprendre comment SSL fonctionne rellement avec PostgreSQL.

Voici, quelques principes de fonctionnement des connexions SSL dans PostgreSQL

Le client et le serveur ont tous deux leur mot dire quant l’utilisation du chiffrement. Si le client tente d’tablir une connexion crypte, le serveur peut accepter ou refuser cette demande. Le client peut alors choisir d’accepter une connexion non chiffre ou d’abandonner. Si le client demande une connexion non crypte, le serveur peut choisir d’accepter cette connexion ou de l’abandonner ;
La validation du certificat, le processus par lequel le client dtermine si le certificat prsent par le serveur est lgitime, est galement configurable. La validation du certificat a lieu pendant la poigne de main TLS. Elle empche les serveurs malveillants de se faire passer pour le vritable serveur auquel un client avait l’intention de se connecter (attaque de type man-in-the-middle). Il s’agit d’une exigence pour une connexion rellement scurise ;
Votre client ne vous dira probablement pas si votre connexion est non chiffre , souligne Jonathan Mortensen. Vous avez peut-tre remarqu qu’il y a plusieurs chemins qui sautent SSL alors qu’un seul chemin (le client et le serveur acceptant une connexion SSL) dmarre une connexion SSL chiffre. La plupart des clients PostgreSQL ont un paramtre, souvent nomm sslmode, qui spcifie le(s) chemin(s) essayer. De nombreux clients SQL sont configurs par dfaut pour ne pas tenter de connexion chiffre du tout ou pour revenir silencieusement une connexion non chiffre si le serveur ne supporte pas SSL.

La bibliothque PostgreSQL standard pour Python est psycopg (2 et 3), qui utilise libpq, donc son mode par dfaut est de prfrer ssl. Cela signifie que les mthodes de connexion tenteront d’abord une connexion chiffre, mais se rabattront ensuite sur une mthode non crypte si le serveur ne supporte pas SSL. Les autres bibliothques de langage : jdbc, npgsql, node-postgres et pgx – ont SSL dsactiv par dfaut, l’utilisateur est donc responsable de la configuration du chiffrement.

MySQL

MySQL utilise une scurit base sur des listes de contrle d’accs (ACL) pour toutes les connexions, requtes et autres oprations que les utilisateurs peuvent tenter d’effectuer. Il existe galement un support pour les connexions chiffres par SSL entre les clients et les serveurs MySQL. La plupart des concepts abords ici ne sont pas du tout spcifiques MySQL ; les mmes ides gnrales s’appliquent presque toutes les applications.

Lorsque vous vous connectez un serveur MySQL, vous devez utiliser un mot de passe. Le mot de passe n’est pas transmis en clair lors de la connexion. Toutefois, les autres informations sont transfres sous forme de texte et peuvent tre lues par toute personne capable de surveiller la connexion. Si la connexion entre le client et le serveur passe par un rseau non fiable et que cela inquite, il est possible dutiliser le protocole compress pour rendre le trafic beaucoup plus difficile dchiffrer. Il est galement possible dutiliser le support SSL interne de MySQL pour rendre la connexion encore plus sre. Il est galement possible dutiliser SSH pour obtenir une connexion TCP/IP chiffre entre un serveur MySQL et un client MySQL.

Avec une connexion non chiffre entre le client MySQL et le serveur, une personne ayant accs au rseau pourrait observer tout le trafic et inspecter les donnes envoyes ou reues entre le client et le serveur. Les algorithmes de chiffrement doivent inclure des lments de scurit pour rsister de nombreux types d’attaques connues, comme la modification de l’ordre des messages chiffrs ou la relecture des donnes.

MySQL prend en charge les connexions chiffres entre les clients et le serveur l’aide du protocole TLS (Transport Layer Security). TLS est parfois appel SSL (Secure Sockets Layer) mais MySQL n’utilise pas rellement le protocole SSL pour les connexions chiffres car son chiffrment est faible. TLS utilise des algorithmes de chiffrement pour garantir la fiabilit des donnes reues sur un rseau public. Il dispose de mcanismes pour dtecter la modification, la perte ou la relecture des donnes. TLS intgre galement des algorithmes qui permettent la vrification de l’identit l’aide de la norme X.509.

La norme X.509 permet d’identifier une personne sur Internet. En termes simples, il doit exister une entit appele autorit de certification (ou CA) qui attribue des certificats lectroniques toute personne qui en a besoin. Les certificats s’appuient sur des algorithmes de chiffrement asymtrique qui possdent deux cls de chiffrement (une cl publique et une cl secrte). Le propritaire d’un certificat peut prsenter le certificat une autre partie comme preuve d’identit. Un certificat est constitu de la cl publique de son propritaire. Toute donne chiffre l’aide de cette cl publique ne peut tre dchiffre qu’ l’aide de la cl secrte correspondante, qui est dtenue par le propritaire du certificat.

Le support des connexions chiffres dans MySQL est assur par OpenSSL. Rappelons que OpenSSL est une bote outils de chiffrement comportant deux bibliothques, libcrypto et libssl, fournissant respectivement une implmentation des algorithmes cryptographiques et du protocole de communication SSL/TLS, ainsi qu’une interface en ligne de commande, Openssl. Dveloppe en C, OpenSSL est disponible sur les principaux systmes d’exploitation et dispose de nombreux wrappers ce qui la rend utilisable dans une grande varit de langages informatiques. Utilis par deux tiers des sites Web en 2014, la documentation dOpenSSL a augment de 94 % depuis OpenSSL 1.1.1 et le nombre de lignes de code dans nos tests a augment de 54 % (aprs ajustement).

Par dfaut, les instances MySQL se lient une bibliothque OpenSSL installe et disponible au moment de l’excution pour la prise en charge des connexions chiffres et d’autres oprations lies au chiffrement. Il est possible de compiler MySQL partir des sources et utiliser l’option CMake WITH_SSL pour spcifier le chemin d’accs une version particulire d’OpenSSL installe ou un paquetage systme OpenSSL alternatif. Dans ce cas, MySQL slectionne cette version.

De MySQL 8.0.11 8.0.17, il tait possible de compiler MySQL en utilisant wolfSSL comme alternative OpenSSL. A partir de MySQL 8.0.18, le support de wolfSSL est supprim et toutes les compilations MySQL utilisent OpenSSL. Si MySQL est compil avec une version d’OpenSSL et que lutilisateur souhaite passer une autre version sans recompiler, il peut le faire en modifiant le chemin du chargeur de bibliothque dynamique (LD_LIBRARY_PATH sur les systmes Unix ou PATH sur les systmes Windows). Supprimez le chemin d’accs la version compile d’OpenSSL, et ajoutez le chemin d’accs la version de remplacement, en la plaant avant toute autre bibliothque OpenSSL sur le chemin d’accs. Au dmarrage, lorsque MySQL ne trouve pas la version d’OpenSSL spcifie avec WITH_SSL sur le chemin, il utilise la premire version spcifie sur le chemin la place.

Par dfaut, les programmes MySQL tentent de se connecter en utilisant le chiffrement si le serveur supporte les connexions chiffres, et reviennent une connexion non chiffre si une connexion chiffre ne peut tre tablie. MySQL effectue le chiffrement sur une base par connexion, et l’utilisation du chiffrement pour un utilisateur donn peut tre facultative ou obligatoire. Cela permet de choisir une connexion chiffre ou non chiffre en fonction des exigences des applications individuelles.

Source : Jonathan Mortensen

Et vous ?

Pensez-vous que l’analyse de Jonathan Mortensen est pertinente ou pas, et pourquoi ?