Ce que vous devez savoir sur l’utilisation de SSL/TLS pour chiffrer les connexions effectuées par vos serveurs de messagerie

Quand on m’a approché
avec le sujet de ce billet de blog, j’ai accepté avec joie. Voici une paraphrase
de la façon dont ça s’est passé:

« Pourriez-vous
écrire un billet sur l’importance de TLS dans les serveurs de messagerie ? » a demandé Patrick.

« Bien sûr », ai-je répondu.

Ouf, c’était une folle
conversation à revivre ! Comme un tourbillon !

Puis j’ai commencé à y réfléchir un peu. Existe-t-il vraiment des serveurs de messagerie qui n’utilisent pas le cryptage pour le transit ? Je ne parle pas du cryptage de bout en bout comme nous l’avons couvert dans le passé (S/MIME, PGP, etc). Je parle du cryptage de serveur à serveur ou de tout ce qui se trouve entre les deux pour protéger les données le long du parcours de traversée.

Certainement, à notre époque, personne ne laisserait son courrier entrant/sortant en clair traversant Dieu sait quelle route pour être intercepté et exploité. De nombreuses personnes utilisent des services de messagerie électronique et il est impossible qu’ils excluent le cryptage du transit de leur service. Les violations de données leur coûtent des millions en
poursuites judiciaires, en perte d’activité et en honte……Hmmmm…..

Je suis retourné vers Patrick
avec une question.

« Avons-nous des statistiques
ou des informations sur les serveurs de messagerie n’utilisant pas le cryptage ? A mon avis, ce serait
faible. En d’autres termes, qu’est-ce qui vous a poussé à me poser la question sur cet article ? « .

Patrick a répondu : « Je
ne le sais pas en fait. J’ai pensé que ce serait un bon sujet compte tenu de l’importance
du courrier électronique et de tous les aspects nécessaires à la sécurité. »

OK. C’est logique. Il y a probablement des serveurs de messagerie qui ne l’utilisent pas du tout, même si sans aucun doute un pourcentage beaucoup plus important peut utiliser des protocoles périmés ou des certs expirés et peut juste avoir besoin d’un rafraîchissement.

Cet article va passer
en revue où nous en sommes avec l’email et le cryptage de transit pour s’assurer que vous
opérez à un niveau de sécurité optimal qui est disponible.

Cryptage dans les serveurs de messagerie

À ce stade, nous avons probablement une compréhension générale de la façon dont TLS fonctionne, mais résumons au cas où vous êtes nouveau dans ce domaine.

Une personne A veut envoyer
une communication sécurisée à Human B. La personne A et Human B ont un certificat préétabli
. La personne A utilise le certificat pour chiffrer l’information et envoie
l’information chiffrée à l’humain B. L’information est illisible jusqu’à ce que l’humain
B utilise le certificat pour déchiffrer l’information chiffrée.

Si l’humain B veut
répondre à la personne A avec des informations cryptées, alors l’humain B utiliserait le
certificat pour crypter les données et la personne A utiliserait le certificat pour
décrypter le message.

C’est généralement ainsi que
le chiffrement/déchiffrement fonctionne. Maintenant, remplacez les personnes citées dans cet exemple par des
serveurs et autres connexions de ce type. Même concept.

Maintenant, si l’humain B veut répondre en retour à la personne A avec des informations cryptées, alors l’humain B utilise la clé symétrique qui vient d’être générée et ils peuvent maintenant à la fois crypter et envoyer, et recevoir et décrypter des données l’un vers l’autre.

C’est généralement ainsi que fonctionne le chiffrement/déchiffrement avec SSL/TLS. Maintenant, remplacez les personnes citées dans cet exemple par des serveurs et d’autres connexions de ce type. Même concept. C’est ainsi que TLS fonctionne avec le courrier électronique, ce qui est un peu différent de la façon dont il facilite une connexion HTTPS en raison du fait que le courrier électronique utilise des protocoles différents. Mais, il y a encore quelques similitudes distinctes :

• Une poignée de main se produit
• Une authentification se produit (bien que les deux parties s’authentifient dans ce contexte)
• Des clés de session sont utilisées pour transmettre le flux de courriels.

Ebb and (Mail) Flow

L’étape suivante de cet
article « comprendre pourquoi à » est la partie « comprendre comment ».

En bref, un client de messagerie envoie un courriel au serveur de sortie. Le serveur de sortie fera une recherche DNS, basée sur le domaine de courriel de destination, et l’enregistrement MX de ce DNS déterminera à quel serveur envoyer le courriel et, éventuellement, ce serveur déterminera s’il doit être transféré sur jusqu’à ce qu’il atteigne l’agent de livraison de courrier (MDA) de la boîte de réception de destination.

Il ne suffit pas de
faire confiance aux enregistrements MX du DNS, ce qui est une toute autre question de confiance, mais le serveur SMTP
(courrier sortant, MTA, etc) et le courrier entrant ( via POP3, IMAP,
Exchange) doivent pouvoir s’identifier mutuellement et disposer des bonnes clés pour
communiquer entre eux. Et, selon la route, il peut y avoir plus
que des communications de serveur de messagerie à un seul saut. Des échangeurs de mails, des serveurs proxy
et autres pourraient être en place le long de la route. Chaque saut (devrait) nécessiter un lien crypté. Souvent, c’est le cas. Parfois, ce n’est pas le cas. Les utilisateurs préféreraient que les informations sensibles soient cryptées en cours de route. Le cryptage de bout en bout
aide à assurer qu’il y a une sorte de cryptage tout au long du chemin, mais
les couches de sécurité sont toujours, euh, meilleures.

Respect Thy Securi-Tie

Pour mémoire,
Securi-Tie n’est pas un vrai mot. J’ai seulement inventé ce mot parce qu’il rimait. C’est
un jeu de mot sur le mot sécurité.

Pour faire une sorte de tremplin
à partir de la section précédente, nous devrions parler des options de sécurité qui, alors
qu’elles seraient définies du côté du client, fourniraient en fait des instructions
au côté du serveur de courrier à des fins de sécurité.

Lors de la configuration d’un
client de messagerie (Outlook, Thunderbird, etc), la configuration par défaut est une configuration
non chiffrée. Mais, comme c’est le but de cet article, nous voulons généralement opter
pour l’option chiffrée. En un sens, cela ne dépend pas entièrement du client : cela
dépend de ce que le côté serveur est capable de supporter. En supposant que vos serveurs entrants
et sortants puissent supporter le cryptage, pourquoi ne le feriez-vous pas ? Si vous commandez un
steak dans un restaurant et qu’ils vous proposent un faux-filet de choix ou un faux-filet Kobe(wagyu)
au même prix, pourquoi ne commanderiez-vous pas la coupe de meilleure qualité ?

Donc, si vous voulez utiliser
TLS/SSL sur votre courrier électronique (ceci est pour la partie transit et non la partie end-to-end,
S/MIME qui est abordée dans d’autres articles du blog), activez-la. Utilisez les ports 465
ou 587 pour SMTP (‘membre, courrier sortant) et 993 (IMAP) ou 995 (POP3) pour
le trafic entrant.

Il existe un
protocole de chiffrement intéressant qui est encore utilisé parmi les serveurs de messagerie. Il
a ses bons avec ses mauvais comme c’est le cas avec la plupart des choses. En fin de compte, je dirais que
ses intentions sont bonnes mais que l’application dans le monde réel n’est pas tout à fait idéale comme elle
pourrait l’être. Mesdames et Messieurs, ce protocole est STARTTLS.

STARTTLS est un protocole de sécurité
qui est fondamentalement SSL/TLS. Tout simplement, STARTTLS va prendre une
connexion en clair existante et, donc, non sécurisée, et tenter de la convertir
en une connexion sécurisée en utilisant TLS (ou SSL). Ainsi, le niveau de sécurité de
STARTTLS par rapport à SSL/TLS n’est en fait pas différent. Si tout est bien réglé, ils
vont tous deux chiffrer les informations en utilisant TLS (ou SSL).

La principale différence est
basée sur l’état d’une connexion et/ou l’initiation de la communication. STARTTLS
ne garantit pas une communication cryptée. Cela signifie essentiellement : « si la
connexion n’est pas chiffrée et que vous en êtes capable, transformez-la en une
connexion sécurisée ». Si le nœud de connexion (probablement un serveur) n’est pas en mesure de transformer la
connexion en une connexion cryptée, ce peut être à l’extrémité client de
décider comment la gérer à partir de là.

Bien que j’ai utilisé le terme
qualificatif de STARTTLS comme « utile », il pourrait être considéré comme moins sécurisé
que la sélection de SSL/TLS. Le choix standard de SSL/TLS est essentiellement « Utilisez
le cryptage ou foutez le camp ». STARTTLS dit, « Hum, si vous le pouvez, faites-le. Si
non, nous pouvons procéder en fonction d’autres instructions. »

Voici quelques déclarations concluantes

Souvent, l’évidence doit être énoncée et peut-être
exprimée. Alors voilà, ahem : Utilisez le cryptage. Surtout pour quelque chose qui
est si important, si crucial et intégré dans apparemment la grande majorité de
toute structure organisationnelle qui peut transporter des informations qui font ou défont. Il n’y a
pas beaucoup d’efforts à fournir. Utilisez à la fois le cryptage de bout en bout et en transit
. Deux valent mieux qu’un.

Si quelqu’un estime que l’effort supplémentaire pour configurer un serveur de courriel
pour qu’il soit crypté par rapport à un non crypté ne vaut pas la peine, alors cette personne n’en vaut
pas la peine. C’est tout simplement exagérer l’évidence. Le cryptage de bout en bout, tel que S/MIME, nécessite une approche plus complexe, mais cela en vaut la peine lorsque l’on ajoute des couches et des couches de sécurité. Mais, il n’y a aucune excuse pour ne pas prendre le temps de configurer et de maintenir
des liens sécurisés.

Lorsque la visibilité le permet, tout chemin de messagerie qui pourrait ne pas sembler sécurisé ou compromis devrait être tenu à l’œil. Et avec cela, soyez heureux dans votre examen minutieux pour un internet plus sûr. Santé !

*** Ceci est un blog du Security Bloggers Network syndiqué par Hashed Out by The SSL Store™ et rédigé par Ross Thomas. Lire l’article original à l’adresse suivante : https://www.thesslstore.com/blog/encryption-and-email-servers/