PostgreSQL dispose d'un support natif des connexions SSL pour crypter les connexions client/serveur et améliorer ainsi la sécurité. Voir la Section 18.9 pour des détails sur la fonctionnalité SSL côté serveur.
libpq lit le fichier de configuration système
d'OpenSSL. Par défaut, ce fichier est nommé
openssl.cnf
et est placé dans le répertoire indiqué par
openssl version -d
. Cette valeur par défaut peut être
surchargé en configurant la variable d'environnement
OPENSSL_CONF
avec le nom du fichier de configuration
souhaité.
Par défaut, PostgreSQL ne vérifie pas le certificat du serveur. Cela signifie qu'il est possible de se faire passer pour le serveur final (par exemple en modifiant un enregistrement DNS ou en prenant l'adresse IP du serveur) sans que le client ne le sache. Pour empêcher ceci, le client doit être capable de vérifier l'identité du serveur via une chaîne de confiance. Une chaîne de confiance est établie en plaçant le certificat racine auto-signé d'une autorité de certificats (CA) sur un ordinateur et un certificat feuille signé par le certificat racine sur un autre ordinateur. Il est aussi possible d'utiliser un certificat « intermédiaire » signé par le certificat racine et qui signe des certificats feuilles.
Pour permettre au client de vérifier l'identité du serveur, placez un certificat racine sur le client et un certificat feuille signé par le certificat racine sur le serveur. Pour permettre au serveur de vérifier l'identité du client, placez un certificat racine sur le serveur et un certificat feuille signé par le certificat racine sur le client. Un ou plusieurs certificats intermédiaires (habituellement stockés avec le certificat feuille) peuvent aussi être utilisés pour lier le certificat feuille au certificat racine.
Une fois qu'une chaîne de confiance a été établie, il existe deux façons
pour le client de valider le certificat feuille envoyé par le serveur. Si
le paramètre sslmode
est configuré à verify-
ca
, libpq vérifiera que le serveur est de confiance en vérifiant
la chaîne de certificats jusqu'au certificat racine stocké sur le client.
Si sslmode
est configuré à verify-
full
, libpq va aussi vérifier que le nom
d'hôte du serveur correspond au nom stocké dans le certificat du serveur.
La connexion SSL échouera si le certificat du serveur n'établit pas ces
correspondances. La connexion SSL échouera si le certificat du serveur ne
peut pas être vérifié. verify-full
est recommandé pour
les environnements les plus sensibles à la sécurité.
En mode verify-full
, le nom de l'hôte est mis
en correspondance avec le ou les attributs "Subject Alternative
Name" du certificat, ou avec l'attribut "Common Name" si aucun
"Subject Alternative Name" de type dNSName
est présent. Si le nom du
certificat débute avec le caractère étoile (*
),
le caractère étoile sera traité comme un métacaractère qui
correspondra à tous les caractères à l'exception
du point. Cela signifie que le certificat ne pourra pas
être utilisé pour des sous-domaines complets. Si la connexion se
fait en utilisant une adresse IP au lieu d'un nom d'hôte, l'adresse
IP sera vérifiée (sans faire de recherche DNS).
Pour permettre la vérification du certificat du serveur, un ou plusieurs
certificats racines doivent être placés dans le fichier
~/.postgresql/root.crt
du répertoire personnel de
l'utilisateur (sur Windows, le fichier est nommé
%APPDATA%\postgresql\root.crt
). Les certificats
intermédiaires doivent aussi être ajoutés au fichier s'ils sont nécessaires
pour lier la chaîne de certificat envoyée par le serveur aux certificats
racines stockés sur le client.
Les entrées de la liste de révocation des certificats (CRL) sont aussi
vérifiées si le fichier ~/.postgresql/root.crl
existe
(%APPDATA%\postgresql\root.crl
sur Microsoft
Windows).
L'emplacement du certificat racine et du CRL peuvent être changés avec
les paramètres de connexion sslrootcert
et
sslcrl
, ou les variables d'environnement
PGSSLROOTCERT
et PGSSLCRL
.
Pour une compatibilité ascendantes avec les anciennes versions de
PostgreSQL, si un certificat racine d'autorité existe, le comportement
de sslmode
=require
sera identique
à celui de verify-ca
. Cela signifie que le
certificat du serveur est validé par l'autorité de certification. Il ne
faut pas se baser sur ce comportement. Les applications qui ont besoin
d'une validation du certificat doivent toujours utiliser
verify-ca
ou verify-full
.
Si le serveur tente de vérifier l'identité du client en réclamant le
certificat feuille du client, libpq enverra le
certificat stocké dans le fichier
~/.postgresql/postgresql.crt
du répertoire personnel
de l'utilisateur. Les certificats doivent chaîner vers le certificat racine
de confiance du serveur. Un fichier de
clé privé correspondant ~/.postgresql/postgresql.key
doit aussi être présent. Sur
Microsoft Windows, ces fichiers sont nommés
%APPDATA%\postgresql\postgresql.crt
et
%APPDATA%\postgresql\postgresql.key
.
L'emplacement des fichiers certificat et clé peut être surchargé par les
paramètres de connexion sslcert
et
sslkey
, ou par les variables d'environnement
PGSSLCERT
et PGSSLKEY
.
Sur les systèmes Unix, les droits sur le fichier de clé privée ne doit pas
permettre l'accès au monde et au groupe ; vous pouvez vous en assurer
avec une commande telle que chmod 0600
~/.postgresql/postgresql.key
. Il est aussi possible de rendre
root propriétaire deu fichier et d'avoir le droit d'accès pour le groupe
(autrement dit, les droits 0640
). Cette configuration est
prévue pour les installations où les fichiers certificat et clé sont gérés
par le système d'exploitation. L'utilisateur de
libpq devra alors devenir membre du group qui a
accès à ces fichiers certificat et clé. (Sur Microsoft Windows, aucune
vérification n'est effectuée sur les droits des fichiers car le répertoire
%APPDATA%\postgresql
est supposé sécurisé.)
Le premier certificat dans postgresql.crt
doit être le
certificat du client parce qu'il doit correspondre à la clé privée du
client. Les certificats « intermédiaires » peuvent être ajoutés
au fichier en option -- le faire permet d'éviter d'avoir à stocker les
certificats intermédiaires sur le fichier root.crt
du
serveur.
Pour des instructions sur la création de certificats, voir Section 18.9.3.
Les différentes valeurs du paramètre sslmode
fournissent
différents niveaux de protection. SSL peut fournir une protection contre trois types d'attaques différentes :
Si une troisième partie peut examiner le trafic réseau entre le client et le serveur, il peut lire à la fois les informations de connexion (ceci incluant le nom de l'utilisateur et son mot de passe) ainsi que les données qui y passent. SSL utilise le chiffrement pour empêcher cela.
Si une troisième partie peut modifier les données passant entre le client et le serveur, il peut prétendre être le serveur et, du coup, voir et modifier les données y compris si elles sont chiffrées. La troisième partie peut ensuite renvoyer les informations de connexion et les données au serveur d'origine, rendant à ce dernier impossible la détection de cette attaque. Les vecteurs communs pour parvenir à ce type d'attaque sont l'empoisonnement des DNS et la récupération des adresses IP où le client est dirigé vers un autre serveur que celui attendu. Il existe aussi plusieurs autres méthodes d'attaque pour accomplir ceci. SSL utilise la vérification des certificats pour empêcher ceci, en authentifiant le serveur auprès du client.
Si une troisième partie peut prétendre être un client autorisé, il peut tout simplement accéder aux données auquel il n'a pas droit. Typiquement, cela peut arrier avec une gestion incorrecte des mots de passe. SSL utilise les certificats clients pour empêcher ceci, en s'assurant que seuls les propriétaires de certificats valides peuvent accéder au serveur.
Pour qu'une connexion soit sûre, l'utilisation de SSL doit être configurée
sur le client et sur le serveur avant que
la connexion ne soit effective. Si c'est seulement configuré sur le serveur,
le client pourrait envoyer des informations sensibles (comme les mots de
passe) avant qu'il ne sache que le serveur réclame une sécurité importante.
Dans libpq, les connexions sécurisées peuvent être garanties en configurant le paramètre
sslmode
à verify-full
ou
verify-ca
, et en fournissant au système un certificat
racine à vérifier. Ceci est analogue à l'utilisation des URL
https
pour la navigation web chiffrée.
Une fois que le serveur est authentifié, le client peut envoyer des données sensibles. Cela signifie que jusqu'à ce point, le client n'a pas besoin de savoir si les certificats seront utilisés pour l'authentification, rendant particulièrement sûr de ne spécifier que ceci dans la configuration du serveur.
Toutes les options SSL ont une surcharge du type
chiffrement et échange de clés. Il y a donc une balance entre performance et
sécurité. Tableau 33.1 illustre les risques que les différentes valeurs
de sslmode
cherchent à protéger, et ce que cela apporte
en sécurité et fait perdre en performances.
Tableau 33.1. Description des modes SSL
sslmode | Protection contre l'écoute | Protection contre l'attaque MITM | Remarques |
---|---|---|---|
disable | Non | Non | Peu m'importe la sécurité, je ne veux pas la surcharge apportée par le chiffrement. |
allow | Peut-être | Non | Peu m'importe la sécurité, mais je vais accepter la surcharge du chiffrement si le serveur insiste là-dessus. |
prefer | Peut-être | Non | Peu m'importe la sécurité, mais j'accepte la surcharge du chiffrement si le serveur le supporte. |
require | Oui | Non | Je veux chiffrer mes données, et j'accepte la surcharge. Je fais confiance au résreau pour me connecter toujours au serveur que je veux. |
verify-ca | Oui | Dépend de la politique du CA | Je veux chiffrer mes données, et j'accepte la surcharge. Je veux aussi être sûr que je me connecte à un serveur en qui j'ai confiance. |
verify-full | Oui | Oui | Je veux chiffrer mes données, et j'accepte la surcharge. Je veux être sûr que je me connecte à un serveur en qui j'ai confiance et que c'est bien celui que j'indique. |
La différence entre verify-ca
et verify-full
dépend de la politique du CA racine. Si un
CA publique est utilisé, verify-ca
permet
les connexions à un serveur que quelqu'un d'autre a pu
enregistrer avec un CA accepté. Dans ce cas,
verify-full
devrait toujours être utilisé. Si un
CA local est utilisé, voire même un certificat signé
soi-même, utiliser verify-ca
fournit souvent suffisamment de
protection.
La valeur par défaut pour sslmode
est prefer
.
Comme l'indique la table ci-dessus, cela n'a pas de sens d'un point de vue
de la sécurité, et cela ne promet qu'une surcharge en terme de performance
si possible. C'est uniquement fourni comme valeur par défaut pour la
compatibilité ascendante, et n'est pas recommandé pour les déploiements de
serveurs nécessitant de la sécurité.
Tableau 33.2 résume les fichiers liés à la configuration de SSL sur le client.
Tableau 33.2. Utilisation des fichiers SSL libpq/client
Fichier | Contenu | Effet |
---|---|---|
~/.postgresql/postgresql.crt | certificat client | envoyé par le serveur |
~/.postgresql/postgresql.key | clé privée du client | prouve le certificat client envoyé par l'utilisateur ; n'indique pas que le propriétaire du certificat est de confiance |
~/.postgresql/root.crt | autorité de confiance du certificat | vérifie que le certificat du serveur est signé par une autorité de confiance |
~/.postgresql/root.crl | certificats révoqués par les autorités | le certificat du serveur ne doit pas être sur cette liste |
Si votre application initialise les bibliothèques libssl
et/ou libcrypto
et que libpq
est construit avec le support de SSL, vous devez appeler
la fonction PQinitOpenSSL
pour indiquer à
libpq que les bibliothèques
libssl
et/ou libcrypto
ont été
initialisées par votre application, de façon à ce que
libpq n'initialise pas elle-aussi ces
bibliothèques.
PQinitOpenSSL
Permet aux applications de sélectionner les bibliothèques de sécurité à initialiser.
void PQinitOpenSSL(int do_ssl, int do_crypto);
Quand do_ssl
est différent de zéro,
libpq initialisera la bibliothèque
OpenSSL avant d'ouvrir une connexion à la base
de données. Quand do_crypto
est différent de
zéro, la bibliothèque libcrypto
sera initialisée. Par
défaut (si PQinitOpenSSL
n'est pas appelé), les deux
bibliothèques sont initialisées. Quand le support de SSL n'est pas
intégré, cette fonction est présente mais ne fait rien.
Si votre application utilise et initialise soit
OpenSSL soit libcrypto
,
vous devez appeler cette fonction avec des zéros
pour les paramètres appropriés avant d'ouvrir la première connexion à la
base de données. De plus, assurez-vous que vous avez fait cette
initialisation avant d'ouvrir une connexion à la base de données.
PQinitSSL
Permet aux applications de sélectionner les bibliothèques de sécurité à initialiser.
void PQinitSSL(int do_ssl);
Cette fonction est équivalent à
PQinitOpenSSL(do_ssl, do_ssl)
. C'est suffisant pour les
applications qui initialisent à la fois OpenSSL
etlibcrypto
ou aucune des deux.
PQinitSSL
est présente depuis
PostgreSQL 8.0, alors que
PQinitOpenSSL
a été ajoutée dans
PostgreSQL 8.4, donc
PQinitSSL
peut être préférée pour les applications
qui ont besoin de fonctionner avec les anciennes versions de
libpq.