Postfix/TLS - Considérations de Sécurité

Les sections suivantes couvrent quelques considérations de sécurités (possibles) en ce qui concerne Postfix/TLS.

Clef privée du client/serveur
Postfix/TLS utilise l'authentification du côté serveur (obligatoire) et du côté client (facultatif). Afin de s'authentifier,
le processus défini (smptd/smtp) doit pouvoir accéder à la clef privée, qui doit cependant être maintenue secrète.
Car ces processus sont lancés à partir de 'master' sans possibilité d'interaction d'utilisateur, il n'est pas possible
de fournir un mot de passe, de sorte que la clef privée ne puisse pas être chiffrée.

La seule protection peut donc venu des droits d'accès de systéme de fichiers, qui devraient être placés
à 'root' et ' lisible pour le propriétaire seulement
-rw------- 1 root sys 887 Apr 29 1999 /etc/postfix/key.pem

Cette protection n'est valable que si votre système est protégé contre les failles de sécurités concernant root

Vous devez aussi vous rendre compte que des personnes ayant un accés physique à la machine peuvent voler
la clef privée si ils peuvent démarrer la machine en mode 'superutilisateur' (single-user) sans mot de passe
ou peuvent voler le disque et le monter sur un autre système où ils sont super-utilisateur. (Oui je sais qu'il existe
des systémes de fichiers encryptés mais ils n'ont pas encore une large diffusion)

Antémemoire de session sur le disque

Si vous utilisez l'antémemoire de session sur le disque (par défaut) des personnes capables mettre la main sur les fichiers
devraient pouvoir éviter les paramètres de transmission sécurisée. Cette situation n'est cependant pas plus grave que le cas
de la clef privée décrit ci-dessus, ainsi je ne considère aucun danger supplémentaire venant de l'enregistrement information
de session sur un peripherique de stockage

Casser le cryptage avec un système de clefs n'est qu'une affaire de temps (même si ce temps peut être très long), les sessions
ne devraient pas être utilisées indéfiniment. La valeur par défaut pour Postfix/TLS est 1 heure, la RFC 2246 recommande
de ne pas utiliser les sessions plus de 24 heures

Solutions pour le DNS
Un point faible dans l'authentification est l'utilisation du DNS pour découvrir le MX. Comme nous faisons du (E)SMTP
nous avons à utiliser les enregistrements MX.
Comme nous avons à authentifier le server découvert par le MX, quelqu'un est capable d'usurper un faux enregistrement MX
pour être capable de recevoir le mail, si son serveur peut présenter un certificat délivré par un CA acceptable. La dernière
partie n'est pas difficile si les certificat 'standarts' sont inclus (Verisign, Thawte,...)
Le seul moyen de se protéger contre ce problème est que, pour les destinataires pour lesquels nous voulons imposer le
chiffrement et l'authentification, la consultation de MX doit être ignorée avec une entrée appropriée dans la table /etc/postfix/transport

domaine.tres.important smtp:[server.du.domaine.important]