6. Examples (Exemples)

Cette section présente des exemples de sections Security Considerations, destinés à donner au lecteur une idée de ce qu'entend ce document.

Le premier exemple est un exemple « rétrospectif », appliquant les critères de ce document à un protocole largement déployé existant, SMTP. Le second exemple est une bonne section Security Considerations extraite d'un protocole actuel.

6.1. SMTP

Lorsque la RFC 821 a été rédigée, les sections Security Considerations n'étaient pas exigées dans les RFC, et aucune ne figure dans ce document. [RFC 2821] a mis à jour la RFC 821 et ajouté une section Security Considerations détaillée. Nous reproduisons ici la section Security Considerations de ce document (avec de nouveaux numéros de section). Nos commentaires sont en retrait et précédés de « NOTE: ». Nous ajoutons aussi plusieurs nouvelles sections pour couvrir des sujets que nous jugeons importants. Ces sections sont marquées [NEW] dans l'en-tête de section.

6.1.1. Security Considerations

6.1.1.1. Mail Security and Spoofing

Le courrier SMTP est intrinsèquement non sécurisé en ce sens qu'il est possible même pour des utilisateurs assez occasionnels de négocier directement avec les serveurs SMTP de réception et de relais et de créer des messages qui tromperont un destinataire naïf en lui faisant croire qu'ils proviennent d'ailleurs. Construire un tel message de sorte que le comportement « usurpé » ne puisse pas être détecté par un expert est un peu plus difficile, mais pas assez pour dissuader quelqu'un de déterminé et compétent. Par conséquent, à mesure que la connaissance du courrier Internet augmente, augmente aussi la conscience que le courrier SMTP ne peut intrinsèquement pas être authentifié ni soumis à des contrôles d'intégrité au niveau transport. La véritable sécurité du courrier réside uniquement dans des méthodes de bout en bout portant sur les corps des messages, telles que celles qui utilisent des signatures numériques (voir [14] et, par ex., PGP [4] ou S/MIME [31]).

NOTE: Une mauvaise approche de l'authentification de l'émetteur est [IDENT], dans laquelle le serveur de courrier récepteur contacte l'émetteur présumé et demande le nom d'utilisateur de l'émetteur. C'est une mauvaise idée pour de nombreuses raisons, y compris mais sans s'y limiter le relais, le détournement de connexion TCP et le simple mensonge du serveur d'origine. Outre le fait qu'IDENT a une faible valeur de sécurité, l'utilisation d'IDENT par les sites récepteurs peut entraîner des problèmes opérationnels. De nombreux sites émetteurs ignorent les requêtes IDENT, ce qui retient le courrier jusqu'à expiration du délai de la requête IDENT du serveur récepteur.

Diverses extensions de protocole et options de configuration qui fournissent l'authentification au niveau transport (par ex. d'un client SMTP vers un serveur SMTP) améliorent quelque peu la situation traditionnelle décrite ci-dessus. Cependant, sauf si elles sont accompagnées de transferts

prudents de responsabilité dans un environnement de confiance soigneusement conçu, elles restent intrinsèquement plus faibles que les mécanismes de bout en bout qui utilisent des messages signés numériquement plutôt que de dépendre de l'intégrité du système de transport.

Les efforts visant à rendre plus difficile pour les utilisateurs de fixer le chemin de retour d'enveloppe et l'en-tête « From » vers des adresses valides autres que les leurs sont en grande partie mal orientés : ils frustrent des applications légitimes dans lesquelles le courrier est envoyé par un utilisateur au nom d'un autre ou dans lesquelles les réponses d'erreur (ou normales) doivent être dirigées vers une adresse spéciale. (Les systèmes qui offrent des moyens pratiques pour que les utilisateurs modifient ces champs message par message devraient tenter d'établir une adresse de boîte aux lettres primaire et permanente pour l'utilisateur afin que les champs Sender dans les données du message puissent être générés de façon sensée.)

La présente spécification ne traite pas davantage des questions d'authentification liées à SMTP sinon pour préconiser que des fonctionnalités utiles ne soient pas désactivées dans l'espoir d'offrir une petite marge de protection contre un utilisateur ignorant qui tente de falsifier le courrier.

NOTE: Nous avons ajouté du matériel supplémentaire sur la sécurité des communications et SMTP à la section 6.1.2 Dans une spécification finale, le texte ci-dessus serait un peu édité pour refléter ce fait.

Des adresses qui n'apparaissent pas dans les en-têtes du message peuvent figurer dans les commandes RCPT vers un serveur SMTP pour plusieurs raisons. Les deux plus courantes concernent l'utilisation d'une adresse de liste comme « list exploder » (une seule adresse qui se résout en plusieurs adresses) et l'apparition de « copies aveugles ». Surtout lorsque plus d'une commande RCPT est présente, et afin d'éviter de détruire une partie du but de ces mécanismes, les clients et serveurs SMTP NE DEVRAIENT PAS copier l'ensemble complet des arguments de commande RCPT dans les en-têtes, que ce soit dans les en-têtes de traçage ou comme en-têtes d'information ou d'extension privée. Comme cette règle est souvent violée en pratique et ne peut être appliquée, les systèmes SMTP émetteurs conscients de l'usage « bcc » PEUVENT trouver utile d'envoyer chaque copie aveugle comme une transaction de message séparée ne contenant qu'une seule commande RCPT.

Il n'existe pas de relation inhérente entre les adresses « reverse » (des commandes MAIL, SAML, etc.) ou « forward » (RCPT) dans la transaction SMTP (« enveloppe ») et les adresses dans les en-têtes. Les systèmes récepteurs NE DEVRAIENT PAS tenter de déduire de telles relations et de les utiliser

pour modifier les en-têtes du message pour la livraison. L'en-tête populaire « Apparently-to » viole ce principe et est aussi une source fréquente de divulgation involontaire d'information et NE DEVRAIT PAS être utilisé.

6.1.1.3. VRFY, EXPN, and Security

Comme indiqué à la section 3.5, des sites individuels peuvent vouloir désactiver VRFY ou EXPN ou les deux pour des raisons de sécurité. En corollaire, les implémentations qui le permettent NE DOIVENT PAS donner l'impression d'avoir vérifié des adresses qui ne le sont pas en fait. Si un site désactive ces commandes pour des raisons de sécurité, le serveur SMTP DOIT renvoyer une réponse 252, plutôt qu'un code qui pourrait être confondu avec une vérification réussie ou échouée.

Renvoyer un code de réponse 250 avec l'adresse listée dans la commande VRFY après ne l'avoir vérifiée que syntaxiquement viole cette règle. Bien sûr, une implémentation qui « prend en charge » VRFY en renvoyant toujours 550 que l'adresse soit valide ou non n'est pas non plus conforme.

Ces dernières années, le contenu des listes de diffusion est devenu une source populaire d'informations d'adresse pour les soi-disant « spammeurs ». L'utilisation d'EXPN pour « récolter » des adresses a augmenté à mesure que les administrateurs de listes ont mis en place des protections contre les usages inappropriés des listes elles-mêmes. Les implémentations DEVRAIENT toujours fournir la prise en charge d'EXPN, mais les sites DEVRAIENT évaluer soigneusement les compromis. À mesure que des mécanismes d'authentification sont introduits dans SMTP, certains sites peuvent choisir de rendre EXPN disponible uniquement aux demandeurs authentifiés.

NOTE: Il n'est pas clair que la désactivation de VRFY apporte beaucoup de protection, car il est souvent possible de découvrir si une adresse est valide avec RCPT TO.

6.1.1.4. Information Disclosure in Announcements

Un débat permanent oppose les avantages de débogage qu'offre l'annonce du type et de la version du serveur (et parfois même du nom de domaine du serveur) dans la réponse de salutation ou en réponse à la commande HELP aux inconvénients d'exposer des informations qui pourraient servir dans une attaque hostile potentielle. L'utilité des informations de débogage ne fait pas de doute. Ceux qui plaident pour les rendre disponibles soulignent qu'il vaut bien mieux sécuriser réellement un serveur SMTP que d'espérer que masquer l'identité précise du serveur pour dissimuler des vulnérabilités connues apportera plus de protection. Les sites sont encouragés à évaluer le

compromis en gardant ce point à l'esprit ; les implémentations sont fortement encouragées à fournir au minimum un moyen de rendre le type et la version disponibles d'une façon ou d'une autre aux autres hôtes du réseau.

6.1.1.5. Information Disclosure in Trace Fields

Dans certaines circonstances, par exemple lorsque le courrier provient d'un LAN dont les hôtes ne sont pas directement sur l'Internet public, les champs de traçage (« Received ») produits conformément à cette spécification peuvent divulguer des noms d'hôte et des informations similaires qui ne seraient normalement pas disponibles. Cela ne pose en général pas de problème, mais les sites ayant des préoccupations particulières sur la divulgation de noms doivent en être conscients. De plus, la clause FOR optionnelle doit être fournie avec prudence ou pas du tout lorsque plusieurs destinataires sont impliqués, de peur de divulguer involontairement l'identité des destinataires en « copie aveugle » à d'autres.

6.1.1.6. Information Disclosure in Message Forwarding

Comme indiqué à la section 3.4, l'utilisation des codes de réponse 251 ou 551 pour identifier l'adresse de remplacement associée à une boîte aux lettres peut divulguer involontairement des informations sensibles. Les sites concernés par ces questions doivent veiller à sélectionner et configurer les serveurs de façon appropriée.

6.1.1.7. Scope of Operation of SMTP Servers

C'est un principe bien établi qu'un serveur SMTP peut refuser d'accepter le courrier pour toute raison opérationnelle ou technique qui a du sens pour le site fournissant le serveur. Cependant, la coopération entre sites et installations rend l'Internet possible. Si les sites abusent du droit de rejeter le trafic, l'ubiquité de la disponibilité du courrier électronique (l'une des forces de l'Internet) sera menacée ; une grande prudence et un équilibre doivent être maintenus si un site décide d'être sélectif sur le trafic qu'il acceptera et traitera.

Ces dernières années, l'utilisation de la fonction de relais via des sites arbitraires a servi dans des efforts hostiles pour masquer les origines réelles du courrier. Certains sites ont décidé de limiter l'usage de la fonction de relais aux sources connues ou identifiables, et les implémentations DEVRAIENT fournir la capacité d'effectuer ce type de filtrage. Lorsque le courrier est rejeté pour ces raisons ou d'autres raisons de politique, un code 550 DEVRAIT être utilisé en réponse à EHLO, MAIL ou RCPT selon le cas.

6.1.1.8. Inappropriate Usage

SMTP lui-même n'offre aucune protection contre le courrier électronique commercial de masse non sollicité (spam). Il est extrêmement difficile de dire a priori si un message donné est du spam ou non. Du point de vue du protocole, le spam est indiscernable des autres courriers — la distinction est presque entièrement sociale et souvent assez subtile. (Par exemple, un message d'un marchand chez qui vous avez déjà acheté faisant la publicité d'articles similaires est-il du spam ?) Les mécanismes de lutte contre le spam SMTP se limitent en général à identifier les expéditeurs de spam connus et à refuser de les servir ou à les cibler pour sanction/déconnexion. [RFC-2505] fournit de nombreuses indications pour rendre les serveurs SMTP résistants au spam. Nous donnons ici une brève discussion du sujet.

L'outil principal pour refuser de servir les spammeurs est la liste noire. Une autorité telle que [MAPS] collecte et publie une liste de spammeurs connus. Les serveurs SMTP individuels bloquent alors les contrevenants listés (généralement par adresse IP).

Pour éviter d'être mis sur liste noire ou autrement identifiés, les spammeurs tentent souvent d'obscurcir leur identité, soit simplement en envoyant une identité SMTP fausse, soit en faisant transiter leur courrier via un relais ouvert — un serveur SMTP qui effectue le relais de courrier pour tout expéditeur. En conséquence, il existe maintenant aussi des listes noires [ORBS] des relais ouverts.

6.1.1.8.1. Closed Relaying

Pour éviter d'être utilisés pour le relais de spam, de nombreux serveurs SMTP fonctionnent en relais fermés, ne fournissant le relais que pour les clients qu'ils peuvent identifier. De tels relais devraient en général insister pour que les expéditeurs annoncent une adresse d'envoi cohérente avec leur identité connue. Si le relais fournit un service pour un réseau identifiable (tel qu'un réseau d'entreprise ou d'un FAI), il suffit de bloquer toutes les autres adresses IP). Dans les autres cas, une authentification explicite doit être utilisée. Les deux choix standard pour cela sont TLS [STARTTLS] et SASL [SASLSMTP].

6.1.1.8.2. Endpoints

En pratique, les extrémités SMTP ne peuvent pas refuser le service aux expéditeurs non authentifiés. Comme la grande majorité des expéditeurs sont non authentifiés, cela briserait l'interopérabilité du courrier Internet. L'exception est lorsque le serveur d'extrémité ne devrait recevoir du courrier

que d'un autre serveur qui peut lui-même recevoir des messages non authentifiés. Par exemple, une entreprise peut exploiter une passerelle publique mais configurer ses serveurs internes pour ne parler qu'à la passerelle.

6.1.2. Communications security issues

SMTP lui-même ne fournit aucune sécurité des communications, et donc un grand nombre d'attaques sont possibles. Une attaque passive suffit pour récupérer le texte des messages transmis avec SMTP. Aucune authentification d'extrémité n'est fournie par le protocole. L'usurpation d'émetteur est triviale, et donc la falsification de messages de courrier est triviale. Certaines implémentations ajoutent des lignes d'en-tête avec des noms d'hôte dérivés par résolution inverse de nom (qui n'est sûre que dans la mesure où il est difficile d'usurper le DNS — pas beaucoup), bien que ces lignes d'en-tête ne soient en général pas affichées aux utilisateurs. L'usurpation du récepteur est aussi assez simple, soit par détournement de connexion TCP soit par usurpation DNS. De plus, comme les messages de courrier passent souvent par des passerelles SMTP, toutes les passerelles intermédiaires doivent être dignes de confiance, condition presque impossible sur l'Internet mondial.

Plusieurs approches sont disponibles pour atténuer ces menaces. Par ordre de niveau croissant dans la pile de protocoles, nous avons :

SMTP sur IPSEC
SMTP/TLS
S/MIME et PGP/MIME

6.1.2.1. SMTP over IPSEC

Une connexion SMTP exécutée sur IPSEC peut fournir la confidentialité du message entre l'émetteur et la première passerelle SMTP, ou entre toute paire de passerelles SMTP connectées. C'est-à-dire qu'elle fournit la sécurité de canal pour les connexions SMTP. Dans une situation où le message va directement du client à la passerelle du destinataire, cela peut fournir une sécurité substantielle (bien que le destinataire doive encore faire confiance à la passerelle). Une protection est fournie contre les attaques par rejeu, car les données elles-mêmes sont protégées et les paquets ne peuvent pas être rejoués.

L'identification des extrémités est un problème, cependant, sauf si l'adresse du récepteur peut être directement authentifiée cryptographiquement. L'identification de l'émetteur n'est en général pas disponible, car en général seule la machine de l'émetteur est authentifiée, pas l'émetteur lui-même. De plus, l'identité de l'émetteur apparaît simplement dans l'en-tête From du message, donc elle est facilement falsifiable par l'émetteur. Enfin, sauf si la politique de sécurité est fixée de façon extrêmement stricte, il existe aussi une attaque active de rétrogradation vers le clair.

Un autre problème d'IPsec comme solution de sécurité pour SMTP est l'absence d'une API IPsec standard. Pour tirer parti d'IPsec, les applications en général doivent pouvoir indiquer à l'implémentation IPsec leurs politiques de sécurité et découvrir quelle protection a été appliquée à leurs connexions. Sans API standard, il est très difficile de le faire de façon portable.

Les implémenteurs de serveurs SMTP ou les administrateurs SMTP NE DOIVENT PAS supposer qu'IPsec sera disponible sauf s'ils ont raison de croire qu'il le sera (comme l'existence d'une association préexistante entre deux machines). Cependant, il peut être raisonnable de tenter de créer une association IPsec de façon opportuniste vers un serveur pair lors de la livraison du courrier. Notez que dans les cas où IPsec sert à fournir un tunnel VPN entre deux sites, cela a une valeur de sécurité substantielle, en particulier dans la mesure où la confidentialité est fournie, sous réserve des mises en garde mentionnées ci-dessus. Voir aussi [USEIPSEC] pour des indications générales sur l'applicabilité d'IPsec.

6.1.2.2. SMTP/TLS

SMTP peut être combiné avec TLS comme décrit dans [STARTTLS]. Cela fournit une protection similaire à celle obtenue avec IPSEC. Comme les certificats TLS contiennent typiquement le nom d'hôte du serveur, l'authentification du destinataire peut être légèrement plus évidente, mais reste sensible aux attaques par usurpation DNS. Notamment, les implémentations courantes de TLS contiennent un mode exportable aux États-Unis (donc à faible sécurité). Les applications exigeant une haute sécurité doivent veiller à ce que ce mode soit désactivé. Une protection est fournie contre les attaques par rejeu, car les données elles-mêmes sont protégées et les paquets ne peuvent pas être rejoués. [Note: La section Security Considerations du document SMTP sur TLS est assez bonne et mérite d'être lue comme exemple de bonne pratique.]

6.1.2.3. S/MIME and PGP/MIME

S/MIME et PGP/MIME sont tous deux des protocoles de sécurité orientés message. Ils fournissent la sécurité d'objet pour des messages individuels. Avec divers réglages, l'authentification de l'émetteur et du destinataire et la confidentialité peuvent être fournies. Plus important encore, l'identification ne porte pas sur les machines d'envoi et de réception, mais sur l'émetteur et le destinataire eux-mêmes. (Ou du moins sur des clés cryptographiques correspondant à l'émetteur et au destinataire.) Par conséquent, une sécurité de bout en bout peut être obtenue. Notez toutefois qu'aucune protection n'est fournie contre les attaques par rejeu. Notez aussi que S/MIME et PGP/MIME fournissent en général des marques d'identification pour l'émetteur et le récepteur. Ainsi même lorsque la confidentialité est fournie, l'analyse de trafic reste possible.

6.1.3. Denial of Service

Aucune de ces mesures de sécurité ne fournit de protection réelle contre le déni de service. Les connexions SMTP peuvent facilement servir à saturer les ressources système de plusieurs façons, notamment consommation excessive de ports, utilisation disque excessive (le courrier est typiquement livré dans des fichiers disque) et consommation mémoire excessive (sendmail, par exemple, est assez volumineux et crée typiquement un nouveau processus pour chaque message.)

Si la sécurité de couche transport ou application est utilisée pour les connexions SMTP, il est possible de monter diverses attaques sur des connexions individuelles en utilisant des RST forgés ou d'autres formes d'injection de paquets.

6.2. VRRP

Le second exemple provient de VRRP, le Virtual Router Redundance Protocol ([VRRP]). Nous reproduisons ici la section Security Considerations de ce document (avec de nouveaux numéros de section). Nos commentaires sont en retrait et précédés de « NOTE: ».

6.2.1. Security Considerations

VRRP est conçu pour une gamme d'environnements d'interréseau pouvant employer différentes politiques de sécurité. Le protocole inclut plusieurs méthodes d'authentification allant de l'absence d'authentification, des mots de passe simples en clair, à une authentification forte utilisant IP Authentication avec MD5 HMAC. Les détails sur chaque approche, y compris les attaques possibles et les environnements recommandés, suivent.

Indépendamment de tout type d'authentification, VRRP inclut un mécanisme (TTL=255 à l'envoi, vérification à la réception) qui protège contre l'injection de paquets VRRP depuis un autre réseau distant. Cela limite la plupart des vulnérabilités aux attaques locales.

NOTE: Les mesures de sécurité discutées dans les sections suivantes ne fournissent que divers types d'authentification. Aucune confidentialité n'est fournie du tout. Cela devrait être explicitement décrit comme hors champ.

6.2.1.1. No Authentication

L'utilisation de ce type d'authentification signifie que les échanges de protocole VRRP ne sont pas authentifiés. Ce type d'authentification NE DEVRAIT être utilisé que dans des environnements où le risque de sécurité est minimal et la probabilité d'erreurs de configuration faible (par ex. deux routeurs VRRP sur un LAN).

6.2.1.2. Simple Text Password

L'utilisation de ce type d'authentification signifie que les échanges de protocole VRRP sont authentifiés par un mot de passe simple en clair.

Ce type d'authentification sert à protéger contre une mauvaise configuration accidentelle des routeurs sur un LAN. Il protège contre des routeurs qui sauvegardent par inadvertance un autre routeur. Un nouveau routeur doit d'abord être configuré avec le bon mot de passe avant de pouvoir exécuter VRRP avec un autre routeur. Ce type d'authentification ne protège pas contre des attaques hostiles où le mot de passe peut être appris par un nœud qui écoute les paquets VRRP sur le LAN. L'authentification Simple Text combinée à la vérification TTL rend difficile l'envoi d'un paquet VRRP depuis un autre LAN pour perturber le fonctionnement de VRRP.

Ce type d'authentification est RECOMMANDÉ lorsque le risque que des nœuds sur un LAN perturbent activement VRRP est minimal. Si ce type d'authentification est utilisé, l'utilisateur doit savoir que ce mot de passe en clair est envoyé fréquemment et ne doit donc pas être le même qu'un mot de passe ayant une importance sécuritaire.

NOTE: Cette section devrait être plus claire. L'essentiel est que l'absence d'authentification et Simple Text ne sont utiles que pour un modèle de menace très limité, à savoir qu'aucun des nœuds du LAN local n'est hostile. La vérification TTL empêche les nœuds hostiles hors-LAN de se faire passer pour des nœuds valides, mais rien n'empêche les nœuds hostiles sur le LAN d'usurper l'identité de nœuds autorisés. Ce n'est pas un modèle de menace particulièrement réaliste dans bien des situations. En particulier, il est extrêmement fragile : la compromission d'un nœud du LAN permet la reconfiguration des nœuds VRRP.

6.2.1.3. IP Authentication Header

L'utilisation de ce type d'authentification signifie que les échanges de protocole VRRP sont authentifiés au moyen des mécanismes définis par l'IP Authentication Header [AH] utilisant [HMAC]. Cela fournit une forte protection contre les erreurs de configuration, les attaques par rejeu et la corruption/modification de paquets.

Ce type d'authentification est RECOMMANDÉ lorsqu'il y a un contrôle limité sur l'administration des nœuds sur un LAN. Bien que ce type d'authentification protège le fonctionnement de VRRP, il existe d'autres types d'attaques qui peuvent être menées sur des liens à média partagé (par ex. génération de réponses ARP frauduleuses) qui sont indépendantes de VRRP et ne sont pas protégées.

NOTE : C'est une erreur que AH soit RECOMMANDÉ dans ce contexte. Comme AH est le seul mécanisme qui protège VRRP contre les attaques d'autres nœuds sur le même LAN, son emploi devrait être un DOIT (MUST) lorsqu'il existe des nœuds non dignes de confiance sur le même réseau. Dans tous les cas, AH devrait être obligatoire à implémenter (MUST implement).

NOTE: Il manque une analyse de sécurité importante seulement évoquée dans ce document, à savoir le compromis coût/bénéfice de l'authentification VRRP.

[Le reste de cette section est du matériel NOUVEAU] La menace que l'authentification VRRP vise à empêcher est un attaquant qui s'arrange pour être le maître VRRP. Cela se ferait en rejoignant le groupe (probablement plusieurs fois), en réduisant au silence le maître puis en s'élisant maître. Un tel nœud pourrait alors diriger le trafic de façons arbitrairement indésirables.

Cependant, il n'est pas nécessaire qu'un attaquant soit le maître VRRP pour cela. Un attaquant peut infliger des dommages similaires au réseau en forgeant des paquets ARP ou (sur des réseaux commutés) en trompant le commutateur. L'authentification VRRP n'offre aucune protection réelle contre ces attaques.

Malheureusement, l'authentification rend les réseaux VRRP très fragiles face aux erreurs de configuration. Imaginez ce qui se passe si deux nœuds sont configurés avec des mots de passe différents. Chacun rejettera les messages de l'autre et donc tous deux tenteront d'être maître. Cela crée une instabilité réseau substantielle.

Cet ensemble de compromis coût/bénéfice suggère que l'authentification VRRP est une mauvaise idée, car le bénéfice de sécurité marginal est faible mais le risque marginal est élevé. Ce jugement devrait être réexaminé si l'ensemble actuel de menaces non-VRRP est supprimé.