Accueil / Articles PiApplications. / Sécurité informatique.

Courriels en réception.

Il existe plusieurs protocoles de transmission des messages électroniques. Il faut bien distinguer ici les "messages" de leur "transport".

Un message est un flux d'octets contigus qui respecte un standard de mise en forme défini par plusieurs RFC (Request For Comments). Pour faire simple disons qu'un message électronique est un "texte" constitué généralement de plusieurs parties, chaque pièce jointe formant par ailleurs une partie. Lorsque le message est transmis au format HTML, cela signifie simplement que le message intègre une partie qui n'est pas autre chose qu'une page HTML. Le plus souvent, un message HTML contient également une partie "texte". Ainsi, si le client de messagerie ne peut pas effectuer un affichage HTML, il présentera la partie "texte" et non la partie HTML (client de messagerie console par exemple). Les pièces jointes sont des fichiers binaires encodés sous forme de texte (representation textuelle de chaque octet qui compose le fichier). Grâce à cette représentation, le message, tant qu'il reste sous cette forme, ne présente quasiment aucun danger du point de vue viral ou sécurité. Cela ne signifie pas qu'il ne peut pas transporter un virus, mais que ce dernier pour être actif, impose la conversion du texte reçu vers le format binaire (ce que font automatiquement la plupart des clients de messagerie comme Outlook). En résumé, un message est un texte structuré d'une manière standardisée.

Pour transporter un message, ce dernier est encapsulé dans un flux compréhensible par la totalité des serveurs de messageries qui auront à le traiter. Cela est vrai pour l'émission comme pour la réception. Nous allons nous intéresser ici uniquement à la réception.

Principe de la réception de courriels.

Quel que soit l'émetteur du message, si votre adresse figure dans un des champs "vers" (To), "pour copie" (Bc) ou en "copie cachée" (Bcc), le serveur qui détient votre boîtes aux lettres finira par le recevoir. Une fois reçu, le message est stocké sous sa forme textuelle sans aucune interprétation.

Lorsque vous souhaitez savoir si vous avez des messages ("lus" ou "non lus"), votre client de messagerie s'adresse à ce serveur et lui demande s'il y a des messages disponibles. Si c'est le cas, il demandera que le serveur luis adresse les nouveaux messages qui apparaîtront comme "non lus" dans votre client de messagerie préféré.

Les demandes et les réponses constituent un dialogue sous forme de couples (requête, réponse). Les requêtes comme les réponses répondent à un standard de communication appelé "protocole". Il existe de nombreux protocoles de messagerie et nous allons nous intéresser ici aux deux plus répandus : POP3 et IMAP.

Quel que soit le protocole utilisé, les message émis vers une adresse de courriel sont stockés dans la boîte aux lettres identifiée par cette adresse courriel. Du point de vue du réseau, cette boîte aux lettres (adresse courriel) est unique. Une boîte aux lettres est constituée d'une arborescence "standard" de fichiers qui peut être éventuellement enrichie. Les messages sont placés dans un dossier de cette arborescence nommé "INBOX". C'est ce dossier qui est interrogé par le client de messagerie lorsque l'utilisateur souhaite savoir s'il a reçu de nouveaux messages.

Le protocole PO3.

Nous avons vu que pour interroger l'arborescence constituant une boîte aux lettres, le client doit émettre vers le serveur de messagerie des requêtes "normées". POP3 est un protocole qui défini ces requêtes et leur format. Ce protocole dérive du protocole POP dont il est la version 3. C'est l'un des protocoles les plus anciens. Il recense un ensemble de requêtes simples visant à décharger la boîte de l'utilisateur et donc à réduire l'espace disque consommé par le serveur. Idéalement, une commande de suppression du message est lancée par le client dès qu'il l'a réceptionné. Il est de la responsabilité du client de gérer ensuite les messages reçus car ces derniers ne sont plus dans la boîte aux lettres détenue par le serveur.

Certains client comme Outlook 2010 proposent de n'émettre la commande de suppression qu'au bout d'un certain délai (14 jours par défaut). Ce délai permet de rapatrier les derniers messages en cas de perte de la base locale des messages. POP3 est donc conçu dans un esprit "point-à-point" et fonctionne très bien lorsque vous utilisez un même client de messagerie pour réceptionner vos courriels.

Le protocole IMAP.

Le principe du "point-à-point" pose problème dès lors que vous utilisez plusieurs clients de messagerie pour une même boîte aux lettres. En effet, soit le client recevra des massages en double, soit il n'aura pas accès à des messages lus (et donc supprimés) par un autre client. C'est pour résoudre ce type de difficulté que le protocole IMAP a été mis au point.

La philosophie générale de ce protocole est ici différente : le serveur gère et conserve les messages à la manière d'une base de données dédiée aux messages. Les messages et leur statut sont partagés par l'ensemble des clients et seul un message explicitement supprimé ne sera plus accessible. Cette suppression se fait en deux temps : une suppression "logique" qui "marque" le fichier dans l'état supprimé mais le laisse accessible et une suppression physique qui supprime le message marqué "supprimé" à la demande ou au bout d'un laps de temps donné après sa réception. Ainsi, tant q'un message est simplement marqué "supprimé" par un client il demeure accessible aux autres clients. IMAP est donc conçu dans un esprit "multi-point" : une même adresse de messagerie doit pouvoir être consultée par plusieurs clients en donnant à chacun une même représentation du contenu de la boîte aux lettres.

POP3 et IMAP face à la sécurité.

Ces deux protocoles disposent d'une version chiffrable du transport (port 995 par exemple pour POP3/SSL et 993 pour IMAP/SSL). Il est donc possible de masquer le contenu des courriels pendant leur transport du serveur vers le client. De plus, IMAP est nettement moins "bavard" que POP3 dans la mesure où il n'est pas obligé de fournir le contenu d'un courriel au client pour en livrer les principales caractéristiques. On peut donc s'interroger sur la raison pour laquelle IMAP n'a pas définitivement remplacé POP3 dans l'usage courant ?

Une première réponse est technique car la simplicité de POP3 permet de l'utiliser aisément, voir de réaliser rapidement et à moindre frais des serveurs POP3 de distribution (pas de gestion de contention notamment). Toutefois, à cet argument s'oppose celui de la légèreté des communications via IMAP ce qui est un argument clef pour les clients de smartphone. La véritable réponse est donc ailleurs et est sans doute liée au niveau de sécurité intrinsèque de chacun de ces protocoles.

La plupart du temps, les messages ne font que transiter par le réseau jusqu'au serveur hébergeant votre boîte aux lettres. Leur risque d'interception est donc faible surtout en utilisant leur version chiffrée. Ce n'est donc pas non plus le mode de transport qui est déterminant.

Ce qui est important, c'est la capacité offerte à un tiers de lire le contenu de votre boîte aux lettres. Dans la mesure où vous n'avez pas la maîtrise du serveur de messagerie supportant votre boîte aux lettres, vous n'avez aucune garantie quant à la confidentialité de son contenu. Ainsi, n'importe quel administrateur indélicat du côté de l'hébergeur du serveur de messagerie peut consulter le contenu de vos courriels. C'est là que POP3 devient intéressant car il est possible d'imposer à la plupart des clients de messagerie de supprimer les messages immédiatement après leur transfert. Couplé à un délai de rafraîchissement court de vérification et de transfert des nouveaux courriels, cela laisse peu de temps pour exploiter le contenu de votre boîte aux lettres. Si la suppression automatique des messages par POP3 est un inconvénient lors du partage d'une même boîte aux lettres par plusieurs clients, c'est une force du point de vue de la sécurité. Comme toujours, l'augmentation de la sécurité se traduit par une baisse des capacités fonctionnelles. A vous de placer correctement le curseur en fonction des risques consentis...

(c) PiApplications 2016