Postfix/TLS - Introduction

Postfix/PLS est une extension du MTA Postfix dans le but de supporter le protocole TLS

Une note à propos du démarrage du projet

Quand j'ai commencé a écrire ce programme, j'avais en tête un un moyen sophistiqué pour autoriser le relayage de mes utilisateurs itinérants. En attendant ce projet vit de lui-même.

RFC2246 : le protocol TLS (anciennement SSL)

Par défaut toutes les communications sur internet sont faites sans cryptage et sans authentification forte. Cela signifie que toute personne avec un accès physique au chemin de communication qu'emprunte un paquet peut écouter vos communications. Pire, il est même possible de rediriger ou de modifier vos communications donc l'information que vous voulez envoyer à quelqu'un peut être perdue ou modifiée à votre insu.

Dans le but de résoudre ces problèmes de sécurité, le protocole SSL (Secure Socket Layers), présenté par Netscape inc., a maintenant évolué en protocole TLS (Transportation Layer Security) standardisé par la RFC2246. Cela permet à la fois le cryptage de la communication (arrêt des écoutes) et l'authentification forte (être sûr que les deux parties de la communication sont correctement identifiées et que la communication ne peut pas être altérée)

Postfix/TLS ne réalise pas le protocole TLS lui-même, il utilise plutôt le package OpenSSL pour cette tâche. Sur le site d'OpenSSL, vous trouverez aussi des liens vers une documentation plus approfondie sur le protocole et ses dispositifs, il n'est donc pas nécessaire de les inclure ici. (Et, bien sûr il n'y a aucune utilité de réécrire ce que d'autres ont déjà ecrits, cela présente juste l'intérêt de rajouter des erreurs)

 

RFC2487: Présentation de TLS a SMTP

L'intégration du protocole TLS au protocole SMTP (Simple Mail Transport Protocol) est décrit dans la RFC2487

À la différence des premières incarnations du SSL comme 'emballage' d'une communication normale [STUNNEL] [JONAMA], le protocole TLS est maintenant complétement intégré dans SMTP : pendant la négociation de départ (EHLO) le serveur offre le support de TLS avec la commande STARTTLS. Le client peut maintenant envoyer la commande STARTTLS pour permettre l'authentification et passer en mode crypté.

Postfix/TLS : Ce qu'il peut faire pour vous

La liste de fonctions présentée ici doit être comprise comme une liste d'idées. Toutes ne sont pas encore réalisées, regardez bien les notes pour chaque fonction.

Encryption de message d'une machine à une autre:
Etat: Fait
Commentaire: une fois que la negociation STARTTLS est réalisée, la communication entre les deux machines est cryptée. Ceci inclue aussi les enveloppes MAIL FROM: et RCPT TO:, les 'sniffeurs' ne seront pas capables d'avoir ces informations.

Authentification de l'hôte récepteur afin d'éviter une interception
Etat: Fait
Commentaire: Ceci est une fonction importante qui n'est pas difficile a implementer. Le problème est en fait que toutes les machines (en fait presque aucune) ne supportent pas ce protocole. L'expéditeur doit par conséquent mettre à jour une liste de récepteurs qui doivent s'identifier par TLS, sinon quelqu'un peut intercepter la session et ne pas prèsenter la commande STARTTLS, dans ce cas, aucune authentification n'est faite. On doit également faire attention à utiliser le nom correct du serveur (voir le CNAME), mais ce problème est le même pour des serveurs HTTP.

Authentification de l'hote émetteur afin d'éviter la contrefaçon
Etat: Fait
Commentaire: Ceci est l'idée à l'origine de ce projet, ce fut donc la première réalisation. Basé sur le certificat du client MTA (ou MUA) présenté au serveur, le relayage peut être ainsi autorisé.

D'autres idées:
Etat: envoyez moi un message

Postfix/TLS: ce qu'il ne peut pas faire pour vous

Voici un point sur lequel je veux insister:

Garantir l'intimité de votre correspondance
Etat: ne peut pas etre fait
Commentaire: La RFC2487 ne prend en compte uniquement le transport entre deux serveurs de courrier. Pour vous assurer que personne ne peut 'sniffer' votre correspondance il faudrait que:
- Tous les serveurs de courrier soient forcés en TLS
- Tous les serveurs eux-mêmes soient dignes de confiance, car l'email est seulement chiffré pendant le transport, pas en spool ni en queue.
- La destination soit digne de confiance, car le courrier est spoolé en clair et toute personne pouvant accéder à votre boite aux lettres (root par exemple) peut lire votre courrier!
Par conséquent, si vous voulez une intimité plus conséquente, vous devez envoyer votre email chiffré, par exemple en utilisant S/MIME ou le module traditionnel de PGP

Authentifier l'émetteur du message
Etat: ne peut être fait
Commentaire: Beaucoup de MUA envoient les messages juste en se connectant sur le port SMTP de l'hôte local ou du mailhub le plus proche. il n'y a aucun moyen de s'assurer que l'émetteur listé dans le message est bien l'émetteur réel. Et même si il était possible d'identifier l'émetteur, le contenu du message pourrait avoir été modifié entre temps.
Pour assurer l'identité de l'expéditeur et l'intégrité de l'email, vous pouvez encore employer S/MIME ou PGP.

D'autres packages Opensource:
Depuis la version 8.11 sendmail intègre le support de la RFC2487.
Frederik Vermeulen a réalisé une extension de la RFC2487 pour le MTA Qmail.
Matti Aarnio a intégré la RFC2487 dans ZMailer.
Michal Trojnara est actuellement en train d'intégrer un système basique d'authentification SMTP dans son logiciel stunnel depuis la version stunnel-3.3.
Trey Childs travaille sur une solution d'emballage.

Implémentations commerciales:

La version commerciale de sendmail supporte la RFC2487.
Netscape Enterprise Server et Microsoft exchange server supportent aussi la RFC 2487.
CommunigatePro mailserver software supporte aussi la RFC2487.