Comment fonctionne le courrier électronique?

Tout d'abord, vous utilisez un agent utilisateur de messagerie, ou MUA pour lire et envoyer des e-mails à partir de votre appareil (comme gmail ou l'application de messagerie sur les appareils Apple). Ces programmes ne sont actifs que lorsque vous les utilisez.

En général, ils communiquent avec un agent de transfert de courrier, ou MTA (également appelé serveur de messagerie, hôte MX et échangeur de courrier), qui sert à recevoir et à stocker vos e-mails.

Les e-mails sont stockés à distance jusqu'à ce que vous ouvriez votre MUA afin de vérifier vos e-mails. Les e-mails sont livrés par des agents de distribution de courrier (MDA), qui sont généralement fournis avec le MTA.

Auparavant, le courrier était envoyé à un serveur de messagerie via SMTP, ou Simple Mail Transfer Protocol. SMTP est un protocole de communication pour le courrier électronique.

Même maintenant, alors que de nombreux systèmes propriétaires tels que Microsoft Exchange et des programmes de messagerie Web comme Gmail utilisent leurs propres protocoles en interne, ils utilisent SMTP pour transférer des messages en dehors de leurs systèmes (par exemple, si un utilisateur de Gmail souhaite envoyer un e-mail à un client Outlook).

Le courrier serait ensuite téléchargé à partir du serveur à l'aide du protocole POP3 (Post Office Protocol) POP3 est un protocole de couche application qui permet d'accéder via un réseau de protocole Internet (IP) à une application utilisateur pour contacter une boîte aux lettres sur un serveur de messagerie. Il peut se connecter, récupérer des messages, les stocker sur l'ordinateur du client et les supprimer ou les conserver sur le serveur.

Il a été conçu pour pouvoir gérer les connexions Internet temporaires, telles que l'accès commuté (il se connecte et récupère simplement les e-mails une fois connecté, et vous permet d'afficher les messages lorsque vous êtes hors ligne). Cela était plus populaire lorsque l'accès commuté était plus répandu.

Désormais, IMAP, Internet Message Access Protocol, a principalement remplacé POP3. IMAP peut permettre à plusieurs clients de gérer la même boîte aux lettres (afin que vous puissiez lire votre courrier électronique à partir de votre ordinateur de bureau, de votre ordinateur portable et de votre téléphone, etc. et tous vos messages seront là, organisés de la même manière).

Finalement, le webmail a remplacé les deux. Webmail vous permet de vous connecter à un site Web et de recevoir des messages de n'importe où ou de n'importe quel appareil (yay!), Mais vous devez être connecté à Internet lorsque vous l'utilisez. Si le site Web (comme gmail) est votre MUA, vous n'avez pas besoin de connaître les paramètres du serveur SMTP ou IMAP.

Comment le courrier électronique est-il sécurisé?

Malheureusement, la sécurité n'était pas vraiment intégrée aux protocoles de messagerie depuis le début (comme la plupart des protocoles Internet débutants). Les serveurs s'attendaient simplement à prendre n'importe quel message de n'importe qui et à le transmettre à n'importe quel autre serveur qui pourrait aider à acheminer le message vers sa destination finale (le destinataire dans le champ to:).

Sans surprise, cela est devenu un problème lorsque l'Internet est passé de quelques groupes gouvernementaux et de recherche à quelque chose que la plupart des pays du monde utilisent pour faire essentiellement tout. Très vite, le spam et les e-mails de phishing sont devenus (et restent) un énorme problème pour tout le monde.

En réponse, nous avons collectivement essayé de mettre en œuvre plusieurs mesures qui empêchent les gens de lire les messages des autres (chiffrement) et de valider que les messages provenaient réellement du prétendu expéditeur (authentification).  

La plupart des endroits utilisent TLS (sécurité de la couche de transport, le remplacement de SSL, couche de sockets sécurisés), un protocole cryptographique qui fournit un cryptage en transit. Il fournit une protection lorsque le message est transmis, mais pas lorsque les données sont au repos (par exemple, en cours de stockage sur votre ordinateur).

Cela garantit qu'un message n'est pas modifié ou espionné pendant qu'il voyage d'un MTA à l'autre. Cependant, cela ne vérifie pas que le message n'a pas été modifié pendant le voyage.

Par exemple, si le courrier électronique passe par plusieurs serveurs de messagerie avant d'atteindre sa destination finale, l'utilisation de TLS garantira qu'il est crypté entre les serveurs, mais chaque serveur peut modifier le contenu du message. Pour y remédier, nous avons créé SPF, DKIM et DMARC.

SPF (Sender Policy Framework)

SPF permet au propriétaire d'un domaine (comme google.com) de définir un enregistrement TXT dans son DNS indiquant quels serveurs sont autorisés à envoyer des e-mails à partir de ce domaine (pour obtenir des instructions sur la manière de procéder pour divers fournisseurs d'hébergement, consultez ce site).

Comment cela marche-t-il?

Cet enregistrement répertorie les périphériques (généralement par IP) qui sont autorisés et peuvent se terminer par l'une des options suivantes:

-all = Si la vérification échoue (la source de l'e-mail n'est pas l'un des périphériques répertoriés), le résultat est un HardFail. La plupart des systèmes de messagerie marqueront ces messages comme spam.

? all = = Si la vérification échoue (la source de l'e-mail n'est pas l'un des appareils répertoriés), le résultat est neutre. Ceci est généralement utilisé pour les tests, pas pour les domaines de production.

~ all = Si la vérification échoue (la source de l'e-mail n'est pas l'un des appareils répertoriés), le résultat est un SoftFail. Cela signifie que ce message est suspect, mais n'est pas nécessairement un mauvais connu. Certains systèmes de messagerie marqueront ces messages comme spam, mais la plupart ne le feront pas.

Les en-têtes SPF peuvent être utiles aux serveurs eux-mêmes, car ils traitent les messages. Par exemple, si un serveur se trouve à la périphérie d'un réseau, il sait que les messages qu'il reçoit doivent provenir de serveurs dans l'enregistrement SPF de l'expéditeur. Cela aide les serveurs à se débarrasser plus rapidement du spam. Bien que cela semble bien, malheureusement, il y a quelques problèmes majeurs avec le SPF.

  1. SPF ne dit pas à un serveur de messagerie quoi faire avec le message - ce qui signifie qu'un message peut échouer à une vérification SPF et être toujours remis.
  2. Un enregistrement SPF ne regarde pas l'adresse «de» que l'utilisateur voit, il regarde le «chemin de retour». C'est fondamentalement l'équivalent de l'adresse de retour que vous écrivez sur une lettre. Il indique aux serveurs de messagerie qui gèrent la lettre où renvoyer le message (et il est stocké dans les en-têtes de courrier électronique - essentiellement les serveurs d'informations techniques utilisent pour traiter le courrier électronique).

    Cela signifie que je peux mettre tout ce que je veux dans l'adresse from: et cela n'aura aucun impact sur le contrôle SPF. En fait, ces deux adresses e-mail peuvent être relativement usurpées par un pirate informatique. Parce qu'il n'y a pas de cryptage impliqué, les en-têtes SPF ne peuvent pas être entièrement fiables.

  3. Les enregistrements SPF doivent être constamment mis à jour, ce qui peut être difficile dans les grandes organisations en constante évolution.
  4. La transmission interrompt le SPF. En effet, si un e-mail de, disons google.com, est transféré par [email protected], l'expéditeur de l'enveloppe reste inchangé (l'adresse d'expéditeur indique toujours google.com). Le serveur de messagerie de réception pense qu'il prétend provenir de google.com, mais provient de bobsburgers.com, il échoue donc à la vérification SPF (même si le courrier provient en fait de google.com).

Pour plus d'informations sur le SPF, consultez ces articles. Vous pouvez vérifier si un domaine spécifique a des enregistrements SPF et DMARC configurés ici.

DKIM (messagerie identifiée par DomainKeys)

DKIM est similaire au SPF. Il utilise également les enregistrements TXT dans le DNS du domaine d'envoi et fournit une certaine authentification du message lui-même. Il tente de vérifier que les messages n'ont pas été modifiés pendant le transit.

Comment cela marche-t-il?

Le domaine d'envoi génère une paire de clés publique / privée et place la clé publique dans l'enregistrement DNS TXT du domaine (si vous ne savez pas ce qu'est une paire de clés publique / privée, consultez cet article sur la cryptographie).

Ensuite, les serveurs de messagerie du domaine (à la limite extérieure - les serveurs qui envoient du courrier en dehors du domaine (par exemple de gmail.com à outlook.com)) utilisent la clé privée pour générer une signature de l'ensemble du corps du message, y compris en-têtes.

La génération d'une signature nécessite généralement que le texte soit haché et chiffré (pour plus de détails sur ce processus, consultez cet article).

Les serveurs de messagerie de réception utilisent la clé publique dans l'enregistrement DNS TXT pour décrypter la signature, puis hacher le message et les en-têtes pertinents (tous les en-têtes créés alors que le courrier se trouvait à l'intérieur de l'infrastructure de l'expéditeur - par exemple si plusieurs serveurs gmail ont traité le courrier avant a été envoyé en externe à outlook.com).

Le serveur vérifiera alors que les deux hachages correspondent. S'ils le font, le message est probablement inchangé (sauf si quelqu'un a compromis la clé privée de l'expéditeur) et légitimement de l'expéditeur présumé. Si les hachages ne correspondent pas, le message ne provient pas de l'expéditeur présumé, ou il a été modifié par un autre serveur en transit, ou les deux.

DKIM fait un très bon travail dans une tâche très spécifique - répondre à la question «cet e-mail a-t-il été modifié en transit ou non par l'expéditeur présumé? Cependant, c'est tout ce qu'il fait. Il ne vous dit pas comment traiter les e-mails qui échouent à ce test, quel serveur a peut-être modifié le message ou quelles modifications ont été apportées.  

DKIM est également utilisé par certains FAI ou fournisseurs d'accès Internet pour déterminer la réputation de votre domaine (envoyez-vous beaucoup de spam? Avez-vous un faible engagement? À quelle fréquence vos e-mails sont-ils renvoyés?).

Pour plus d'informations sur DKIM, consultez cet article. Vous pouvez valider un enregistrement DKIM ici.

DMARC (authentification, rapport et conformité des messages basés sur le domaine)

DMARC est essentiellement des instructions destinées aux serveurs de messagerie sur la façon de gérer les enregistrements SPF et DKIM. Il n'effectue aucun test lui-même, mais il indique aux serveurs de messagerie comment gérer les vérifications effectuées par SPF et DKIM.

Les FAI participants examineront les enregistrements DMARC publiés et les utiliseront pour déterminer comment gérer les échecs DKIM ou SPF. Ainsi, par exemple, une marque couramment usurpée peut publier un enregistrement DMARC indiquant que si DKIM ou SPF échouent, supprimez le message.

Souvent, les FAI vous enverront également des rapports sur l'activité de votre domaine avec la source de l'e-mail et s'il a réussi / échoué DKIM / SPF. Cela signifie que vous pourrez voir quand les gens usurpent (prétendent envoyer depuis) ​​votre domaine ou modifient vos messages.

Afin de mettre en œuvre DMARC, vous devez créer un enregistrement DMARC, en fonction de vos besoins (de la surveillance de votre trafic de courrier électronique pour déterminer quelles sont toutes vos sources de courrier électronique à demander des actions, comme le rejet de tout courrier électronique qui échoue DKIM ou SPF). Vous pouvez en savoir plus ici et ici.

Pour plus d'informations sur DMARC, consultez cet article. Vous pouvez vérifier si un domaine spécifique a des enregistrements SPF et DMARC configurés ici.

Emballer

Aucune de ces mesures de sécurité n'est parfaite, mais ensemble, elles font un travail décent en nous aidant à améliorer la sécurité des systèmes de messagerie dans le monde entier.

Plus il y aura d'organisations qui adopteront ces mesures (soit en utilisant des implémentations open source, soit en payant pour un produit), mieux tout le monde s'en portera. La sécurité ajoutée après le développement d'un protocole ou d'un produit est généralement plus coûteuse, moins efficace et plus difficile à mettre en œuvre que la sécurité intégrée au produit.

Cependant, la plupart des protocoles sur lesquels Internet actuel s'appuie ont été conçus pour le premier Internet - pour un petit groupe de passionnés, de scientifiques et de représentants du gouvernement - et non pour un réseau mondial sur lequel nous gérons des bâtiments, des appareils intelligents, des transports en commun, des centrales nucléaires. (!), etc.

Ainsi, à mesure qu'Internet continue de se développer, nous devons continuer à nous adapter et à développer de nouvelles façons de sécuriser les systèmes sur lesquels nous comptons.