Support TLS de PostfixSupport TLS de PostfixEn activant le support TLS dans Postfix, vous n'obtenez pas seulement la possibilité de chiffrer les messages et d'authentifier les clients et les serveurs. Vous activez également des milliers de lignes de code le la librairie OpenSSL. En supposant qu'OpenSSL est écrit avec autant de soin que le code écrit par Wietse, chaque groupe de 1000 lignes introduit statistiquement un bug dans Postfix.
La couche de sécurité du transport TLS (Transport Layer Security, également appelée SSL) fournit les authentifications basées sur des certificats et le chiffrement des sessions. Une session chiffrée protège les informations transmises par message SMTP ou par les authentifications SASL.
Postfix version 2.2 introduit le support TLS tel que décrit dans la RFC 3207. Le support TLS pour les versions antérieures de Postfix était disponible sous forme de patch. Le paragraphe "Compatibilité avec le support TLS Postfix < 2.2" ci-après présente les différences entre ces implémentations.
Sujets abordés par ce document :
Et last but not least pour les impatients :
Le schéma ci-dessous montre les principaux éléments de l'architecture TLS de Postfix et leurs relations. Les éléments colorés contenant un chiffre représentent des programmes démons de Postfix. Les autres éléments colorés représentent les éléments de stockages.
Le serveur smtpd(8) implémente la partie serveur de TLS sur SMTP.
Le client smtp(8) implémente la partie cliente de TLS sur SMTP.
Le serveur tlsmgr(8) maintient le générateur de nombres pseudo-aléatoires (PRNG) qui égraine les moteurs TLS engines des processus du serveur smtpd(8) et du client smtp(8), et maintient le fichier de cache des clefs de session TLS.
| Réseau-> | smtpd(8) |
<--graine-- <-session-> | tlsmgr(8) |
--graine--> <-session-> | smtp(8) | ->Réseau | ||||||||||
| | | |
| ||||||||||||||
|
cache des clefs de session smtpd | fichier d'état du PRNG | cache des clefs de session smtp |
||||||||||||||
Pour compiler Postfix avec le support de TLS, nous devons d'abord générer les fichiers make(1) avec les définitions nécessaires. Ceci est fait en invoquant la commande "make makefiles à la racine du répertoire des sources de Postfix avec les arguments présentés ci-dessous.
NOTE : n'utilisez pas Gnu TLS. Il interrompra spontanément un processus démon de Postfix qui se termine avec le code de retour 2 au lieu de permettre à Postfix de 1) rapporter l'erreur dans le journal et de 2) fournir le service en clair lorsqu'il est approprié.
Si les fichiers include d'OpenSSL (tel ssl.h) sont dans le répertoire /usr/include/openssl, et que les librairies OpenSSL (telles libssl.so et libcrypto.so) sont dans le répertoire /usr/lib :
% make tidy # si vous avez déjà compilé les sources dans ce répertoire % make makefiles CCARGS="-DUSE_SSL" AUXLIBS="-lssl -lcrypto"
Si les fichiers include d'OpenSSL (tels ssl.h) sont dans le répertoire /usr/local/include/openssl, et que les librairies OpenSSL (telles libssl.so et libcrypto.so) sont dans le répertoire /usr/local/lib :
% make tidy # si vous avez déjà compilé les sources dans ce répertoire
% make makefiles CCARGS="-DUSE_SSL -I/usr/local/include" \
AUXLIBS="-L/usr/local/lib -lssl -lcrypto"
Sur Solaris, utilisez l'option -R comme indiqué ci-dessous :
% make tidy # si vous avez déjà compilé les sources dans ce répertoire
% make makefiles CCARGS="-DUSE_TLS -I/usr/local/include" \
AUXLIBS="-R/usr/local/lib -L/usr/local/lib -lssl -lcrypto"
Si vous devez appliquer d'autres personnalisations (telles les bases de données Berkeley DB, MySQL, PosgreSQL, LDAP ou SASL), lisez les documents README de Postfix correspondants, et combinez leurs instructions "make makefiles" avec les instructions ci-dessous :
% make tidy # si vous avez déjà compilé les sources dans ce répertoire
% make makefiles CCARGS="-DUSE_SSL \
(autres options -D or -I)" \
AUXLIBS="-lssl -lcrypto \
(autres options -l pour les librairies de /usr/lib \
-L/chemin/ + -l options pour les autres librairies)"
Pour terminer le processus de compilation, lisez les instructions de la page INSTALL. Le support TLS désactivé par défaut dans Postfix, ainsi vous pouvez démarrer Postfix tel qu'il est installé.
Sujets abordés dans ce paragraphe :
Pour utiliser TLS, le serveur SMTP de Postfix a besoin d'un certificat et d'une clef privée. Les deux doivent être au format PEM. La clef privée ne doit pas être chiffrée, ce qui signifie : la clef doit être accessible sans mot-de-passe. Le certificat et la clef privée peuvent être dans le même fichier.
Les certificats RSA et DSA sont tous deux supportés. Généralement, vous n'aurez que des certificats RSA issus d'une autorité de certification commerciale. En complément, les outils fournis avec OpenSSL généreront par défaut des certificats RSA. Vous pouvez avoir les deux en même temps, auquel cas le chiffrement utilisé détermine le certificat présenté. Pour les clients Netscape et les clients SSL ouverts sans choix particulier de chiffrement, le certificat RSA est préferré.
Pour permettre aux clients SMTP distants de vérifier le certificat du serveur SMTP de Postfix, le certificat de l'autorité (dans le cas d'une chaîne de certification, tous les certificats des autorités) doit être disponible. Vous devrez ajouter ces certificats au certificat du serveur, le certificat en premier suivi des autorités fournissant le certificat.
Exemple: le certificat pour "server.dom.ain" est issu de "intermediate CA" elle-même certifiée par "root CA". Créez le fichier server.pem avec :
cat server_cert.pem intermediate_CA.pem root_CA.pem > server.pem
Le certificat d'un serveur SMTP de Postfix utilisé ici doit être utilisable comme certificat d'un serveur SSL et donc passer le test "openssl verify -purpose sslserver ...".
Un client qui agrée l'autorité de certification (CA) racine dispose d'une copie locale de son certificat, donc il n'est pas nécessaire d'inclure le certificat racine ici. On réduit ainsi le surplus de trafic réseau lié à TLS.
Si vous voulez que le serveur SMTP de Postfix accepte les certificats des clients SMTP issus de ces mêmes autorités, vous pouvez également ajouter les certificats des autorités au fichier $smtpd_tls_CAfile ou les installer dans le répertoire $smtpd_tls_CApath. Lorsque vous utilisez une autorité racine, il n'est pas nécessaire d'agréer explicitement les autorités intermédiaires signées par l'autorité racine, sauf si le nombre $smtpd_tls_ccert_verifydepth est inférieur au nombre d'autorités de la chaine de certification du client. Avec une profondeur de vérification de 1, vous ne pouvez vérifier que les certificats directement issus d'une des autorités agréées. Avec une profondeur de 2, vous pouvez vérifier les certificats signés par l'autorité racine ou par une intermédiaire directe (sous réserve que le client soit correctement configuré pour fournir son certificat d'autorité intermédiaire).
Exemples de clefs et certificats RSA :
/etc/postfix/main.cf
smtpd_tls_cert_file = /etc/postfix/server.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
L'équivalent DSA :
/etc/postfix/main.cf
smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
smtpd_tls_dkey_file = $smtpd_tls_dcert_file
Pour vérifier un certificat client SMTP, le serveur SMTP de Postfix a besoin de connaître les certificats des autorités les fournissant. Ces certificats au format "pem" peuvent être stockés dans un seul fichier $smtpd_tls_CAfile ou dans de multiples fichiers, une CA par fichier dans le répertoire $smtpd_tls_CApath. Si vous utilisez un répertoire, n'oubliez pas de créer les nécessaires liens "hash" avec :
# $OPENSSL_HOME/bin/c_rehash /chemin/du/répertoire
Le fichier $smtpd_tls_CAfile contient les certificats d'une ou de plusieurs autorités agréées. Le fichier est ouvert (avec les privilèges root) avant que Postfix n'entre dans l'optionnelle cage chroot et n'a donc pas besoin d'être accessible depuis la cage.
Des autorités additionnelles peuvent être ajoutées via le répertoire $smtpd_tls_CApath, auquel cas les certificats sont lus (avec le compte $mail_owner) dans ce répertoire en cas de besoin. Ainsi, le répertoire $smtpd_tls_CApath doit être accessible depuis l'intérieur de la cage chroot.
Lorsque vous configurez Postfix pour exiger les certificats clients (en indiquant $smtpd_tls_ask_ccert = yes), tous les certificats présents dans $smtpd_tls_CAfile sont envoyés au client, afin de lui permettre de choisir une identité signée par une autorité que vous agréez. Si aucun fichier $smtpd_tls_CAfile n'est indiqué, aucune liste de préférence n'est envoyée et le client est libre de présenter le certificat de son choix. La plupart des clients utilisent une identité fixée sans examiner la liste de préférence et vous pouvez réduire le surplus de trafic lié à la négociation TLS en installant tout ou partie de vos certificats dans $smtpd_tls_CApath. Dans ce cas, vous n'êtes pas obligé de renseigner $smtpd_tls_CAfile.
Notez que bien que les certificats clients sont utilisés pour autoriser l'accès aux clients authentifiés par TLS, il est préférable de ne pas exiger de certificats clients, car outre l'augmentation de trafic, certains clients (notamment qmail dans certains cas) ne sont pas en mesure de compléter l'échange TLS lorsqu'un certificat client est exigé.
Exemple:
/etc/postfix/main.cf :
smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtpd_tls_CApath = /etc/postfix/certs
Pour obtenir des informations complémentaires sur l'activité TLS du serveur SMTP de Postfix, vous pouvez augmenter le niveau de log de 0 à 4. Chaque niveau de log inclut également les inforamtions des niveaux inférieurs.
0 Désactive l'enregistrement de l'activité TLS. 1 Enregistre les informations de négociation TLS et des certificats. 2 Enregistre les niveaux durant la négociation TLS. 3 Retranscrit en hexadecimal et ASCII le processus de négotiation TLS 4 Retranscrit en hexadecimal et ASCII toute la transmission après STARTTLS
Utilisez le niveau 3 seulement en cas de problème. L'utilisation du niveau 4 est vivement déconseillée.
Exemple :
/etc/postfix/main.cf :
smtpd_tls_loglevel = 0
Pour inclure les informations sur le protocole et le chiffrement utilisés ainsi que les CommonName du client et de l'autorité émettrice dans l'en-tête de message "Received:", mettez la variable smtpd_tls_received_header à "yes". La valeur par défaut est "no" car l'information n'est pas nécessairement authentique. Seule l'information enregistrée par la destination finale est fiable car les en-têtes peuvent être modifiés par les serveurs intermédiaires.
Exemple :
/etc/postfix/main.cf :
smtpd_tls_received_header = yes
Par défaut, TLS est désactivé dans le serveur SMTP de Postfix, ainsi aucune difference avec Postfix standard n'est visible. Activez-le explicitement en utilisant "smtpd_use_tls = yes".
Exemple :
/etc/postfix/main.cf :
smtpd_use_tls = yes
A partir de là, le serveur SMTP de Postfix annonce le support de STARTTLS aux clients SMTP mais n'exige pas les clients l'utilisent.
Note : lorsqu'un utilisateur non privilégié invoque "sendmail -bs", STARTTLS n'est jamais proposé en raison d'une insuffisance de privilèges pour accéder à la clef privée du serveur.
Vous pouvez FORCER l'emploi de TLS, ainsi le serveur SMTP de Postfix n'accepte aucune commande (à l'exception de QUIT bien sûr) sans chiffrement TLS, en indiquant "smtpd_enforce_tls = yes". En accord avec la RFC 2487 ceci NE DOIT PAS être fait dans le cas d'un serveur SMTP référencé et public. Donc cette option est désactivée par défaut et ne doit que rarement être utilisée.
Exemple :
/etc/postfix/main.cf :
smtpd_enforce_tls = yes
TLS est parfois utilisé dans le mode non standard "wrapper" où le serveur utilise systématiquement TLS au lieu d'annoncer le support de STARTTLS et attendre que les clients requièrent les service TLS. Certains clients, nommés Outlook [Express] prefèrent utiliser le mode "wrapper". Ceci est vrai pour OE (Win32 < 5.0 et Win32 >= 5.0 lorsque le port utilisé diffère de 25) et OE (5.01 Mac et tous les portages).
Il est strictement déconseillé d'utiliser ce mode dans main.cf. Si vous voulez supporter ce service, activez un port particulier dans master.cf et indiquez "-o smtpd_tls_wrappermode = yes" en option de la ligne de commande de smtpd(8). Le port 465 (smtps) a été choisi pour cette fonctionnalité.
Exemple :
/etc/postfix/main.cf :
smtpd_tls_wrappermode = no
Pour recevoir le certificat d'un client SMTP extérieur, le serveur SMTP de Postfix doit le demander explicitement en envoyant les certificats $smtpd_tls_CAfile au client. Malheureusement, les clients Netscape généreront une alerte si aucun certificat client ne correspond ou offriront à l'utilisateur un choix parmi une liste de certificats. Ceci peut être gênant, ainsi cette option est désactivée par défaut. Vous aurez également besoin du certificat si vous voulez acepter le relais par certificat avec, par exemple, l'option permit_tls_client_certs.
Exemple :
/etc/postfix/main.cf :
smtpd_tls_ask_ccert = no
Vous deciderez peut-être de requérir un certificat pour les client SMTP avant d'autoriser les connexions TLS. Cette fonctionnalité est incluse pour la perfection et implique "smtpd_tls_ask_ccert = yes".
Soyez attentif au fait que ceci interdit les connexions TLS sans certificat client conforme et n'a de sens que si les soumissions sans TLS sont désactivées (smtpd_enforce_tls = yes). Autrement, les clients pourront outrepasser la restriction simplement en n'utilisant pas STARTTLS.
Lorsque TLS n'est pas forcé, la connexion sera traitée ainsi seulement si "smtpd_tls_ask_ccert = yes", sinon un avertissement est enregistré.
Exemple :
/etc/postfix/main.cf :
smtpd_tls_req_ccert = no
Une profondeur de vérification des certificats de 1 est suffisante si le certificat est directement issu d'une autorité listée dans le fichier CA. La valeur par défaut (5) devrait suffire pour les chaînes plus longues (autorité racine certifiant une autorité de laquelle le certificat est issu...)
Exemple :
/etc/postfix/main.cf :
smtpd_tls_ccert_verifydepth = 5
Envoyer des données d'authentification sur un canal non crypté pose un problème de sécurité. Lorsque le chiffrement TLS est requis (smtpd_enforce_tls = yes), le serveur SMTP de Postfix annoncera AUTH et l'acceptera seulement après que la couche TLS ait été activée avec STARTTLS. Lorsque la couche TLS est optionnelle (smtpd_enforce_tls = no), il peut être pratique de n'offrir AUTH que si TLS est activé. Pour maintenir la compatibilité avec les clients non-TLS, la valeur par défaut est d'accepter AUTH sans chiffrement. Pour changer ce comportement, indiquez "smtpd_tls_auth_only = yes".
Exemple :
/etc/postfix/main.cf :
smtpd_tls_auth_only = no
Le serveur SMTP de Postfix et le client SMTP distant négocient une session qui utilise du temps CPU et de la bande passante. Par défaut, cette information de session est cachée seulement dans le processus smtpd(8) utilisant actuellement cette session et est perdue lorsque le processus s'arrête. Pour partager les informations de session entre de multiples processus smtpd(8), un cache de session persistant peut être utilisé. Vous pouvez utiliser tous les types de bases de données qui peuvent stocker des objets de plusieurs koctets et qui supportent l'opérateur de séquence. Les bases DBM ne peuvent être utilisées car elles ne stockent que de petits objets. Le cache est maintenu par le processus tlsmgr(8), il n'y a donc pas de problèmes d'accès concurrents. Le cache des sessions est fortement recommandé car le coût des négociations TLS répétées est très élevé.
Exemple :
/etc/postfix/main.cf :
smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache
Les informations de session cachées par les serveurs SMTP de Postfix expirent après un certain temps. Postfix/TLS n'utilise pas la valeur par défaut de OpenSSL (300 secondes), mais un temps plus long de 3600 secondes (=1 heure). La RFC 2246 recommande un maximum de 24 heures.
Exemple :
/etc/postfix/main.cf :
smtpd_tls_session_cache_timeout = 3600s
Le support TLS de Postfix introduit deux fonctionnalités additionelles pour le contrôle d'accès au serveur SMTP de Postfix :
- permit_tls_clientcerts
Autorise les requêtes des client SMTP si le certificat du client passe la vérification, et si son empreinte est listée dans la liste des certificats clients (voyez la présentation de relay_clientcerts ci-dessous).
- permit_tls_all_clientcerts
Autorise les requêtes des client SMTP si le certificat du client passe la vérification.
- check_ccert_access type:table
Si le certificat client passe la vérification, utilise son empreinte (fingerprint) comme clef pour la table d'accès indiquée.
La fonctionnalité permit_tls_all_clientcerts doit être utilisé avec précaution, car elle peut engendrer trop de permissions d'accès. Utilisez cette fonctionnalité seulement si une autorité particulière fournit les certificats client et seule cette autorité est reconnue dans le liste des autorités certifiées. Si d'autres autorités sont reconnues, tous les propriétaires de certificats valides seront autorisés. La fonctionnalité permit_tls_all_clientcerts peut être pratique pour un serveur relais créé spécialement.
Il est généralement recommandé de s'en tenir à la fonctionnalité permit_tls_clientcerts et de lister tous les certificats dans $relay_clientcerts, alors que permit_tls_all_clientcerts ne permet aucun contrôle lorsqu'un certificat ne doit plus être utilisé (un employé parti...).
Exemple :
/etc/postfix/main.cf :
smtpd_recipient_restrictions =
...
permit_tls_clientcerts
reject_unauth_destination
...
Les routines de manipulation des listes de Postfix donnent un traitement particulier aux espaces et à certains autres caractères, rendant impossible l'utilisation des noms des certificats. A la place, nous utilisons les empreintes des certificats qui sont difficiles à fausser mais faciles à utiliser dans les consultations. Les tables de correspondances de Postfix ont la forme de paires (clef, valeur) pairs. Puisque nous n'avons besoin que de la clef, la valeur peut être choisie librement, c'est à dire le nom de l'utilisateur ou de la machine.
Exemple :
/etc/postfix/main.cf :
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
/etc/postfix/relay_clientcerts :
D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
Pour influencer le schéma de sélection du chiffrement du serveur SMTP de Postfix, vous pouvez indiquer une chaîne listant les chiffrements. Pour une description plus détaillée, reportez-vous à la documentation OpenSSL. Si vous ne savez pas de quoi il s'agit, ne touchez à rien et laissez les valeurs (openssl-)compilées par défaut !
N'UTILISEZ PAS de guillemets "" pour encadrer la chaîne, indiquez juste une chaîne !!!
Exemple :
/etc/postfix/main.cf :
smtpd_tls_cipherlist = DEFAULT
Si vous voulez utiliser les avantages des chiffrements avec EDH, les paramètres DH sont nécessaires. Au lieu d'utiliser les paramètres DH compilés pour 1024bit et 512bit, il est préférable de générer vos "propres" parametres, entre autres les attaquants pourraient tenter une attaque force brute contre les paramètres utilisés par tout le monde. Pour cette raison, les paramètres choisits seront différents que ceux distribués avec les autres packages TLS.
Pour générer vos propres paramètres DH, utilisez :
% openssl gendh -out /etc/postfix/dh_1024.pem -2 -rand /var/run/egd-pool 1024 % openssl gendh -out /etc/postfix/dh_512.pem -2 -rand /var/run/egd-pool 512
Exemple :
/etc/postfix/main.cf :
smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
Le paramètre smtpd_starttls_timeout limite le temps d'écriture et de lecture des opérations TLS durant les procédures de démarrage et d'arrêt TLS.
Exemple :
/etc/postfix/main.cf :
smtpd_starttls_timeout = 300s
Sujets abordés dans ce paragraphe :
Durant la négociation de démarrage TLS, le client SMTP de Postfix peut presenter un certificat au serveur SMTP distant. Le client Netscape est plutôt intelligent ici et laisse l'utilisateur choisir seulement parmi les certificats qui correspondent aux certificats des autorités offerts par le serveur SMTP distant. Comme le client SMTP de Postfix utilise la fonction "SSL_connect()" du package OpenSSL, on ne peut choisir qu'un certificat. Ainis pour l'instant, le défaut est de n'utiliser aucun certificat ni clef sauf si un est explicitement indiqué ici.
Les certificats RSA et DSA sont tous deux supportés. Vous pouvez avoir les deux en même temps, auquel cas le chiffrement utilisé détermine le certificat présenté.
Il est possible pour le client SMTP de Postfix d'utiliser la même paire clef/certificat que le serveur SMTP de Postfix. Si un certificat est présenté, il doit être au format PEM. La clef privée ne doit pas être chiffrée, en d'autre termes, elle doit être accessible sans mot-de-passe. Les deux parties (certificat et clef privée) peuvent être dans le même fichier.
Pour les les serveurs SMTP distants vérifient le certificat du client SMTP de Postfix, le certificat de l'autorité (dans le cas d'une chaîne de certificat, tous les certificats des autorités) doivent être disponibles. Vous devrez ajouter ces certificats au certificat client : le certificat client en premier, puis les autorités émettrices.
Exemple : le certificat de "client.dom.ain" est issu de "intermediate CA" elle-même certifiée par "root CA". Créez le fichier client.pem avec :
% cat client_cert.pem intermediate_CA.pem root_CA.pem > client.pem
Un certificat client SMTP de Postfix fourni ici doit être utilisable comme certificat client SSL et donc passer le test "openssl verify -purpose sslclient ...".
Un serveur qui agrée une autorité racine dispose d'une copie locale du certificat de cette autorité, ainsi il n'est pas nécessaire de l'inclure ici. L'enlever du fichier "client.pem" reduit le surplus de trafic lié à l'échange TLS.
Si vous voulez que le client SMTP de Postfix accepte les certificats issus de ces autorités, vous devez également ajouter leurs certificats dans le fichier smtp_tls_CAfile, ou les installer dans le répertoire smtp_tls_CApath. Lorsque vous agréez une autorité racine, il n'est pas nécessaire d'agréer explicitement les autorités intermédiaires qu'elle a signé, sauf si le nombre $smtp_tls_scert_verifydepth est inférieur au nombre d'autorités de la chaine de certification. Avec une profondeur de 1, vous ne pouvez vérifier que les certificats directement issus d'une autorité agréée. Avec une profondeur de 2, vous pouvez vérifier les certificats signés par une autorité intermédiaire signée directement par une autorité que vous agréez (pour autant que le serveur soit correctement configuré pour fournir les certificats intermédiaires).
Exemples de clefs et certificats RSA :
/etc/postfix/main.cf :
smtp_tls_cert_file = /etc/postfix/client.pem
smtp_tls_key_file = $smtp_tls_cert_file
L'équivalent DSA :
/etc/postfix/main.cf :
smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
smtp_tls_dkey_file = $smtpd_tls_cert_file
Pour vérifier un certificat serveur SMTP extérieur, le client SMTP de Postfix doit reconnaître les certificats des autorités émettrices. Ces certificats au format PEM peuvent être stockés dans un seul fichier $smtp_tls_CAfile ou dans plusieurs fichiers dans le répertoire $smtp_tls_CApath. Si vous utilisez un répertoire, n'oubliez pas de créer les nécessaires liens "hash" avec :
# $OPENSSL_HOME/bin/c_rehash /chemin/vers/le/répertoire
Le fichier $smtpd_tls_CAfile contient les certificats d'une ou de plusieurs autorités agréées. Le fichier est ouvert (avec les privilèges root) avant que Postfix n'entre dans l'optionnelle cage chroot et n'a donc pas besoin d'être accessible depuis la cage.
Des autorités additionnelles peuvent être ajoutées via le répertoire $smtpd_tls_CApath, auquel cas les certificats sont lus (avec le compte $mail_owner) dans ce répertoire en cas de besoin. Ainsi, le répertoire $smtpd_tls_CApath doit être accessible depuis l'intérieur de la cage chroot.
Le choix entre $smtp_tls_CAfile et $smtpd_tls_CApath est une question d'espace/temps. S'il y a beaucoup d'autorités agréées, le coût de leur préchargement en mémoire peut dépasser l'économie d'un plus rapide accès lorsque le certificat est requis.
Exemple :
/etc/postfix/main.cf :
smtp_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_CApath = /etc/postfix/certs
Pour obtenir des informations complémentaires sur l'activité TLS du client SMTP de Postfix, vous pouvez augmenter le niveau de log de 0 à 4. Chaque niveau de log inclut également les inforamtions des niveaux inférieurs.
0 Désactive l'enregistrement de l'activité TLS. 1 Enregistre les informations de négociation TLS et des certificats. 2 Enregistre les niveaux durant la négociation TLS. 3 Retranscrit en hexadecimal et ASCII le processus de négotiation TLS 4 Retranscrit en hexadecimal et ASCII toute la transmission après STARTTLS
Exemple :
/etc/postfix/main.cf :
smtp_tls_loglevel = 0
Le serveur SMTP de Postfix et le client SMTP distant negocient une session qui utilise du temps CPU et de la bande passante. Par défaut, cette information de session est cachée seulement dans le processus smtpd(8) utilisant actuellement cette session et est perdue lorsque le processus s'arrête. Pour partager les informations de session entre de multiples processus smtpd(8), un cache de session persistant peut être utilisé. Vous pouvez utiliser tous les types de bases de données qui peuvent stocker des objets de plusieurs koctets et qui supportent l'opérateur de séquence. Les bases DBM ne peuvent être utilisées car elles ne stockent que de petits objets. Le cache est maintenu par le processus tlsmgr(8), il n'y a donc pas de problèmes d'accès concurrents. Le cache des sessions est fortement recommandé car le coût des négociations TLS répétées est très élevé. Les futurs serveurs SMTP de Postfix pourront limiter le nombre de sessions qu'un client est autorisé à négocier par unité de temps.
Exemple :
/etc/postfix/main.cf :
smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
Les informations de sessions cachées par les clients SMTP de Postfix expirent après un certian temps. Postfix/TLS n'utilise pas la valeur par défaut d'OpenSSL (300 secondes), mais un délai plus long de 3600 secondes (=1 heure). La RFC 2246 recommande un maximum de 24 heures.
Exemple :
/etc/postfix/main.cf :
smtp_tls_session_cache_timeout = 3600s
Par défaut, TLS est désactivé dans le client SMTP de Postfix, ainsi aucune différence avec Postfix classique n'est visible. Si vous activez TLS, le client SMTP de Postfix enverra STARTTLS lorsque le support TLS est annoncé par le serveur SMTP distant.
Lorsque le serveur accepte la commande STARTTLS, mais que la négociation TLS échoue et qu'aucun autre serveur n'est disponible, le client SMTP de Postfix retarde la tentative de livraison et le message reste en file d'attente. Après un échec de négociation, le canal de communication se trouve dans un état indéterminé et ne peut être réutilisé pour des livraisons en clair.
Exemple :
/etc/postfix/main.cf :
smtp_use_tls = yes
Vous pouvez FORCER l'utilisation de TLS, ainsi le client SMTP de Postfix ne délivrara aucun message sur une connexion non chiffrée. Dans ce mode, le nom de machine du serveur SMTP doit correspondre aux informations contenues dans le certificat du serveur et ce dernier doit être issu d'une autorité reconnue par le client SMTP de Postfix. Si l'une de ces condition n'est pas vérifiée, la livraison est retardée et le message reste en file d'attente.
Le nom de machine du serveur SMTP utilisé dans la vérification en question doit être le nom de machine principal (aucun CNAME n'est autorisé ici). Les comparaisons sont effectuées avec tous les noms fournis comme dNSNames dans le champ SubjectAlternativeName. Si aucun dNSNames n'est trouvé, le champ CommonName est utilisé. Ce comportement peut être modifié avec l'option smtp_tls_enforce_peername présentée ci-dessous.
Cette option n'est utilisable que ci vous ne vous connectez qu'à des serveurs supportant la RFC 2487 et qui présentent des certificats serveurs convenant aux deux conditions nécessaires. Un exemple pourrait être un client envoyant du courrier seulement à un commutateur de messagerie spécifique qui offre le nécessaire support STARTTLS.
Exemple :
/etc/postfix/main.cf :
smtp_enforce_tls = yes
Conformément à la RFC 2487, l'exigence de l'examen du nom de machine n'est pas requis pour les clients MTA. Lorsque TLS est requis (smtp_enforce_tls = yes), l'option smtp_tls_enforce_peername peut être mise à "no" pour désactiver l'examen strict du non de machine du serveur SMTP. Dans ce cas, les messages seront livrés sans regarder les champs CommonName, etc. listés dans le certificat.
En dépit du potentiel pour éliminer les attaques type "man-in-the-middle" ou autre, exiger une vérification des certificats suivant le nom n'est pas viable comme politique de livraison de courrier par défaut. Une part non négligeable des MTA supportant TLS disposent de certificats auto-signés ou de certificats issus d'une autorité privée. Sur une machine qui livre du courrier sur Internet, si vous indiquez smtp_enforce_tls = yes, vous devrez probablement ajouter smtp_tls_enforce_peername = no. Vous pouvez utiliser une politique TLS par site (voir ci-dessous) pour activer la vérification complète pour certaines destinations connues pour avoir des certificats valides.
Exemple :
/etc/postfix/main.cf :
smtp_enforce_tls = yes
smtp_tls_enforce_peername = yes
Une faible part des serveurs propose STARTTLS dans la réponse EHLO mais la négotiation échoue en raison de défauts de configuration, la livraison échoue alors à chaque tentative et le message reste en file d'attente puis retourne à son expéditeur à l'expiration du temps limite. Dans de tels cas, vous pouvez utiliser une politique par site pour désactiver TLS pour les sites à problème. Inversement, vous pouvez activer TLS seulement pour quelques sites et pas dans le cas général.
La table smtp_tls_per_site est consultée pour trouver une politique qui correspond aux informations suivantes.
- nom de machine du serveur SMTP distant
- C'est simplement le nom DNS du serveur auquel le client SMTP de Postfix se connecte ; ce nom peut être obtenu par d'autres consultation DNS telles les requêtes MX ou CNAME.
- destination suivante
- C'est normalement la partie domaine de l'adresse de destination, mais peut-être surchargée par les informations contenues dans la table transport(5), dans le paramètre relayhost, ou dans le paramètre relay_transport. Lorsque ce n'est pas le domaine du destinataire, la destination suivante peut prendre la forme spécifique à Postfix "[nom]", [nom]:port", "nom" or "nom:port".
Lorsque la consultation sur le nom de machine et sur la destination suivante réussissent, la politique correspondant au nom de machine ne prend pas automatiquement le pas sur l'autre. A la place, la préférence est donnée à la plus spécifique ou la plus sûre des politiques décrites ci-dessous.
La table smtp_tls_per_site utilise un simple format "nom espace valeur". Indiquez des noms de machine ou de destination sur la partie gauche - les cartes blanches ne sont pas autorisées. Sur la partie droite, indiquez l'un des mots-clefs suivants :
- NONE
- Ne pas utiliser TLS. Ceci surcharge un résultat de consultation moins spécifique MAY issu de la consultation avec l'autre clef (nom de machine ou destination suivante) et surcharge les paramètres globaux smtp_use_tls, smtp_enforce_tls, et smtp_tls_enforce_peername.
- MAY
- Tente d'utiliser TLS si le serveur en annonce le support, sinon utilise une connection en clair. Cette politique dispose d'une moindre préférence qu'un résultat plus précis (y compris NONE) issu de la consultation avec l'autre clef (nom de machine ou destination suivante) ou des cas ou la configuration globale contient "smtp_enforce_tls = yes" ou "smtp_tls_enforce_peername = yes".
- MUST_NOPEERMATCH
- Exige le chiffrement TLS, mais pas que le nom de machine du serveur SMTP distant ne corresponde aux informations contenues dans le certificat, ou que celui-ci soit issu d'une autorité agréée. Cette politique dispose d'une préférence plus élevée que la moins sécurisée NONE ou la moins spécifique MAY qui pourraient résulter de la consultation avec l'autre clef, et surcharge les paramètres globaux smtp_use_tls, smtp_enforce_tls et smtp_tls_enforce_peername.
- MUST
- Exige le chiffrement TLS, une correspondance entre le nom de machine du serveur SMTP distant et les informations contenues dans son certificat et la signature d'une autorité agréée. Cette politique dispose d'une préférence plus élevée que les moins sécurisées NONE et MUST_NOPEERMATCH ou la moins spécifique MAY qui pourraient résulter de la consultation avec l'autre clef, et surcharge les paramètres globaux smtp_use_tls, smtp_enforce_tls et smtp_tls_enforce_peername.
Les préférence entre les politiques TLS globales (main.cf) et spécifiques par site peuvent être résumées comme suit :
Lorsque ni le nom de machine du serveur SMTP distant ni la destination suivante ne sont trouvés dans la table smtp_tls_per_site, la politique basée sur smtp_use_tls, smtp_enforce_tls et smtp_tls_enforce_peername. Note : "smtp_enforce_tls = yes" et "smtp_tls_enforce_peername = yes" implique "smtp_use_tls = yes".
Lorsque à la fois le nom de machine du serveur SMTP distant et la destination suivante produisent un résultat, la politique par site la plus spécifique (NONE, MUST, etc.) surcharge la moins spécifique (MAY) et la plus sécurisée (MUST, etc.) surcharge la moins sécurisée (NONE).
Après que les politiques par site aient été combinées, le résultat surcharge généralement la politique globale. Une exception : une politique par site MAY est surchargée par la politique plus spécifique "smtp_enforce_tls = yes" avec une vérification du certificat serveur correspondant au paramètre smtp_tls_enforce_peername.
Tant qu'aucun mécanisme de consultation sécurisé du DNS n'existe, de faux noms de machines dans les réponses MX ou CNAME peuvent changer le nom de machine que Postfix utilise pour les recherches de politique de sécurité et la vérification de certificat. Même avec une correspondance parfaite entre le nom de machine du serveur et le certificat du serveur, il n'y a pas de garantie absolue que Postfix est connecté au bon serveur. Pour éviter ce trou de sécurité, procédez suivant les étapes suivantes :
Eliminez les consultations MX. Utilisez une table de transport(5) locale pour les domaines sensibles avec une destination explicite smtp:[mailhost] ou smtp:[mailhost]:port (vous garantirez mieux la sécurité de cette table que celle du DNS) ; dans la table smtp_tls_per_site utilisez la valeur MUST pour la clef [mailhost] ou smtp:[mailhost]:port. Ceci évite que des fausses informations sur les noms de machine dans les enregistrements MX du DNS ne changent le nom de machine que Postfix utilise pour les recherches de politique TLS et les vérifications des certificats.
Désactivez les surcharges de noms de machine par CNAME. Dans main.cf ajoutez "smtp_cname_overrides_servername = no". Ceci évite qu'une fausse information dans les enregistrements CNAME du DNS ne changent le nom de machine que Postfix utilise pour les recherches de politique TLS et les vérifications des certificats. Cette fonctionnalité est disponible dans les versions 2.2.9 et supérieures de Postfix.
Example:
/etc/postfix/main.cf:
smtp_tls_per_site = hash:/etc/postfix/tls_per_site
relayhost = [msa.exemple.net]:587
/etc/postfix/tls_per_site:
# relayhost correspondance exacte pour la destination suivante
[msa.example.net]:587 MUST
# TLS ne doit pas être utilisé avec les serveurs MX de exemple.org.
exemple.org NONE
# TLS ne doit pas être utilisé avec le serveur smtp.exemple.com.
smtp.exemple.com NONE
Si vous choisissez "par site" si oui ou non utiliser TLS, il peut être intéressant d'avoir une liste des sites qui offrent "STARTTLS". Nous pouvons les collecter avec cette option :
Si la fonctionnalité smtp_tls_note_starttls_offer est activée et qu'un serveur offre STARTTLS alors que TLS n'est pas activé pour ce serveur, le client SMTP de Postfix enregistre une ligne telle :
postfix/smtp[pid]: Host offered STARTTLS: [hostname.exemple.com]
Exemple :
/etc/postfix/main.cf :
smtp_tls_note_starttls_offer = yes
Lors de la vérification du certificat d'un serveur SMTP distant, une profondeur de vérification de 1 est suffisante si le certificat est directement issu d'une autorité indiquée dans smtp_tls_CAfile ou smtp_tls_CApath. La valeur par défaut de 5 doit suffire pour les chaînes plus longues (une autorité racine certifie une autorité particulière certifiant elle-même le certificat présenté...)
Exemple :
/etc/postfix/main.cf :
smtp_tls_scert_verifydepth = 5
Pour influencer le schéma de sélection du chiffrement du client SMTP de Postfix, vous pouvez indiquer une chaîne liste de chiffrement. Pour la description détaillée consultez la documentation OpenSSL. Si vous n'y connaissez rien, laissez simplement la valeur (openssl-)compilée par défaut !
N'UTILISEZ PAS de guillemets "" pour encadrer la chaîne, indiquez juste une chaîne !!!
Exemple :
/etc/postfix/main.cf :
smtp_tls_cipherlist = DEFAULT
Le paramètre smtp_starttls_timeout limite la durée des procédures d'établissement et de rupture de la session TLS. En cas de problèmes, le client SMTP de Postfix tente l'adresse suivante de la liste des échangeur de messagerie et retarde la livraison si aucun serveur alternatif n'est disponible.
Exemple :
/etc/postfix/main.cf :
smtp_starttls_timeout = 300s
La sécurité des logiciels de chiffrement tels TLS dépend fortement de leur capacité à générer des nombres aléatoires pour les clefs et quelques autres informations. A cette fin, le processus tlsmgr(8) maintient un groupe de générateurs de nombres pseudo-aléatoires (Pseudo Random Number Generator PRNG). Il est consulté par les processus smtp(8) et smtpd(8) à leur initialisation. Par défaut, ces démons demandent 32 octets à la fois, l'équivalent de 256 bits. C'est amplement suffisant pour générer des clefs de sessions 128 (ou 168) bits.
Exemple :
/etc/postfix/main.cf :
tls_daemon_random_bytes = 32
Pour alimenter son pool PRNG en mémoire, tlsmgr(8) lit l'entropie depuis une source extérieure au démarrage ainsi que pendant le fonctionnement. Indiquez une bonne source telle EGD ou /dev/urandom ; assurez-vous de n'utiliser que des sources non bloquantes. Si la source d'entropie n'est pas un fichier régulier, vous devez préficer le nom de la source avec son type : "dev:" pour un fichier device ou "egd:" pour une source disposant d'une interface socket compatible EGD.
Exemples (utilisez en un seul dans main.cf) :
/etc/postfix/main.cf :
tls_random_source = dev:/dev/urandom
tls_random_source = egd:/var/run/egd-pool
Par défaut, tlsmgr(8) lit 32 octets à la fois de la source d'entropie externe. Cette valeur (<=>256 bits) est largement suffisante pour générer des clefs symétriques de 128 bits. Avec des sources d'entropie EGD et dev:, tlsmgr(8) limite la quantité de données lue à la fois à 255 octets. Si vous utilisez un fichier régulier comme source d'entropie, une quantité supérieure peut être lue.
Exemple :
/etc/postfix/main.cf :
tls_random_bytes = 32
Pour mettre à jour son pool PRNG en mémoire, tlsmgr(8) interroge la source d'entropie externe après un délai aléatoire. Celui-ci est calculé en utilisant le PRNG, et est compris entre 0 et le temps maximum indiqué au paramètre tls_random_reseed_period. Le délai maximal par défaut est d'1 heure.
Exemple :
/etc/postfix/main.cf :
tls_random_reseed_period = 3600s
Le processus tlsmgr(8) sauvegarde l'état du PRNG dans un fichier d'échange persistant à intervalles réguliers et lorsque le processus se termine, ainsi il peut récupérer cet état au prochain démarrage. Ce fichier est créé lorsqu'il n'existe pas. Son emplacement par défaut se trouve dans le répertoire de configuration de Postfix, ce qui n'est pas le meilleur emplacement pour les informations modifiées par Postfix. À la place, ce fichier devrait probablement se trouver dans la partition /var (mais pas dans la cage chroot).
Exemples:
/etc/postfix/main.cf:
tls_random_exchange_name = /etc/postfix/prng_exch
tls_random_prng_update_period = 3600s
Les étapes suivantes vont vous permettre de démarrer rapidement. Comme vous signez votre propre certificat, vous obtiendrez le chiffrement TLS mais pas l'authentification TLS. C'est suffisant pour des tests et pour échanger des messages avec les sites avec lesquels vous n'avez pas de relation de certification. Pour obtenir une réelle authentification, le certificat de votre Postfix doit être signé par une autorité de certification reconnue et Postfix doit être configuré avec une liste des certificats des autorités agréées pour pouvoir vérifier les certificats présentés par les autres serveurs.
Dans les exemples ci-dessous, les commandes entrées par l'utilisateur sont affichéés en gras et un "#" indique un shell du super-utilisateur.
Devenez votre propre autorité de certification pour pouvoir signer votre propre clef publique. Cet exemple utilise le script CA.pl fournit avec OpenSSL. Par défaut, OpenSSL l'installe dans /usr/local/ssl/misc/CA.pl, mais celà peut varier. Ce script crée une clef privée ./demoCA/private/cakey.pem et une publique ./demoCA/cacert.pem.
% /usr/local/ssl/misc/CA.pl -newca CA certificate filename (or enter to create) Making CA certificate ... Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key ....................++++++ .....++++++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase:à-votre-choix
Créez une clef privée non protégée par mot-de-passe pour la machine FOO et un certificat non signé.
% openssl req -new -nodes -keyout FOO-key.pem -out FOO-req.pem -days 365 Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key ........................................++++++ ....++++++ writing new private key to 'FOO-key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Ile de France Locality Name (eg, city) []:Paris Organization Name (eg, company) [Internet Widgits Pty Ltd]:Porcupine Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:FOO Email Address []:wietse@porcupine.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:à-votre-choix An optional company name []:
Signez le certificat de la machine FOO avec la clef privée de l'autorité créée plus haut.
% openssl ca -out FOO-cert.pem -infiles FOO-req.pem Uing configuration from /etc/ssl/openssl.cnf Enter PEM pass phrase:whatever Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'FR' stateOrProvinceName :PRINTABLE:'Ile de France' localityName :PRINTABLE:'Paris' organizationName :PRINTABLE:'Porcupine' commonName :PRINTABLE:'FOO' emailAddress :IA5STRING:'wietse@porcupine.org' Certificate is to be certified until Nov 21 19:40:56 2005 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
Installez la clef privée du serveur, son certificat et celui de l'autorité de certification. Ceci requiert les privilèges du super-utilisateur.
# cp demoCA/cacert.pem FOO-key.pem FOO-cert.pem /etc/postfix # chmod 644 /etc/postfix/FOO-cert.pem /etc/postfix/cacert.pem # chmod 400 /etc/postfix/FOO-key.pem
Configurez Postfix, en ajoutant ce qui suit au fichier /etc/postfix/main.cf.
smtp_tls_CAfile = /etc/postfix/cacert.pem smtp_tls_cert_file = /etc/postfix/FOO-cert.pem smtp_tls_key_file = /etc/postfix/FOO-key.pem smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache smtp_use_tls = yes smtpd_tls_CAfile = /etc/postfix/cacert.pem smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem smtpd_tls_key_file = /etc/postfix/FOO-key.pem smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/var/run/smtpd_tls_session_cache smtpd_use_tls = yes tls_random_source = dev:/dev/urandom
Les problèmes doivent être rapportés de préférence via <postfix-users@postfix.org>. Voyez la page http://www.postfix.org/lists.html pour les informations de souscription. Lorsque vous rapportez un problème, soyez exhaustif. Les éventuels patches sont grandement appréciés.
Le support TLS de Postfix version 2.2 est basé sur le patch TLS de Lutz Jänicke, mais diffère quelque peu.
main.cf: utilisez "btree" au lieu de "sdbm" pour les bases de données utilisées pour le cache des sessions TLS.
Les bases de données gérant le cache des sessions TLS sont utilisées maintenant seulement par le processus tlsmgr(8), ainsi il n'y a plus de problèmes d'accès concurrents. Comme Postfix dispose d'un client sdbm, la librairie sdbm (près de 1000 lignes de code) n'est pas incluse dans Postfix.
Les caches de session TLS peuvent utiliser toutes les bases de données qui peuvent stocker des objets de plusieurs kilo octets et qui implémentent l'opération de séquence. Dans la plupart des cas, btree est adéquat.
NOTE : Vous ne pouvez pas utiliser de bases dbm. Les objets de session TLS sont trop grands.
master.cf: utilisez "unix" au lieu de "fifo" dans le type de service de tlsmgr.
Les processus smtp(8) et smtpd(8) utilisent maintenant un protocole client-serveur pour accéder au groupe de générateurs de nombres pseudo-aléatoires (PRNG) de tlsmgr(8), et pour accéder au cache des sessions TLS. Un tel protocole ne peut être utilisé dans des fifos.
smtp_tls_per_site: la politique par site MUST_NOPEERMATCH ne peut surcharger le paramètre global "smtp_tls_enforce_peername = yes".
smtp_tls_per_site: un résultat de consultation combiné (NONE + MAY) pour (nom de machine et destination suivante) produit un résultat non intuitif suivant les paramètres main.cf. TLS est activé avec "smtp_tls_enforce_peername = no", mais est désactivé lorsque "smtp_enforce_tls = yes" et "smtp_tls_enforce_peername = yes".
Les limitations de smtp_tls_per_site ont été supprimées à la fin du cycle de support de Postfix 2.2.
traduction par Xavier Guimard - Retour au menu