La majorité des serveurs PostgreSQL sur Internet ne seraient pas sécurisés, selon Jonathan Mortensen,

Alors qu'il est souvent considéré comme un système plus fiable et plus robuste que MySQL

MySQL utilise une sécurité basée sur des listes de contrôle d'accès (ACL) pour toutes les connexions, requêtes et autres opérations que les utilisateurs peuvent tenter d'effectuer. Il prend en charge les connexions chiffrées entre les clients et le serveur à l'aide du protocole TLS (Transport Layer Security). De l’avis 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 derrière ces concurrents en matière de sécurité. En comparaison, selon Google, plus de 96 % des chargements de pages dans Chrome sur un Mac sont chiffrés. Les 100 premiers sites Web prennent en charge le chiffrement et 97 d'entre eux l'utilisent par défaut.

La situation ne s'arrête pas aux serveurs PostgreSQL : la plupart des clients SQL populaires seraient plus que favorables aux connexions non chiffrées sans avertissement. Jonathan Mortensen et son équipe ont mené une enquête informelle auprès de 22 clients SQL populaires et ont constaté que seuls deux d'entre eux exigent des connexions chiffrées par défaut. Six autres demandent le chiffrement, mais acceptent en sourdine une connexion non chiffrée. Les 14 clients restants demandent à l'utilisateur d'opter pour l'utilisation de SSL ; les connexions sont non chiffrées par défaut.


« Lorsque vous vous connectez à un site Web avec votre navigateur, les données que vous envoyez et recevez sont probablement chiffrées. Il est donc étonnant que les données envoyées vers et depuis les serveurs PostgreSQL connectés à Internet soient très probablement non chiffrées. C'est un problème », é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 connectés à l'Internet : une recherche sur shodan.io montre un échantillon de plus de 820 000 serveurs PostgreSQL connectés à l'Internet entre le 1er et le 29 septembre. Seuls 36 % des serveurs examinés 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 indésirable des données transmises vers et depuis le serveur. Pire encore, 41 serveurs PostgreSQL en ligne n'étaient absolument pas protégés, ne disposant même pas d'un mot de passe.

Certificats autosignés et expirés

Il ne suffit pas d'avoir un certificat. Près de 12 000 (4,0 %) des certificats étaient expirés. En outre, plus de 128 000 (43,3 %) des certificats étaient autosignés. Les connexions aux serveurs avec des certificats autosignés sont chiffrées, mais les certificats ne confèrent souvent pas de confiance : généralement, ils ne sont ni émis ni validés par une autorité de certification, ils n'expirent pas et ne peuvent pas être révoqués. La plupart des clients ne disposent pas d'un certificat racine pour un certificat autosigné 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 connectés à Internet ne prennent pas en charge le chiffrement

Cela nous laisse 160 310 serveurs PostgreSQL avec des certificats qui ne sont ni expirés ni autosignés. Le chiffrement des connexions à ces serveurs n'est toujours pas garanti, car de nombreux clients PostgreSQL n'activent pas les connexions SSL par défaut, et ceux qui le font ne valideront pas nécessairement le certificat du serveur par défaut. De même, les serveurs PostgreSQL qui prennent en charge SSL et disposent de certificats SSL valides n'exigent pas toujours que ces certificats soient utilisés. La prise en charge du chiffrement semble être mieux que rien, mais étant donné les valeurs par défaut non sécurisées des clients, ce n'est pas beaucoup mieux que l'absence de chiffrement.

Déduire si SSL est nécessaire à 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 renvoyés lorsqu'un client tente de se connecter à chaque serveur. Shodan scanne chaque IP avec un client libpq configuré pour "préférer" SSL (mais en passant un nom de base de données 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 première tentative qui demandait le SSL donne lieu à une erreur. Nous avons utilisé le contenu des erreurs, en combinaison avec la présence/absence d'un certificat, pour déduire le statut de support SSL de ces serveurs PostgreSQL.

Au maximum, environ 14 % des serveurs PostgreSQL connectés à Internet requièrent le SSL. 23% supportent le chiffrement mais ne l'exigent pas

Nous avons constaté que, sur les quelque 820 000 serveurs PostgreSQL de l'enquête, 64 % ne prenaient pas en charge SSL. 23 % supportaient, mais n'exigeaient 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 déductions quant à la nécessité 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 cryptées 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 sûr, nous devons prendre un moment pour comprendre comment SSL fonctionne réellement avec PostgreSQL.

Voici, quelques principes de fonctionnement des connexions SSL dans PostgreSQL

1. [...