La sécurité est désormais devenue une
préoccupation constante de tous les administrateurs réseau
et système. Elle concerne également les auteurs de
logiciels. Mais les concepteurs de protocoles
ne sont pas épargnés. L'IETF demande désormais
à tout protocole conçu pour un déploiement sur
l'Internet d'être impeccable, sur le plan de la
sécurité, d'avoir prévu les attaques possibles, et les parades à
utiliser. Pour éviter tout oubli, il est obligatoire, dans
tout RFC, d'avoir une section Security
considerations, qui contient l'analyse des questions de
sécurité du protocole normalisé par ce RFC. Que mettre dans cette
section ? C'est le but de ce que de l'expliquer.
Ce RFC est donc une lecture indispensable pour l'auteur de
RFC. Il porte toute l'autorité de l'IAB. Mais il est aussi un excellent tutoriel sur la sécurité sur
l'Internet, notamment par son exposé des différents types d'attaques,
et il est donc une lecture recommandée pour toute personne qui débute
sur ce sujet. Elle y apprendra le vocabulaire et les concepts de base
de la sécurité, qui font défaut à tant d'administrateurs aujourd'hui.
À quoi sert la section Sécurité des RFC, obligatoire depuis le (section 9) ? Comme le rappelle la section 1 de notre , cette section Sécurité sert à s'assurer que les auteurs
du protocole ont procédé à une analyse sérieuse de la sécurité de leur
œuvre, et à informer les lecteurs des résultats de ladite
analyse.
Bon, mais avant de prendre des mesures de sécurité, il faut mieux
définir ce qu'est la sécurité. En avant pour la section 2, qui
introduit la partie « tutoriel » du RFC. La sécurité est en fait un
ensemble de propriétés diverses. On peut identifier deux catégories,
la sécurité des communications et celles des systèmes qui communiquent.
La sécurité des communications est détaillée en section 2.1. Elle
se subdivise entre trois sous-catégories, la
confidentialité,
l'intégrité des données et
l'authentification du
partenaire. La confidentialité est le fait que vos secrets restent
secrets : personne ne doit pouvoir écouter vos
communications. L'intégrité des données est le fait qu'on reçoit bien
ce qui a été envoyé, aucun méchant n'a modifié ces données (un
objectif très difficile à atteindre dans le monde
numérique : contrairement au papier, les
changements ne laissent pas de trace). Et l'authentification est le
fait de s'assurer qu'on parle bien avec celui qu'on croit.
Ces trois propriétés sont liées : par exemple, sans
authentification, la confidentialité est difficile à assurer (si
Alice
sécurise ses communications contre l'écoute, mais n'authentifie pas,
qui sait si elle n'écrit pas à Ève en pensant écrire à Bob ? Auquel
cas, ses précautions ne serviraient à rien.)
Une autre propriété qui ne rentre pas dans cette classification est
la non-répudiation (section 2.2) qui est le
fait de pouvoir prouver que le message a bien été émis.
La sécurité des systèmes est en section 2.3. Elle comprend entre autres :
La protection contre l'usage non autorisé du système,La protection contre les usages inappropriés (les petites
lettres dans les contrats qui limitent ce que vous avez le droit de
faire),La protection contre les dénis de
service, les attaques qui visent à empêcher tout usage de
la machine.
Avec la section 3, on étudie cette fois les méchants, les
agresseurs. Elle est consacrée à la modélisation des menaces. L'idée
est qu'on ne peut pas se protéger contre tout (les meilleures
protections contre le déni de service, par exemple, ne serviront pas
si l'attaquant coupe
physiquement le câble). La modélisation des menaces la plus courante sur
l'Internet consiste à considérer que l'attaquant :
N'a pas pris le contrôle d'une des deux machines qui
communique (autrement, la défense devient quasi-impossible),Mais, en revanche, a un contrôle total du réseau qui les
relie. Il peut lire n'importe quel paquet, en modifier et en
fabriquer, y compris avec une adresse IP source
qui n'est pas la sienne.
Il existe aussi des modèles de menaces plus limités (section 3.1) par
exemple où l'attaquant est strictement passif : s'il peut lire
n'importe quel paquet, il n'a pas la possibilité d'en créer ou d'en
modifier. De telles attaques représentent une proportion non
négligeable, dans le monde réel. (En sécurité des réseaux, Ève est un
attaquant passif, Mallory un attaquant actif.)
La section 3.2 détaille donc ce que peut faire un attaquant
passif. Les attaques passives nécessitent d'être
quelque part sur le chemin entre les deux partenaires (section 3.5
pour cette notion d'« être sur le chemin »), par exemple
parce qu'on est sur le même réseau Wifi
(réseau partagé, voir aussi section 3.6) qu'une
des deux machines qui communiquent, ou bien parce qu'on contrôle un
routeur sur le chemin (beaucoup de routeurs
sont mal protégés). Dans ces conditions,
l'attaquant passif peut :
Écouter les communications,Capturer des mots de passe (par exemple avec l'excellent outil
dsniff),Faire, avec les données capturées, des attaques
hors-ligne, par exemple en cryptanalysant.
Passons aux attaques actives. La section 3.3 leur est consacrée. Un
attaquant actif peut fabriquer des paquets IP quelconques (en théorie,
les FAI ne devraient pas laisser passer les
paquets ayant une adresse IP source usurpée, mais le est bien peu déployé). Il ne peut pas toujours recevoir
la réponse (qui ira à celui dont il a usurpé l'adresse) mais certaines
attaques, dites aveugles, sont malgré tout
possibles dans ce cas.
Parmi les autres attaques possibles, il y a le rejeu (section
3.3.1) où l'attaquant réemet un paquet qu'il a déjà vu (sans même le
comprendre, par exemple si le message déclenche un retrait bancaire,
et que le protocole n'a pas de protection contre le rejeu, on voit ce
qu'il peut advenir), la modification de message (section 3.3.4) ou
l'homme du milieu où Janus, se plaçant entre
Alice et Bob, se fait passer pour Bob auprès d'Alice et pour Alice
auprès de Bob (et relaie les messages, pour qu'Alice et Bob ne
s'aperçoivent de rien).
Maintenant, arrivé à ce stade, on connait les agresseurs et leurs
capacités. Il existe évidemment de nombreuses défenses possibles mais
toutes ne sont pas bonnes, loin de là. La section 4 doit donc lister
des questions fréquentes, communes à beaucoup de protocoles. Par
exemple, pour l'authentification des
utilisateurs (section 4.1), notre RFC rappelle les forces et les
faiblesses des différents mécanismes, comme le traditionnel
mot de passe (désormais interdit dans les
protocoles IETF, sauf si le canal est protégé par la cryptographie, le
risque de sniffing étant
trop élevé autrement) ou les certificats (), qui
peuvent être également utilisés pour authentifier une machine.
En fait, concevoir un protocole sûr est une tâche tellement
complexe, avec tellement de possibilités d'erreur (et, en sécurité,
les erreurs ne se voient pas, avant qu'elles ne soient exploitées),
que la meilleure solution est souvent... de ne pas le faire, mais de
compter sur un cadre générique (section 4.2) comme
SASL () pour
l'authentification. En disant simplement « Pour l'authentification, on
utilise SASL », l'auteur de protocole prudent peut ainsi s'appuyer sur
un cadre solide et prouvé. Ceci dit, rien n'est jamais simple en
sécurité et le rappelle que ces cadres génériques
ont souvent une faiblesse, ils peuvent être victimes d'une attaque par
repli, où un attaquant actif va essayer de faire en sorte
qu'Alice et Bob n'utilisent pas la sécurité maximale, si d'autres sont
disponibles. Bien sûr, tout protocole de sécurité où les paramètres
sont négociables court ce risque mais il est plus élevé pour les
cadres génériques car ils encouragent le développeur du protocole à ne
pas trop réfléchir aux détails.
La section 4.4 rappelle la différence entre authentifier et autoriser (le
premier permet de vérifier une identité, le second de déterminer si
une entité donnée a le droit de faire telle action).
Comment fournir des communications sécurisées entre deux machines ?
Un protocole donné a deux solutions, fournir lui-même cette sécurité
ou bien s'appuyer sur un protocole de sécurité généraliste. Ainsi, le
DNS se protège contre les modifications en
transit par la signature des enregistrements
(DNSSEC, ), la
première solution, celle d'une sécurité fournie par le protocole. Par
contre, HTTP délègue en général sa sécurité à un
protocole générique, TLS ( et pour l'adaptation spécifique à HTTP), ce qui est la deuxième solution. La section 4.5 de
notre RFC discute ces deux solutions et donne des exemples.
Par exemple, le mécanisme le plus générique est IPsec (). Cette solution protège toute communication
IP. Mais IPsec est peu déployé, et en général sous forme de
VPN. Un inconvénient de la méthode VPN est
qu'elle est invisible aux applications, ce qui rend difficile pour
celles-ci de savoir si leurs communications sont protégées (et donc si
elles peuvent employer un mot de passe classique). Le RFC demande donc
que les auteurs de protocole ne tiennent pas pour acquise la
disponibilité d'IPsec (une violation de cette règle se trouve dans le
, qui a supprimé les possibilités
d'authentification qui existaient dans les précédentes versions
d'OSPF, pour imposer IPsec). Pourtant, le RFC
rappelle qu'IPsec est obligatoire pour IPv6 (ce qui est de la pure
réthorique, la plupart des implémentations d'IPv6 n'ont pas IPsec et,
même quand il est implémenté, son activation reste facultative... et
compliquée).
L'autre grand mécanisme générique de protection des communications
est TLS () qui
travaille, lui, juste en dessous de la couche
7. Il ne protège donc pas contre, par exemple, des paquets
TCP RST (ReSeT) faux. Notre
RFC note qu'il existe deux façons d'utiliser TLS, avec un port spécial
dédié (ce que fait HTTPS, avec son port 443) ou
bien avec un démarrage de TLS une fois la connexion établie. À part
HTTP, où le n'a eu aucun succès, cette seconde
méthode est la plus employée parmi les protocoles TCP/IP, sous le nom
de STARTTLS. Son avantage est qu'elle permet de
n'utiliser qu'un seul port et de négocier certains paramètres avant de
lancer TLS et donc de choisir le certificat en fonction de critères
comme le nom demandé (ce qui est utile en HTTP, autrement, avoir
plusieurs certificats sur une même machine est complexe, cf. section 4.5.2.1). Son
inconvénient principal est qu'elle peut ouvrir la voie à des attaques
par repli, où Mallory essaie de convaincre Alice et Bob que TLS n'est
pas possible, les amenant à ne pas sécuriser leur communication.
Les attaques par déni de service forment une
classe entière d'attaques, très difficiles à combattre. Très
fréquentes sur l'Internet aujourd'hui (un exemple est l'attaque contre les serveurs racine du
DNS en février 2007), elles n'ont pas de solution générale,
contrairement à la plupart des autres attaques où la
cryptographie résout tous les problèmes
techniques. La section 4.6 étudie cette menace et les approches
possibles. Certaines attaques par déni de service sont brutales et
sans subtilité, d'autres plus avancées comme les attaques SYN
flood contre TCP. Il est parfois possible de modifier
les protocoles pour les rendre moins vulnérables aux attaques
subtiles. Par contre, pour les attaques par force brute, les seules
protections restent le surdimensionnement des infrastructures (si
c'est économiquement raisonnable) et la réaction a posteriori.
Parmi les variétés de DoS, le RFC signale l'attaque aveugle (comme le
TCP SYN flood cité plus haut), où l'attaquant n'a
même pas besoin de pouvoir recevoir les réponses. Mais il y a aussi la
DoS distribuée où des dizaines ou
des centaines de milliers de machine
MS-Windows, devenues des zombies, coopèrent pour l'attaque.
Quant aux protections, elles reposent sur les principes suivants :
Faire en sorte que l'attaquant aie plus de travail que vous
(section 4.6.3.1) par exemple en demandant au client de résoudre des
puzzles cryptographiques comme le fait
HIP (). Cela ne protège pas
contre les attaques distribuées, où l'ennemi a une énorme puissance de
calcul à sa disposition.Obliger l'attaquant à montrer qu'il peut recevoir les réponses
par exemple en générant aléatoirement un petit
gâteau, un ensemble de bits que le partenaire va devoir
transmettre verbatim, prouvant ainsi
qu'il reçoit les réponses. Cela empêche les attaques aveugles et
valide ainsi l'adresse IP source de
l'attaquant. (Photuris,
utilise cette technique.)
Il y a une autre façon de voir les techniques de sécurité, c'est de
séparer celles qui protègent le message et celles
qui protègent le canal. Dans le premier cas, le
message est protégé de bout en bout, quels que soient les
intermédiaires. Dans le second, on ne protège qu'un échange entre deux
machines, mais des intermédiaires ont pu lire et/ou modifier le
message avant ou après le canal sécurisé. Par exemple, pour le
DNS,
DNSSEC fournit une protection de bout en bout,
il protège le message. Même si un des serveurs de noms secondaires du
domaine ou
un serveur de noms récursif est sous le contrôle d'un attaquant,
DNSSEC permettra de détecter une modification. Au contraire,
DNSCurve ne protège que le canal. Si
un serveur de noms récursif triche, DNSCurve ne protège pas (le point
n'est pas mentionné sur le site Web de DNSCurve, ce qui n'est pas
étonnant, l'honnêteté intellectuelle n'ayant jamais été le fort de
djb). Autre exemple, avec le
courrier électronique,
PGP () sécurise
le message (et il est donc protégé contre la lecture non autorisée ou
la modification, quels que soient le comportement des serveurs
intermédiaires) alors que SMTP +
TLS () ne protège qu'un canal
(alors que le courrier est relayé, stocké, etc). Le RFC note que la
distinction entre protection du message et protection du canal dépend
de la couche qu'on
regarde. Au niveau IP,
chaque paquet est un message et donc IPsec peut dire que, au
niveau 3, il sécurise le message alors que, au
niveau 7, les applications considèrent qu'IPsec
ne sécurise que le canal. Et il y a des cas encore plus compliqués
comme une page Web dont les différents composants ont été récupérés
par des canaux différents.
Enfin, après toutes ses considérations sur la sécurité des réseaux
en général et de l'Internet en particulier, on arrive avec la section
5 aux
prescriptions sur la section Security
considerations des futurs RFC. Que faut-il y mettre ? Les
auteurs doivent indiquer :
quelles attaques sont exclues par l'analyse de sécurité (et
pourquoi !)quelles attaques sont inclues dans l'analyse et, pour chacune,
si le protocole est protégé contre cette attaque ou pas.
Le RFC doit également inclure un modèle des menaces, s'appliquant à
l'Internet entier (pas uniquement à un réseau local déconnecté du
reste du monde). Un exemple que donne le RFC concerne
l'authentification traditionnelle Unix via le
mot de passe et les fichiers /etc/passwd et
/etc/shadow et un texte possible serait quelque
chose du genre « La sécurité du système repose sur la difficulté à
deviner le mot de passe et à écouter le réseau lorsque le mot de passe
circule. La divination du mot de passe est possible
hors-ligne avec des programmes comme Crack
(surtout si la longueur du mot est limitée à huit caractères) et
l'écoute est possible dès que le mot de passe est utilisé en clair,
par exemple par telnet. »
Enfin, la section 6 fournit des exemples de « bonnes » sections
Sécurité, tirées de RFC réels comme le (avec des
ajouts mis par le pour traiter des problèmes que le
avait négligé) ou comme le , là
encore avec quelques ajouts (le oubliait de dire
explicitement que la confidentialité n'était pas un but).