tbsLogo guillemet Adresse : 22 rue de Bretagne - 14000 CAEN - FRANCE
Tél. : 02 76 30 59 00 - E-mail : certs@tbs-internet.com
guillemet et filet Sunday, 24-Sep-2017 01:25:39 UTC Recherche arc gauche
arc droit langue FR
Les certificats
Le comparatif
Navigateurs
Notre gamme
Partenaires
Laboratoire
Sécurité Email
Outlook et S/MIME
Chiffrement S/MIME
Signature électronique S/MIME
S/MIME sous Unix
FAQ
Forums
The Satellite
Encyclopedia
Consulting
filet vert

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

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).

Serveurs SMTP
avec STARTTLS
Contrôle du relais
par certificats client
Authentification des serveurs
par certificat
Remarques
Exim 3.20 OUI OUI  
Infinite Interchange
V3.51
? ?  
Inframail Advantage
Server
NON OUI  
Innosoft PMDF/TSL
5.2-31
OUI ? OUI  
Merak NON NON  
Microsoft Exchange 2000 ? OUI  
Microsoft Exchange 5.5 SP3 ? NON  
Netscape Messaging Server
4.15
OUI ?  
Postfix OUI OUI Gratuit
Qmail OUI OUI Gratuit
Sendmail 8.11.0
et +
OUI OUI Gratuit
Software.com Intermail ? ?  
Stalker Communigate Pro 3.2
et +
NON NON  
ZMailer 2.99.51 et + NON NON Gratuit
Si vous pouvez contribuer au remplissage de ce tableau, merci d'envoyer un email à tag-ssl-email@TBS-internet.com.
Logiciel client avec STARTTLS Présentation certificat Remarques
Netscape Communicator >= 4.5 OUI  
Microsoft Outlook >= 5 NON  
Si vous pouvez contribuer au remplissage de ce tableau, merci d'envoyer un email à tag-ssl-email@TBS-internet.com.

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 :

Logiciel serveur
avec STARTTLS
POP IMAP Authentification par
certificat client
Remarques
Cyrus IMAP Server 1.6.19
et +
NON OUI NON  
Infinite Interchange
V3.51
OUI OUI ?  
Inframail Advantage Server OUI OUI NON  
Merak OUI OUI NON  
Netscape Messaging Server 4.1 NON OUI Seulement par IMAP  
Qpopper 4.0 OUI NON NON  
UW Imap 2000 OUI OUI NON Disponible pour quasiment
toutes les plateformes
(unix, windows, OS2, etc.)
avec Open SSL.
Logiciel client avec STARTTLS POP IMAP Remarques
ExpressIT! 2000 OUI OUI  

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 :

Logiciel serveur
avec tunnel TLS
POP IMAP Authentification par
certificat client
Remarques
Infinite Interchange
V3.51
OUI OUI ?  
Inframail Advantage Server OUI OUI NON  
Innosoft PMDF/TLS OUI OUI ?  
Inscribe Messaging Server OUI OUI ?  
Lotus Notes R5 OUI OUI OUI  
Microsoft Exchange 5.5 SP3 OUI OUI NON  
Mirapoint OUI OUI NON  
Netscape Messaging Server 4.1 NON ? OUI OUI seulement pour IMAP  
Software.com Intermail OUI OUI NON  
Stalker Communigate Pro 3.3 OUI OUI OUI  
Sun Internet Mail Server 4.0r5 OUI OUI NON  
UW Imap 2000 OUI OUI NON Disponible pour quasiment toutes les plateformes
(unix, windows, OS2, etc.)
avec OpenSSL.
Autres serveurs
(Postfix, Qmail, etc.)
stunnel stunnel NON Fonctionnalités POP, IMAP, LDAP
facilement ajoutable avec
stunnel,
voir ci-dessous. Gratuit.
Si vous pouvez contribuer au remplissage de ce tableau, merci d'envoyer un email à tag-ssl-email@TBS-internet.com

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 :

Logiciel client avec tunnel TLS POP IMAP Remarques
Fetchmail 5.1.3 et + OUI OUI  
KMail 1.3 et + OUI OUI Sous KDE 2.2
Lotus Notes client >= 5 OUI OUI  
Netscape Communicator >= 4.5 NON OUI  
Microsoft Outlook >= 5 OUI OUI Donner uniquement des FQDN dans la config
UW Pine 4.21 + ssl-patch NON OUI  
Si vous pouvez contribuer au remplissage de ce tableau, merci d'envoyer un email à tag-ssl-email@TBS-internet.com

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 !
freemail

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 internet

blanc
blanc [Webmaster] [Crédits] [Les certificats] [The Satellite Encyclopedia] [Pitux] [Consulting] [Accueil]
© TBS Internet, tous droits réservés. Toute reproduction, copie ou mirroring interdit.
Dernière modification: 22 November 2016