La sécurisation des flux SMTP avec StartTLS
Analyse heuristique
|
Anti-relais
|
Botnet / Zombie
|
Bounce
|
Dane
|
Déni de service - DDOS
|
DKIM
|
DMARC
|
DNSSEC
|
Faux-Négatifs
|
Faux-Positifs
|
Filtres Bayésiens
|
FOVI - Arnaque au président
|
FQDN
|
Greylisting
|
Ingénierie sociale
|
Listes Blanches
|
Listes noires DNSBl
|
Malware
|
MTA / MDA
|
Opt-in
|
Opt-out
|
Ransomware
|
Phishing
|
Sandbox
|
Scam / Nigerian419
|
SMTP
|
Spam
|
Spear Phishing
|
Spoofing
|
SRS
|
SPF
|
StartTLS
|
Teergrubing
|
Test de Turing
|
Virus
|
Définition de StartTLS
Traditionnellement, les communications sécurisées et non sécurisées se font sur des ports différents, c’est le cas notamment de la navigation Web (HTTP sur port 80 et HTTPS sur port 443). Cette architecture pose un certain nombre de problèmes (voir section 7 de la RFC 2595).
StartTLS (ou TLS opportuniste) permet, sur un port unique, l’élévation d’une connexion non-sécurisée en sécurisée : Lors d’un premier échange en clair, client et serveur communiquent sur leurs capacités respectives de chiffrement et s’accordent pour établir ce canal sécurisé, après quoi le reste de la communication est chiffrée. Si aucune méthode de chiffrement compatible n’est trouvée, la communication peut tout de même continuer, en clair. C’est donc une solution d’interopérabilité qui permet à un maximum d’équipements disparates de communiquer dans les meilleures conditions.
Le protocole a néanmoins ses limites et la première phase, non sécurisée, est susceptible d’être interceptée, voire modifiée. Des systèmes complémentaires, tel DANE, ont ainsi été mis en place afin de combler les failles de StartTLS.
Exemples
Voici la représentation d’une communication SMTP utilisant StartTLS entre un serveur émetteur « mail.envoi.fr » (en bleu ci-dessous) et un serveur destinataire « mail.dest.fr » (en vert):
1 → Établissement de la connexion de mail.envoi.fr vers mail.dest.fr sur TCP/25.
2 ← 220 mail.dest.fr ESMTP (le destinataire se présente)
3 → EHLO mail.envoi.fr (l’émetteur se présente)
4 ← 250-(…) 250-STARTTLS (le destinataire transmet ses paramètres, dont sa capacité StartTLS)
5 → STARTTLS (l’émetteur demande à utiliser StartTLS)
6 ← 220 Go ahead (le destinataire confirme la connexion TLS)
7 → Client Hello (l’émetteur initie la connexion sécurisée, le flux est maintenant chiffré)
8 ← Server Hello, Change Cipher Spec (le destinataire confirme et propose plusieurs algorithmes)
9 → Change Cipher Spec (l’émetteur sélectionne son algorithme préféré et valide le changement)
10 ← ACK (le destinataire confirme le changement)
11 → EHLO mail.envoi.fr (reprise de la communication SMTP maintenant chiffrée)
Dans cet exemple, les étapes 1 à 6 sont en clair. À l’étape 7, l’émetteur lance la communication chiffrée avec le protocole compatible à sa disposition, tel que défini lors de la phase 5. Selon la configuration, le client ou le serveur définit le meilleur algorithme à employer. La communication sécurisée reprend finalement à l’étape 11, les données seront échangées.
Applications :
StartTLS est dépendant du protocole utilisé. Comme nous l’avons vu dans l’exemple précédent, c’est lors de la communication SMTP qu’un paramètre est émis afin d’indiquer que StartTLS est disponible. Les protocoles ayant intégré StartTLS sont peu nombreux : IMAP, POP3, SMTP, XMPP et NNTP. À notre niveau, il est utilisé sur la communication SMTP dans tous les cas si le serveur de l’interlocuteur est compatible. Les serveurs Altospam sont configurés pour choisir l’algorithme de chiffrement utilisé (Cipher preference), le choix étant automatiquement fait sur l’algorithme de chiffrement le plus fort compatible.
L’email est le principal vecteur d’une cyberattaque
De nouvelles attaques de plus en plus sophistiquées sont lancées dans le monde tous les jours. Notre solution détecte et neutralise les menaces de phishing, spear-phishing, malware, ransomware et spam en temps réel.
Informations complémentaires :
– RFC2595 StartTLS pour IMAP et POP3
– RFC3207 StartTLS pour SMTP
– Tester StartTLS sur ses serveurs de messagerie
