Gmail devient le premier fournisseur principal de messagerie à prendre en charge les rapports MTA-STS et TLS,
pour améliorer sa sécurité
Actuellement, quand deux relais de messagerie doivent échanger des mails, la sécurité du transport des messages est généralement assurée par un chiffrement des échanges en TLS. Cependant avec TLS, le serveur expéditeur ne peut pas indiquer sa politique de chiffrement et le serveur destinataire ne peut pas la vérifier. Quant aux certificats, ils peuvent être vulnérables : autorités de certifications (CA) multiples dont certaines ont été compromises, certificats falsifiés ou faibles, etc. Ce qui peut favoriser des attaques de type « Man in the Middle ».
DANE (DNS-Based Authentication of Named Entities) est standardisé par le RFC 7672 d’Octobre 2015. Il permet d’indiquer la politique de chiffrement d’un MX dans un enregistrement TLSA d’un DNSSEC. Pour se faire, on peut utiliser un certificat auto-signé ou validé par une autorité de certification connue. Enfin, l’enregistrement TLSA peut contenir le certificat complet ou un hash du certificat qui sera vérifié par le serveur destinataire. DANE permet ainsi une validation du certificat utilisé lors de la session TLS avec celui publié via DNSSEC.
MTA STS pour sa part est une solution de chiffrement qui a été proposée en octobre 2016 par les GAFA comme alternative à DANE. MTA-STS intervient au niveau d’un domaine et non d’un MX notamment quand l’implémentation de DNSSEC n’est pas possible ou non souhaitée.
Quel problème est résolu par MTA-STS ?
Traditionnellement, un gros problème de sécurité avec SMTP est que le chiffrement est entièrement facultatif. Lorsque la prise en charge de la mise à niveau du texte en clair au chiffrement sous la forme de la commande STARTTLS était ajoutée à SMTP (RFC 3207), la spécification précisait explicitement que les serveurs SMTP devaient accepter les connexions en texte en clair. Voici le texte pertinent :
Un serveur SMTP référencé publiquement NE DOIT PAS nécessiter l'utilisation de l'extension STARTTLS pour pouvoir livrer le courrier localement. Cette règle empêche l'extension STARTTLS de nuire à l'interopérabilité de l'infrastructure SMTP d'Internet.
SMTP MTA Strict Transport Security (MTA-STS) est donc un mécanisme permettant aux fournisseurs de services de courrier de déclarer leur capacité à recevoir des connexions SMTP sécurisées TLS (Transport Layer Security) et de spécifier si les serveurs SMTP d'envoi doivent refuser de livrer aux hôtes MX qui n'offrent pas TLS avec un certificat de serveur approuvé.
Hier, Gmail a annoncé le déploiement de MTA-STS :
« Nous sommes ravis d’annoncer que Gmail deviendra le premier fournisseur de messagerie électronique à suivre les nouvelles normes Internet SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 et SMTP TLS Reporting RFC 8460. Ces nouvelles normes de sécurité de la messagerie résultent de trois années de collaboration au sein de l'IETF, avec la contribution de Google et d'autres grands fournisseurs de messagerie ».
Utilisé seul, SMTP est vulnérable aux attaques de type Man-in-the-Middle
Comme tous les fournisseurs de messagerie, Gmail utilise le protocole SMTP (Simple Mail Transfer Protocol) pour envoyer et recevoir des messages électroniques. Google estime que SMTP seul ne fournit que la sécurité au mieux avec un cryptage opportuniste, et de nombreux serveurs SMTP n'empêchent pas certains types d'attaques malveillantes interceptant le trafic de courrier électronique en transit.
SMTP est donc vulnérable aux attaques de type homme au milieu, une attaque par laquelle la communication entre deux serveurs est interceptée et éventuellement modifiée sans détection. Les attaques réelles et la prévention ont été soulignées par Google dans sa recherche publiée en novembre 2015. MTA-STS aidera à prévenir ces types d'attaques.
MTA-STS utilise le chiffrement et l'authentification pour réduire les vulnérabilités
Une stratégie MTA-STS pour votre domaine signifie que vous demandez à des serveurs de messagerie externes d'envoyer des messages à votre domaine pour vérifier que la connexion SMTP est authentifiée avec un certificat public valide et chiffrée avec TLS 1.2 ou une version ultérieure. Cela peut être combiné avec les rapports TLS, ce qui signifie que votre domaine peut demander des rapports quotidiens à des serveurs de messagerie externes contenant des informations sur le succès ou l'échec des e-mails envoyés à votre domaine conformément à la stratégie MTA-STS.
Gmail commence à adhérer à MTA-STS et espère que d'autres suivront
Dans un billet, l’équipe de sécurité de Gmail a indiqué que : « Gmail, le premier fournisseur majeur à suivre la nouvelle norme, l’a lancé en version bêta le 10 avril 2019. Cela signifie que Gmail respectera les stratégies de création de rapports MTA-STS et TLS configurées lors de l'envoi d'e-mails aux domaines ayant défini ces stratégies. Nous espérons que de nombreux autres fournisseurs de messagerie adopteront bientôt ces nouvelles normes qui sécurisent davantage les communications par courrier électronique ».
Les administrateurs de domaine de messagerie doivent configurer des enregistrements DNS et un point de terminaison de serveur Web pour configurer les stratégies de création de rapports MTA-STS et TLS pour les courriers électroniques entrants. L’équipe responsable de Gmail recommande d’utiliser le centre d’aide de Gmail pour savoir comment configurer une stratégie MTA-STS avec votre serveur DNS. Les administrateurs de G Suite peuvent utiliser le blog Mises à jour de G Suite pour voir ce que MTA-STS signifie pour les domaines G Suite.
Source : blog Google, IETF, MTA-STS, RFC 3207
Partager