Sécurisation des courriers électroniques

La libéralisation de la cryptographie et son utilisation dans les protocoles courants changent la donne en matière de sécurité email. Ce document est plutot orienté vers les techniciens, néanmoins les utilisateurs finaux peuvent se rendre directement à la section 2, qui traite de la sécurité sur leurs logiciels de courrier électronique.

Pour apporter de la sécurité en matière de courrier électronique, on peut agir sur deux élements : les MTA et les MUA ou autrement dit coté serveur (TLS) et coté client (S/MIME). Il est vivement souhaitable que les administrateurs système commencent par la sécurisation coté serveur (ne plus transmettre de mots de passe en clair est primordial !). Ensuite on pourrra se concentrer sur la confidentialité et authentification des messages.

Plan du document :

• Sécurisation côté serveur
  - SMTP
  - POP3 et IMAP
  
  
• Sécurisation coté client
  - Logiciels utilisateurs
  - Modules de programmation
  
  
• En savoir plus - Liens

Sécurisation côté serveur

Sur le serveur il faut bien identifier les 2 types de flux à sécuriser. Le flux de transport de courrier, qui utilise le protocole SMTP et le flux de relève de boîte aux lettres qui utilise le plus souvent POP3 et IMAP.

- Serveur et SMTP

Le protocole SMTP dispose désormais d'une extension STARTTLS définie par la RFC 2487. Cette extension permet :

• l'authentification forte des serveurs SMTP (via un certificat),
  
  
• l'établissement d'une session TLS (chiffrée) entre 2 serveurs (MTA-MTA),
  
  
• l'authentification forte des clients SMTP (via un certificat),
  
  
• l'établissement d'une session TLS (chiffrée) entre le client et le serveur (UA-MTA),
  
  
  

L'authentification forte d'un serveur permet de garantir qu'on (que ce soit le client ou le serveur) remet bien le courrier au véritable serveur et non pas à un serveur qui détournerait le traffic (spoofing). Cette fonctionnalité est surtout interessante au sein d'un réseau d'entreprise utilisant internet. Elle permet a un réseau de serveurs tous équipés de certificats de s'authentifier entre eux. Exemple : une entreprise aux USA envoit du courrier à la filiale française. Le serveur US est configuré pour exiger la présentation d'un certificat du serveur français. Si ce certificat est bien présenté, alors le serveur US peut envoyer le courrier en toute confiance. Si subitement le serveur français ne présente plus le certificat, alors il y a un problème de sécurité.

L'intérêt évident de l'authentification forte par certificat est que sur cette base, l'établissement d'une sessions cryptée est possible (principe de SSL/TLS). Cela veut dire que grace à la présence d'un certificat sur le serveur, l'autre extrémité peut ouvrir une session TLS pour faire transiter toute la conversation SMTP chiffrée. L'autre extrémité peut aussi bien être un serveur (dans ce cas on a un transfert SMTP entre serveurs crypté) qu'un client (un logiciel de courrier électronique). Ils y a de nombreuses applications possible, par exemple le commercial itinérant qui veut envoyer du courrier électronique à son entreprise : en se connectant au serveur SMTP TLS de son entreprise, le contenu de la conversion SMTP est cryptée. L'ISP par lequel le commercial se connecte ne peut pas prendre connaissance du contenu des messages, ni même des destinataires (à la différence de S/MIME où seul le corps de l'email est crypté, pas les entêtes).

Enfin l'authentification forte des clients présente un grand intérêt pour régler les problèmes de relais. D'un mot le relais est le mécanisme qui consiste à accepter de transmettre un message a un destinataire quelconque ; ce mécanisme doit être controllé du fait de l'abus de cette fonctionnalité par les spammeurs ; voir la RFC 2505. La fonction de relais est donc par défaut interdite sur les serveurs SMTP mais doit pouvoir être selectivement autorisée pour les utilisateurs dûmment abilités du serveur (pas exemple, un fournisseur d'accès doit relayer pour ses clients mais pas pour tout le monde). Pour sélectivement autoriser le relais, il faut authentifier le client. Ceci peut se faire soit par le détournement d'un mécanisme existant (pop before smtp) ou en utilisant la fonction d'authentification de TLS ! Lors de la négociation TLS le client à la possibilité de présenter son certificat (sa carte d'identité) ce qui permet au serveur de lui attribuer le droit de relayer, si ce certificat correspond a un utilisateur autorisé. Cette fonctionnalité de SMTP TLS a un grand avenir.

Comme vous le voyez, SMTP TLS apporte des fonctionnalités essentielles qui sont rapidement implantées dans les serveurs. Voici la liste des serveurs qui implémentent (au moins partiellement) cette RFC (notez que Lotus Notes R5 utilise le port smtps et donc ne supporte pas cette RFC).

Nous ne pouvons pas donner d'instructions spécifiques pour l'installation des serveurs et/ou des patchs supportant TLS ; reportez vous à la documentation. Pour l'obtention du certificat indispensable à l'activation de TLS, adressez vous à Thawte (certificats de tests disponible gratuitement en ligne).

Pour tester votre serveur STARTTLS vous pouvez envoyer un email à tag-ping@TBS-internet.com qui renverra votre message. Notre ligne "Received" contiendra "with XXX encrypted SMTP" si votre message a été reçu en mode STARTTLS (XXX est l'algo de cryptage utilisé, le plus souvent DES-CBC3-SHA ou RC4-MD5). Si votre serveur laisse un trace dans son champ "Received", vous devriez aussi voir notre serveur parler à votre serveur en mode sécurisé. Voir aussi notre trace exemple.

Outre la sécurisation des sessions, il convient de vérifier que votre serveur SMTP est bien configuré pour ne pas relayer et respecte la RFC 2505 (qui est une "Best Current practice"). Si votre serveur ne respecte pas cette RFC, il est probablement listé comme tel dans la base ORBS (voir aussi notre liste des principaux serveurs de mail français en infraction). Un nombre croissant de serveurs SMTP refusent de recevoir du courrier de serveurs ne respectant pas la RFC 2505. Pour corriger ces problèmes, il existe l'excellent guide d'ORBS.

- Serveur et POP3/IMAP

Les protocoles POP3 et IMAP sont très largement utilisés pour relever ou consulter les boîtes aux lettres. Le problème c'est que ces protocoles transmettent l'authentification username/password en clair (sauf cas particuliers).

La RFC 2595 répond à ce problème en introduisant l'extension STARTTLS (STLS est son nom pour POP3). Tout comme pour SMTP, cette commande permet de passer en mode TLS une fois la connexion établie. Elle permet également, comme pour SMTP, d'authentifier de façon forte le client et de remplacer le couple username/password par un certificat client.

Les produits implémentant la RFC 2595 encore peu nombreux :

En attendant le support de la RFC 2595, il a été défini des ports spécifiques, qui permettent d'encapsuler un protocole dans un tunnel TLS tout comme https pour http. Voici pour références les ports les plus connus :

smtps           465/tcp        # smtp protocol over TLS/SSL
nntps           563/tcp        # nntp protocol over TLS/SSL
ldaps           636/tcp        # ldap protocol over TLS/SSL
telnets         992/tcp        # telnet protocol over TLS/SSL
imaps           993/tcp        # imap4 protocol over TLS/SSL
ircs            994/tcp        # irc protocol over TLS/SSL
pop3s           995/tcp        # POP3 protocol over TLS/SSL
ftps-data       989/tcp        # ftp protocol, data, over TLS/SSL
ftps            990/tcp        # ftp protocol, control, over TLS/SSL

Certains logiciels serveurs supportent nativement ces ports. Ils sont listés ci-dessous :

Pour les serveurs non nativement équipés, on peut très simplement effectuer cette encapsulation avec un logiciel de tunnel qui établit une session TLS et transmet le flux au véritable serveur. Le logiciel le plus connu pour ce faire est stunnel; il existe aussi Jonama (voir références en bas de page). Stunnel permet en mode TLS d'obtenir une sécurité 128-bit.

Pour mettre en place le port pop3s par exemple, il vous faut installer OpenSSL, installer stunnel, obtenir un certificat SSL serveur auprès de Thawte (certificats de tests disponible gratuitement en ligne), et lancer stunnel au boot avec :

/usr/local/sbin/stunnel -p clefpriveeetcertificat.pem -d pop3s -r pop

Idem pour IMAP. Vous pouvez utiliser le même certificat pour POP et IMAP et ApacheSSL si ces 3 services sont sur la même machine !

Voici les logiciels qui supportent nativement les connexions vers ces ports spécifiques :

Si votre logiciel client ne supporte par SSL/TLS en natif, vous pouvez contourner le problème en mettant un stunnel sur votre machine, configuré pour communiquer avec serveur sur le port sécurisé ! Exemple sous unix :

/usr/local/sbin/stunnel -c -d 110 -r pop3.provider.fr:995

Rassurez-vous stunnel existe aussi sous Windows (voir liens en bas de page), et donc vous pouvez faire :

stunnel -c -d 110 -r pop3.provider.fr:995

Vous configurer alors votre logiciel favori pour se connecter sur localhost et le tour est joué !

Besoin d'un nouveau serveur de mail incorporant tout ceci ?
Vous n'avez pas le temps de chercher ni de le mettre en service ?
Fort de notre expérience nous vous proposons notre solution !

Sécurisation côté client

La sécurité coté clients repose sur l'usage du protocole S/MIME. Ce protocole permet de signer et de chiffrer le contenu des courriers électroniques (avec attachements). L'intégration de S/MIME dans les produits grand public rend l'utilisation particulièrement simple.

- Logiciels utilisateurs

Nous avons rassemblé toutes les informations nécessaires à l'utilisation de S/MIME dans les 2 manuels ci-dessous. Ils ont été testé par des utilisateurs sans connaissances particulières avec succès. Nous pensons que tous peuvent désormais accéder à ces technologies avec un minimum de patience et un respect rigoureux des instructions. Bonne lecture !

• Netscape Communicator
• Microsoft Outlook

L'obtention de certificats S/MIME peut se faire dans le cadre gratuit de l'offre Freemail de Thawte.

La gamme Thawte supporte un grand nombre de logiciels S/MIME ; en plus des produits Microsoft et Netscape Thawte supporte Lotus Notes R5, WorldSecure, etc.

- Modules de programmation

Outre les logiciels utilisateurs bien connus, il ne faut pas oublier les applicatifs. Nombre d'applications (progiciels) ont besoin de pouvoir envoyer des emails, notemment les applications sur les serveurs qui utilisent l'email pour l'interface client. Exemple : un serveur de prise de commande en ligne qui les envoit par email aux commerçants concernés !

Nous y avons pensé et nous proposons un toolkit en perl qui permet d'envoyer des emails chiffrés avec S/MIME depuis un serveur. Voyez notre démonstration et documentation.

En savoir plus

Vous avez des questions spécifiques ?
Comment déployer ces technologies dans votre entreprise ?
Nous pouvons intervenir chez vous en consultant sur ces sujets.

Contactez-nous !

1. TLS est définie dans la RFC 2246
2. Implémentation open source de TLS : OpenSSL
3. Groupe de travail sur les applications courrier électronique TLS: http://www.imc.org/ietf-apps-tls/
4. Liste de diffusion en français sur la cryptographie X509: https://www.tbs-internet.com/ssl/liste.html
5. stunnel : http://mike.daewoo.com.pl/computer/stunnel/
6. stunnel.org : http://www.stunnel.org/
7. stunnel miroir : http://opensores.thebunker.net/pub/mirrors/stunnel/
8. stunnel pour Windows : http://security.fi.infn.it/tools/stunnel/index-en.html
9. sslwrap, un concurrent de stunnel : http://www.rickk.com/sslwrap/
10. Jonama, un autre concurrent : http://www.multimania.com/jonama/
11. ZMailer : http://www.zmailer.org/
12. Microsoft Exchange : http://www.microsoft.com/exchange/
13. SSL pour MS Exchange : http://support.microsoft.com/support/kb/articles/Q175/4/39.ASP
14. SMTP SSL encryption pour MS Exchange :
    http://www.microsoft.com/exchange/en/55/help/documents/server/xog05016.htm
15. STARTTLS bug for MS Exchange : http://support.microsoft.com/support/kb/articles/Q237/3/27.ASP
16. Stalker CommuniGate Pro : http://www.stalker.com/CommuniGatePro/
17. Netscape Messaging Server : http://www.iplanet.com/products/infrastructure/messaging/n_mess/index.html
18. software.com Intermail (pas post.office) : http://www.software.com/products/imoverview.html
19. Lotus Notes R5 : http://www.lotus.com/home.nsf/welcome/notes
20. Innosoft PMDF-TLS : http://www.innosoft.com/doc/pmdf/v52-tls.html
21. ORBS : http://www.orbs.org/
22. Thawte France : https://www.tbs-internet.com/thawte/
23. Sun Internet Mail Server (SIMS) : http://www.sun.com/sims/
24. SIMS SMTP TLS 4.0 rev 5 :
    http://docs.iplanet.com/docs/manuals/messaging/sims40/ProductUpdate.fm.html#11203
25. Mirapoint : http://www.mirapoint.com/
26. Postfix TLS : https://www.tbs-internet.com/ssl/postfix-tls.html
27. Qmail TLS : https://www.tbs-internet.com/ssl/qmail-tls.html
28. Sendmail TLS : https://www.tbs-internet.com/ssl/sendmail-tls.html
29. Racines d'autorités de confiance pour configuration de Qmail, Postfix et Sendmail :
    https://www.tbs-internet.com/secure/ca/tbs-trusted-roots.tgz
30. Sendmail commercial Secure Switch : http://www2.sendmail.com/products/routing/secureswitch/
31. Infinite InterChange : http://www.Infinitemail.com/infinite/prods/ichange/ichange.html
32. Inframail Advantage Server : http://www.infradig.com/infradig/inframail/index.shtml
33. Inscribe Messaging Server : http://www.cp.net/products/inscr_messagingserv_overview.html
34. Cyrus Imap Server : http://asg.web.cmu.edu/cyrus/download/imapd/
35. UW Imap 2000 : http://www.washington.edu/imap/
36. UW Pine : http://www.washington.edu/pine/
37. Fetchmail : http://www.tuxedo.org/~esr/fetchmail/
38. Exim : http://www.exim.org/
39. Exim TLS doc : http://www.exim.org/exim-html-3.20/doc/html/spec_38.html
40. Qpopper : http://www.eudora.com/qpopper/
41. Merak : http://www.icewarp.com/merakmail/index.html
42. Sécurisation d'Internet Explorer et d'Outlook Express

Feedback

Un commentaire sur cet article ? Votre avis nous intéresse. Ecrivez à tag-ssl-feedback@TBS-internet.com

TBS est une société de conseil spécialisée dans les télécommunications spatiales, le conseil aux ISPs et la sécurité du commerce électronique. TBS-internet est courtier en certificats depuis 1996.

Sécurisation Outlook Express | Sécurisation Netscape Communicator | Sécurisation serveurs SMTP/POP/IMAP |
Autres documents sécurité TBS CERTIFICATS