La fin annoncée des autorités de certification ? Alternatives: TOFU

La fin annoncée des autorités de certification ?
Alternatives: TOFU, Convergence, CATA, Clés souveraines, DANE
Florian Maury
29 décembre 2011
Mots-clés :
– Infrastructure de Gestion de Clés (IGC)/Public Key Infrastructure (PKI) ;
– Autorités de certification ;
– Transport Layer Security (TLS) ;
– Public Key Infrastructure X.509 (PKIX) ;
– X.509 ;
– Convergence ;
– TOFU ;
– CATA ;
– Clés souveraines ;
– DNS-based Authentication of Named Entities (DANE).
Table des matières
1 Introduction
3
2 PKIX
3
3 TOFU : Trust On First Use
5
4 Convergence
5
5 CATA : Certificate Authority Transparency and Auditability
7
6 Les clés souveraines
7
7 DANE : DNS-based Authentication of Named
7.1 Fonctionnement de DANE . . . . . . . . . . . .
7.2 Fonctionnement de DNSSEC . . . . . . . . . .
7.2.1 Coté serveur DNS . . . . . . . . . . . .
7.2.2 Coté client DNS . . . . . . . . . . . . .
7.3 Les problèmes de sécurité de DNSSEC . . . . .
7.3.1 Les attaques par rejeu . . . . . . . . . .
7.3.2 Les attaques contre les intermédiaires .
7.3.3 La sécurité du dernier kilomètre . . . .
7.4 Vulnérabilités de DANE aux attaques MITM .
7.5 Conclusions sur DANE . . . . . . . . . . . . . .
Entities
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
10
11
11
11
12
12
13
13
8 Conclusion
13
9 Bibliographie
14
1
Introduction
nées bancaires, fichiers médicaux. . .) entre partis accordant leur confiance à l’IGC.
Pour ce faire, ces sociétés de certification attestent à
l’aide d’un certificat que leur client est bien celui qu’il prétend être, après des vérifications d’identité plus ou moins
sérieuses.
Le problème de ce système est que plusieurs ACs peuvent
certifier un même client (plus précisément, un même Common Name (CN)) et qu’il n’existe pas de moyens — tel
qu’est actuellement utilisé X.509 — pour un administrateur d’énoncer de manière fiable à quelles ACs il a légitimement demandé un certificat.
Un attaquant réussissant à passer les tests de vérification
d’identité ou les mesures de sécurité mises en place par
une AC (n’importe laquelle !), peut dès lors parfaitement
obtenir un certificat valide. Il lui est alors possible d’impersonner un serveur TLS sans que le moindre avertissement
ne soit levé par les clients TLS (puisque le certificat est
valide).
Le modèle oligarchique utilisé actuellement par les
ACs est, en effet, que chacune de ces sociétés possède le
même pouvoir de certification que les autres (possibilité
d’émettre des certificats pour n’importe quel CN), à partir
du moment où elle est acceptée dans le cercle "fermé" des
ACs mises par défaut dans les magasins des clients TLS
(navigateurs 1 , Mail User Agent (Client email) (MUA),
. . .).
De fait, pour le prospect en recherche de certification,
il n’existe aucune différence en terme de sécurité entre se
faire certifier par une AC "de seconde zone", ou par Verisign (première AC à avoir été acceptée par Netscape (à
l’époque connue sous le nom "RSA Certification Authority")). Pour lui, la seule différence est donc au niveau du
prix de la certification (et plus récemment, le risque encouru de choisir une AC risquant de se faire bannir des
magasins, comme ce fût le cas pour DigiCert Sdn Bhd ).
Ce type de concurrence incite donc les ACs à tirer les
prix vers le bas, quitte à rogner sur la qualité de leurs services : vérification de l’identité, et infrastructure robuste
et sécurisée. S’en suit les déboires que nous avons connus.
PKIX ne souffre cependant pas uniquement de cette
oligarchie incontrôlée. Pour qu’un certificat reste sûr
(celui-ci reposant sur des paires de clés cryptographiques
dont la sécurité peut être remise en cause au bout d’un
certain temps), il contient notamment une date limite de
validité.
Si la vie d’un certificat doit prendre fin avant sa date d’expiration (compromission, fin d’utilité, perte de la clé privée. . .), il est nécessaire de le révoquer.
Utilisée depuis une quinzaine d’année, après l’introduction du modèle en 1994 dans le navigateur Netscape,
l’IGC/PKI reposant sur les Autorités de Certification
(ACs) en vue d’assurer les communications sur les protocoles Secure Socket Layer (SSL) puis TLS a connu en
2011 une série de déboires ayant retentis jusque dans la
presse commune.
Les défauts des certificats PKIX sont cependant bien
connus des spécialistes qui tirent à boulets rouges sur ce
modèle depuis des années, sans être écoutés des acteurs du
marché, trop contents de pouvoir se reposer sur une architecture inspirant la confiance aux utilisateurs (le fameux
petit cadenas jaune. . .).
Le tremblement de terre inspiré par l’affaire Comodo
[Com11], l’opération Tulipe Noire (DigiNotar ) [FI11] et
plus récemment le retrait de l’Autorité de Certification
(AC) DigiCert Sdn Bhd (suite à de mauvaises pratiques)
[Moz11], a cependant permis de relancer la réflexion sur
des modèles alternatifs ou complémentaires à cette IGC
décadente.
Ce document présente une partie des problèmes de
PKIX tel qu’il est utilisé actuellement, puis présente des
solutions alternatives ou complémentaires à ce modèle :
Trust On First Use (TOFU), Convergence, Certificate Authority Transparency and Auditability (CATA), les clés
souveraines et DANE.
DANE, encore à l’état de brouillon à l’Internet Engineering Task Force (IETF), sera, notamment, mis en lumière,
afin d’étudier ses capacités de restriction d’autorité des
certificats et des ACs et d’addition d’ancres de confiance
par l’intermédiaire du DNS.
2
PKIX
Les certificats PKIX, signés par des ACs au moyen de
la cryptographie à clé publique, sont actuellement le modèle le plus répandu de vecteur de confiance sur l’Internet.
Ces derniers sont notamment utilisés pour des transactions
TLS en vue de sécuriser le transport de protocoles tels que
HyperText Transfer Protocol Secure (HTTPS).
Ces ACs — des sociétés privées qui devraient [Zor11,
Nig08,ZS09] satisfaire les plus hauts niveaux d’exigence en
matière de qualité et sécurité — jouent le rôle de tiers de
confiance, afin de distribuer les outils nécessaires à l’établissement de communications sécurisées pour l’échange
d’informations confidentielles (authentification, coordon-
1. Dans le magasin d’un navigateur classique, il existe environ un cinquantaine de racines et plusieurs centaines d’ACs, par défaut [Eck11a]. Dans les faits, l’utilisateur lambda ne connait même pas la notion d’AC et fait aveuglément confiance au cadenas jaune,
comme il y a été habitué. La décision d’à qui faire confiance est donc entre les mains seules des fournisseurs de clients TLS, des administrateurs des postes de travail (e.g. dans une société, ce qui permet de certifier n’importe quoi et de monter une attaque Man In The
Middle (Homme du milieu) (MITM) sur l’ensemble des serveurs TLS consultés par les employés), et des attaquants ayant réussi à glisser
leurs certificats dans le magasin des clients TLS.
3
La technique qui a été initialement adoptée afin de répondre à cette problématique est la publication de listings
contenant des informations sur les certificats ayant été révoqués : les Certificate Revocation List (Liste de révocation de certificats) (CRL).
En pratique, cependant cette approche ne fonctionne pas
pour les raisons suivantes :
également sujettes aux attaques DoS ; La mauvaise pratique consistant à considérer le certificat comme valide à
défaut d’avoir pu vérifier sa validité est à nouveau très
souvent observée.
Ces derniers défauts (atteinte à la vie privée, et DoS de
la requête OCSP) peuvent être évités par l’OCSP-stapling
(littéralement "agrafage OCSP"), technique consistant à
ce que le serveur TLS fasse lui-même la requête OCSP et
joigne (agrafe) la réponse de l’AC, cryptographiquement
signée, au certificat envoyé au client TLS.
Dans la pratique, il est cependant souvent observé que
ni les validations contre les CRL, ni les requêtes OCSP
(avec ou sans agrafage) ne sont faites [Lan11a], causant
un véritable problème de sécurité, puisque la notion de
révocation est purement et simplement ignorée, et qu’un
certificat compromis reste dès lors valable jusqu’à sa date
d’expiration initialement programmée. De plus, de nombreux périphériques embarqués ou logiciels mal conçus ne
disposent même pas de magasins de certificats d’autorités
racines, et acceptent n’importe quel certificat, même autosignés (ce qui réduit à néant la notion même d’IGC, et
n’offre qu’un simulacre de sécurité en utilisant par mimétisme/singerie des technologies qui ne sont manifestement
pas comprises).
Pire encore, des études [SEA+ 09] montrent que les utilisateurs ne comprennent pas/ne tiennent pas compte des
avertissements donnés par leurs navigateurs quand un certificat est détecté comme invalide (la faute aux fréquentes
mauvaises gestions des certificats (e.g. Figure 1), aux certificats auto-signés ou signés avec une AC privée mais accessibles par l’Internet) et sont prêts à cliquer autant que
de nécessaire pour accéder à leur site (malgré la complexification volontaire de cette procédure par les navigateurs
pour tenter de circonscrire cette démarche).
Bien qu’il existe encore bien d’autres problèmes à
PKIX [Gar05], les points qui viennent d’être abordés sont
ceux auxquels tentent de répondre les technologies qui sont
abordés dans ce document.
Il est important de noter que l’usage seul de certificats
X.509 dans le cadre d’une négociation entre un client et
un serveur TLS avec ce dernier cherchant à s’authentifier
auprès du client TLS est traité.
L’usage des certificats X.509 pour l’authentification des
clients auprès des serveurs n’a que très rarement été déployé, compte tenu de la complexité de gestion de ces derniers (en particulier, à cause de la révocation auprès d’une
AC tierce et des procédures impliquées). Les quelques déploiements constatés sont généralement avec des certificats
auto-signés ou dépendants d’une AC privée, auquel le serveur fait confiance (pas de besoin de reconnaissance en
dehors de la structure les ayant émis). Les problèmes de
multiples racines et de non-utilisation des schémas de révocations sont alors beaucoup plus simples à circonscrire
et n’ont pas besoin des technologies présentées dans ce do-
– Les listes de révocation ne sont pas centralisées et
chaque AC doit donc gérer, et mettre à disposition
des clients TLS sa propre CRL (avec de la haute
disponibilité, cf. point suivant). Cela signifie qu’un
client seul ne peut révoquer un certificat et qu’il
doit nécessairement prévenir son AC et attendre que
celle-ci mette à jour la CRL. De plus, même si la
CRL est signée par l’AC (pour éviter les attaques
MITM), si celle-ci est piratée, la liste des certificats
révoqués peut devenir contrôlable par l’attaquant
(retrait de révocations) ;
– Les CRL sont disponibles à la demande du client
TLS au lieu de lui être imposé. Cela signifie que si un
client n’est pas en mesure de récupérer la CRL, pour
des raisons de défaillances réseau fortuites (incident
sur le chemin d’accès à l’AC) ou non (attaque de
type Denial of Service (Déni de Service) (DoS) pour
prévenir que le client ne la récupère), la vérification
ne peut être faite. Dans de nombreux cas, pour éviter de frustrer le client, le contrôle de non-validité
n’est alors pas fait, et le certificat est accepté, ruinant ainsi le modèle de sécurité [Dis11] ;
– Les CRL peuvent être très longues ce qui peut poser
des problèmes pour les périphériques aux ressources
limitées qui ne peuvent la télécharger et l’analyser
(coût en mémoire et/ou temps de calcul trop important) [Sys]. Dans ce cas, la vérification n’est bien
souvent pas faite.
Compte tenu de l’inefficacité pratique des CRL, un
autre protocole a été créé : Online Certificate Status Protocol (OCSP) [MAM+ 99]. Ce protocole permet à un client
TLS, ayant reçu un certificat de la part d’un serveur TLS
dans le cadre d’une poignée de main, d’interroger — via
une requête HTTP — une AC sur le statut actuel (valide,
révoqué, . . .) du certificat reçu et émanant d’elle.
La réponse reçue ne contenant que le statut pour un certificat spécifique, les problèmes de lourdeur des CRL et de
leur traitement coûteux sont résolus. Les problèmes apparaissant à cause de ce protocole sont cependant importants
puisqu’il y a nécessité d’avoir un dialogue avec l’AC (nécessité d’un chemin réseau menant à l’AC), et l’AC apprend
que le client TLS cherche à vérifier tel certificat (problème
de traçabilité/vie privée ; c’est d’ailleurs notamment par
surveillance des origines des requêtes OCSP que les certificats émis frauduleusement par DigiNotar ont été retrouvés "en exploitation" lors de l’opération Tulipe Noire).
Les requêtes de validation OCSP, à l’instar des CRL, sont
4
$ openssl s_client -connect fr.twitter.com:443 2>&- | grep "^subject=" | sed -e "s/^.*CN=\(.*\)/\1/"
twitter.com
Figure 1: Certificat Twitter invalide
3
cument.
Les certificats utilisés pour S/MIME (signature d’emails
et de documents) ne sont également pas traités. Un début
de brouillon a été proposé pour adapter DANE à la signature d’emails mais ne reçoit à l’heure actuelle aucune participation. Depuis le déploiement de Domain Name System Security Extension (DNSSEC), l’utilisation de technologies comme celles décrites dans la Request For Comments (RFC) 4398 [Jos06] peuvent répondre à cette problématique.
TOFU : Trust On First Use
TOFU signifie "accorder sa confiance lors du premier
usage". Cette approche, bien connu des administrateurs
système qui l’utilisent régulièrement avec SSH 1 est également celle utilisée lorsqu’on ajoute de manière permanente
un certificat invalide (e.g. auto-signé) à son magasin.
Le principe général est de considérer, par un acte de foi
(TOFU est également appelé, en anglais, "leap of faith"),
que la première fois que l’on reçoit un certificat, celui-ci
n’a pas été émis par un attaquant.
Une fois le certificat accepté une première fois, il est admissible que toute communication future impliquant ce
certificat soit avec le même correspondant. Le client TLS
n’émettra dès lors un avertissement qu’à la réception d’un
nouveau certificat.
Ce cas de figure ne se présente que dans ces deux cas :
– Un attaquant commence, (respectivement, termine)
une attaque MITM. Le certificat reçu est alors celui
de l’attaquant (respectivement, celui du serveur légitime). Ce changement est détecté puisqu’un nouveau
certificat, inconnu, est reçu ;
– Le serveur TLS légitime change de certificat (expiration, compromission, perte de la clé privée. . .).
Lors de cet avertissement, l’utilisateur est alors requis
de prendre une décision : accorder à nouveau sa confiance
à ce nouveau certificat, ou non.
Si cette approche est plébiscitée par certains [Pal], elle
est difficilement applicable par l’utilisateur lambda qui
ignore généralement les warnings et validera n’importe
quel certificat sans se soucier qu’il s’agisse d’un changement de certificat légitime ou non.
Cette approche a cependant un avantage certain : sa
simplicité de mise en oeuvre. Il suffit en effet de vider son
magasin des ACs qui y sont actuellement configurées. Une
approche moins nihiliste pourra être d’installer un module
complémentaire à son navigateur (tel que Certificate Patrol 2 ) qui détectera les changements de certificats (même
validés par les ACs) et alertera l’utilisateur en fonction du
niveau de probabilité que ce changement soit illégitime.
Pour résoudre le problème qui nous concerne, nous étudierons les 5 approches suivantes :
– TOFU : L’approche TOFU est basée sur la politique
de sécurité très simple qui est de faire confiance au
certificat qui est fourni à la première connexion à un
serveur TLS et de n’avertir l’utilisateur d’un danger
que si ce certificat change ;
– Convergence : Un protocole permettant d’interroger
des tiers de confiance usant potentiellement de différentes techniques (DANE, Perspectives, . . .) et votant afin de déterminer la validité ou non d’un certificat (éventuellement auto-signé) ;
– CATA : Reposant sur la notion d’un journal public signé et dupliquable dans lequel les ACs seraient
obligées d’enregistrer les certificats qu’elles émettent
(sans quoi le certificat ne serait pas validable par les
clients TLS) et qui peut donc être monitoré par les
propriétaires de certificats afin de détecter des certificats émis frauduleusement ;
– Les clés souveraines : Une approche dans laquelle les
certificats des transactions TLS seraient signés par
des clés souveraines, enregistrées dans un journal distribué, publique et étant uniquement extensible (impossibilité de modifier les enregistrements précédemment insérés). L’enregistrement des clés souveraines
se feraient après que les administrateurs aient prouvé
leur autorité sur le domaine qu’ils souhaitenet protéger (par la possession d’un certificat PKIX valide,
ou par validationDANE) ;
– DANE : Un protocole reposant sur la publication
d’enregistrements Domain Name System (DNS) signés (DNSSEC) contenant des certificats (éventuel- 4
Convergence
lement auto-signés) ou des informations sur les certificats légitimes pouvant être utilisés par un client
Convergence 3 est un protocole, implémenté pour
TLS.
l’heure par un client (sous la forme d’un module com-
1. Alors qu’il est possible d’utiliser un enregistrement DNS SSHFP (qui plus est protégé par DNSSEC) pour fournir l’empreinte de la
clé utilisée par un serveur SSH. [SG06]
2. Certificate Patrol
3. Site officiel de Convergence
5
plémentaire Firefox) et un serveur (autrement appelé Notaire) en bêta-test. Il a été introduit lors de la conférence
Black Hat 2011 [Mar11].
Plus qu’un simple programme, Convergence établit un
"framework" permettant à diverses techniques d’être utilisées, par l’intermédiaire de serveurs appelés "Notaires",
afin de vérifier l’authenticité (éventuellement probabiliste)
d’un certificat rencontré.
Les Notaires sont librement installables sur n’importe
quelle machine reliée à l’Internet, afin de permettre une
véritable architecture distribuée. Le code d’un Notaire est
actuellement disponible sur le site officiel du projet. Ce
Notaire utilise un dérivé de l’approche introduite par Perspectives 1 pour valider ou non un certificat qui lui est soumis.
Le client Convergence est libre d’ajouter un nombre arbitraire de Notaires auxquels il souhaite faire confiance.
A tout moment, celui-ci est libre de révoquer la confiance
qu’il accorde à un Notaire. Cette propriété est appelée
"Agilité du lien de confiance" ("Trust Agility") et est l’un
des fers de lance de cette solution.
La décision finale à propos d’un certificat est laissée
au client Convergence qui est libre d’adopter la politique
de son choix : accepter le certificat si 1, (N ÷ 2) + 1 ou
N Notaires donnent un avis favorable concernant ce certificat (avec N, le nombre de Notaires auquel le client fait
confiance).
Afin de préserver la vie privée de ses utilisateurs et
de ne pas tomber dans le même travers que les requêtes
OCSP (qui permet, indirectement, d’espionner à quel serveur TLS un client se connecte), deux mécanismes ont été
mis en place :
– Un cache local. Le client Convergence, à l’instar de
TOFU, ne contacte les Notaires configurés qu’à la réception d’un nouveau certificat (ou lorsque le cache a
été purgé). Si l’information concernant la première
visite est bien transmises aux Notaires, les visites
suivantes ne le sont plus, ce qui prévient l’apprentissage par les Notaires des habitudes de l’utilisateur
sur l’Internet (e.g. : Quel serveur TLS ? Quand ? À
quelle fréquence ?) ;
– Les Notaires implémentent un système de rebond qui
permet à un client de choisir aléatoirement un Notaire de sa liste de Notaires de confiance et de lui
demander de lui renvoyer le résultat (signé) de tous
les Notaires auquel il fait confiance, ce qui permet
de n’alerter qu’un seul Notaire de la visite d’un site
donné (les autres ne recevant qu’une requête anonymisée). Le défaut de cette approche est cependant
que le notaire effectuant le rebond est alors capable
d’apprendre la liste des Notaires auquel un client fait
confiance.
En dehors de la capacité de rebond, et de l’interface
standard de communication avec un client Convergence
(Application Programming Interface (API) basée sur Representational state transfer (REST)), un Notaire est libre
de choisir la technique de validation qui lui sied (du pile ou
face (hum. . .), à Perspectives, en passant par la vérification
de la signature d’une AC (avec un magasin éventuellement
restreint en fonction de l’actualité. . .), ou par DANE ou
tout autre système imaginable), pour peu qu’une implémentation existe.
Au 28 décembre 2011, Convergence souffre cependant
de quelques défauts, principalement dus à sa jeunesse :
– Une seule approche de validation existe : Perspectives ;
– Le code a une maturité faible (il n’est qu’en version
Bêta) ;
– Il n’existe qu’une seule implémentation du protocole
("software variety problem") ;
– Les serveurs TLS n’étant pas publiquement visibles
ne peuvent pas bénéficier de l’avis de Notaires externes basés sur Perspectives. Il n’est actuellement
pas prévu que les prochaines versions les prennent
en compte ;
– La validation des serveurs TLS utilisés avec les portails captifs est impossible (ce qui pose un sérieux
problème puisque c’est le genre d’environnement très
propice à des attaques MITM) ;
– La fuite d’information sur notre navigation lors de
la réception d’un certificat inédit et la fuite d’information de la liste des Notaires auxquels nous faisons
confiance sont deux problèmes impactant la vie privée de l’utilisateur ;
– L’unique implémentation existe sous la forme d’un
module complémentaire pour Firefox. Cela signifie
qu’elle n’est pas installée par défaut mais sur la base
du volontariat des utilisateurs et que seul Firefox
est en mesure d’utiliser ce protocole pour l’heure.
De plus, il est illusoire, même si Convergence était
intégré dans le code des navigateurs, d’espérer que
les utilisateurs lambda modifient la liste des Notaires
auxquels ils font confiance (puisqu’ils ne le font pas
avec les ACs). Les Notaires configurés par défaut subiraient une très forte charge serveur et auraient une
très grande responsabilité (décision suprême, et leur
indisponibilité signifieraient la prévention d’accès à
tous les serveurs TLS). Il pourrait s’en suivre que
les grands groupes émetteurs de navigateurs pourraient configurer leurs propres Notaires par défaut,
leur accordant encore plus qu’avec le choix des ACs
de "confiance", l’autorité suprême sur nos transac-
1. Projet Perspectives – Le principe est de demander à un tiers de constater si le certificat qu’il reçoit, pour un serveur TLS (ou autre,
e.g. SSH) donné, est différent du certificat que le client Perspectives a reçu. S’ils diffèrent, le client Perspectives ou le tiers est peut-être
victime d’une attaque MITM. Un avertissement est alors affiché.
6
tions sécurisées, ce qui est inacceptable [Lan11b] ;
– Les Notaires basés sur Perspectives ne peuvent fonctionner correctement lorsqu’ils sont confrontés au
problème "Citibank". Certains administrateurs de
serveurs TLS répartissent, en effet, aléatoirement
la charge entre plusieurs serveurs disposant chacun
d’un certificat différent. De fait, le Notaire validant
les certificats avec Perspectives n’est nullement assuré de recevoir le même certificat que le client
Convergence et risque de lui renvoyer, à tort, un
désaveux de ce certificat ;
– Les Notaires ne peuvent à l’heure actuelle pas être
pondérés, ce qui pourrait être souhaitable pour réellement refléter la confiance relative que l’on peut apporter à un Notaire, et même créer des politiques de
sécurité avancées telles que "pour le réseau X (au hasard, un réseau interne, actuellement non supporté),
faire une confiance absolue à tel Notaire, et sinon, ne
pas lui demander son avis". Le développement d’un
Notaire de type "Proxy" pourrait permettre ce genre
de cas d’utilisation sans augmenter la complexité du
client Convergence.
5
d’une "preuve de contrôle". Cette dernière serait constituée de la signature de Merkle du certificat (i.e. la liste
des condensats jusqu’à la racine de l’arbre et la signature
de la racine).
Le papier publié par les ingénieurs de Google ne
contient pour le moment pas d’explication sur le mécanisme de révocation.
D’une manière générale, le document est pour le moment bien trop vague sur de trop nombreux points pour
qu’une critique construite soit établie. On peut cependant
soulever les présents points :
– Combien de journaux devront être créés ?
– Qui tiendra ces journaux ?
– Que se passerait-il si ces journaux devenaient indisponibles (chemin réseau indisponible) ?
– Comment fonctionnera la révocation ?
– Pourquoi ces journaux seraient plus efficacement
consultés que les CRL ?
– Comment se dérouleront les validations de certificats
auto-signés ou émanant d’IGC privée ?
– Comment une AC pourrait-elle être destituée de son
statut de tiers de "confiance" dans un tel schéma ?
CATA : Certificate Authority 6
Transparency and Auditability
Les clés souveraines
Les clés souveraines [Eck11c, Eck11b] sont une proposition de l’Electronic Frontier Foundation (EFF).
Une clé souveraine est une paire de clés cryptographiques dont la partie publique (clé publique) est associée à un nom de domaine (et éventuellement à ses sousdomaines) afin de créer une "ancre de confiance" (Trust
Anchors) pour ce dernier.
L’association clé publique-nom de domaine est enregistrée dans des journaux publiques exclusivement extensibles, maintenus et publiés sur serveurs nommés "timeline
servers" (littéralement, "serveurs de chronologie")).
La partie privée de la clé souveraine (clé privée) permet
de signer des certificats dont le CN est le nom de domaine
(ou un sous-domaine) auquel la clé publique a été associée.
Lors d’une poignée de main avec un serveur TLS, le certificat envoyé est accompagné de sa signature par la clé
souveraine du domaine qu’il protège, selon les mêmes mécanismes par lesquels sont envoyés les certificats intermédiaires dans une transaction TLS reposant sur PKIX.
Le client est alors en mesure de récupérer la clé publique
associée à cette clé souveraine, auprès des timeline servers,
vérifier que la clé souveraine est toujours active, qu’elle
certifie bien le domaine concerné par la transaction TLS,
et qu’elle a bien signé le certificat reçu.
Le cycle de vie d’une clé souveraine commence par la
création d’une paire de clés cryptographiques par l’administrateur du domaine souhaitant proposer un service
TLS. L’administrateur voulant publier la partie publique
CATA [LL11], littéralement "Transparence et contrôlabilité des ACs", est une proposition tenant pour le moment en quelques pages écrites par deux ingénieurs travaillant pour Google et probablement inspiré d’un brevet,
que Google a déposé il y a des années, portant sur la gestion de CRL à base d’arbres [Mic00].
Le principe général est la tenue de journaux publiques
contenant la liste des certificats émis par les ACs. Les
clients TLS seraient alors tenus de vérifier la présence du
certificat reçu du serveur TLS dans les journaux publiques.
Si ce certificat ne faisait pas parti de la liste des certificats
valides pour ce domaine, il serait alors rejeté.
Ces journaux étant publiques, l’administrateur
consciencieux d’un domaine pourrait surveiller qu’aucune
AC ne publie un certificat frauduleux pour son domaine
(car il doit être publié dans le journal pour être reconnu
par les clients TLS) et qu’auncun mainteneur de journal ne cherche à introduire un certificat sans l’accord
du propriétaire du domaine. Si cela se produisait, l’AC
ou le mainteneur de journal serait, de fait, rapidement
confondus.
Les journaux seraient des sortes de listes exclusivement
extensibles et prendraient la forme d’arbres de Merkle signés, éventuellement fragmentés en différents fichiers en
fonction de la signature de Merkle des noeuds.
Afin de valider un certificat fourni par un serveur TLS,
celui-ci devrait être accompagné (par un moyen à établir)
7
de la clé souveraine doit prouver qu’il contrôle le-dit domaine avant de la voir enregistrée dans les journaux publiques.
Pour cela, il doit fournir soit un certificat (dont le CN englobe le nom de domaine déclaré comme protégé par cette
clé souveraine) signé par une AC reconnue par les timeline
servers 1 ou via DANE (quand la norme sera publiée. . .).
pour Simple Mail Transport Protocol Secure (SMTPS),
Internet Message Access Protocol (IMAP) pour Internet
Message Access Protocol Secure (IMAPS). . .).
Cette dernière mesure a probablement été imposée par
peur d’attaques par rétrogradation du niveau de sécurité
(downgrade attacks), mais est intrusive dans la liberté de
gouvernance d’un service (utilisation peut-être abusive du
MUST normatif).
Lors de l’enregistrement de la clé publique par les tiParmi les autres problèmes posés par les clés souvemeline servers, les preuves de contrôle du domaine (par raines, on peut compter :
OCSP ou résolution DANE) sont vérifiées puis insérées
– La perte de la clé privée de la clé souveraine peut enconjointement à diverses méta-données à propos de cette
trainer une longue indisponibilité des services TLS
clé souveraine.
si aucune révocation n’est possible (pas de tiers de
Notamment, une clé souveraine est accompagnée de sa
confiance déclaré). Le conseil donné dans les spécifidate d’expiration, des noms (et éventuels ports) des sercations pour éviter ce problème est de dupliquer la
vices TLS 2 fournis par les serveurs de ce nom de domaine
clé privée afin d’être sûr de toujours en avoir une
et protégés par la clé souveraine, ainsi que d’une liste,
copie. . . ;
éventuellement vide, de noms de domaine dont les clés
– La compromission de la partie privée de la clé souvesouveraines sont autorisées à révoquer (en cas de perte de
raine peut entrainer une perte définitive de contrôle
contrôle de la partie privée de la clé souveraine) l’entrée
d’un nom de domaine pour tous les clients validant
en cours d’insertion.
les clés souveraines. En effet, si la clé est compromise,
Les journaux étant uniquement extensibles, une fois un enun attaquant possédant également une preuve valide
registrement inséré, il est définitivement inaltérable. Toute
de contrôle du domaine (e.g. un certificat obtenu aumodification de ces informations est représenté par l’inserprès d’une AC piratée) peut décider de révoquer la
tion d’une nouvelle entrée de mise à jour. Cette demande
précédente clé souveraine pour en déclarer une noud’erratum doit être signée par la clé souveraine adminisvelle inconnue du propriétaire légitime du domaine
trant le nom de domaine associé. Si cette signature est imattaqué (l’ordre étant auto-signé avec la précédente
possible à produire, le propriétaire d’un nom de domaine
clé souveraine, il est non-répudiable et semble légiest incapable de procéder à la mise à jour des informations
time) et vider dans le même temps la liste des entités
de la clé souveraine. Il doit alors la faire révoquer par les
capables de révoquer la clé souveraine de ce nom de
tiers de confiance qui le peuvent (nommés initialement ou
domaine. Ce problème remet en question le conseil
par mise à jour) ou attendre son expiration, si aucun tiers
donné par les spécifications pour répondre au pron’a été nommé à ce moment.
blème du point précédent ;
Cette obligation est utile afin de prévenir qu’une compro– Si un administrateur ne s’intéresse pas en premier
mission d’une AC ou du DNS ne permettent la compromisaux clés souveraines (ou si sa clé souveraine expire
sion de la clé souveraine, par rebond (attaquant en mesure
sans qu’une nouvelle clé souveraine ne soit publiée),
de fournir la preuve de sa prise de contrôle du domaine atun attaquant obtenant un certificat signé par une
taqué), mais requiert la prudence, car un administrateur
AC reconnue par les timeline servers (ce qui repréincompétent peut perdre le contrôle de son propre nom de
sente le problème que les clés souveraines tentent de
domaine.
résoudre) peut déclarer avant le propriétaire légitime
Outre les règles de gestion de serveurs miroirs afin
(ou pendant l’intervalle pendant lequel la précédente
d’augmenter la disponibilité des journaux publiques (le
clé est expirée et la nouvelle non-déclarée) une clé
nombre de timeline servers étant par conception limité
souveraine (qui sera reconnue par tous les clients vaà quelques dizaines), de gestion des compromissions des
lidant les clés souveraines) et le propriétaire légitime
timeline servers et des miroirs, de gestion des réplications
aura perdu définitivement la capacité de publier une
inter-timeline servers des enregistrements, et autres règles
clé souveraine légitime ;
de gestion interne, les spécifications des clés souveraines
– Les serveurs miroirs consultés pour obtenir la clé
précisent qu’un service déclaré comme protégé (pour un
souveraine d’un domaine apprennent l’historique de
domaine donné) dans un des journaux publiques ne doit
navigation d’un client validant les signatures des
pas être également disponible dans une version vulnérable
clés souveraines. Aucun mécanisme spécifique pour
du même protocole (HyperText Transfer Protocol (HTTP)
contrer ce problème n’a été précisé dans les spécificapour HTTPS, Simple Mail Transport Protocol (SMTP)
tions et a été laissé à la discrétion des implémenteurs
1. La liste des ACs reconnues par les timeline servers est publique (et nécessairement à jour, par des détails de conception).
2. Les noms officiels des services sont déclarés à l’IANA
8
des validateurs.
7
déraisonnable en usant uniquement d’enregistrements de
type 1.
Un second usage pour les enregistrements de type 0
pourrait être de palier aux demandes d’émission de certificats frauduleuses. Les ACs pourraient effectuer une vérification de leurs présences dans les enregistrements DANE
au CN demandé avant d’émettre un certificat.
DANE : DNS-based Authentication of Named Entities
7.1
Fonctionnement de DANE
Deux autres champs constituent un enregistrement
DANE 1 est une technologie basée sur le DNS permetTLSA (en plus de son contenu) :
tant à l’administrateur d’un nom de domaine de publier
– Un sélecteur ("selector field") qui permet de choisir
des informations à propos des certificats PKIX utilisés par
entre le fait que l’enregistrement TLSA contienne
ses serveurs TLS.
des informations sur le certificat en entier (sélecLe brouillon 13 de DANE [HS11] définit un nouveau
teur 0) ou uniquement sur les informations cryptotype d’enregistrement DNS nommé TLSA. L’emplacement
graphiques du certificat (Subject Public Key Info)
auquel doit être placé un enregistrement TLSA dans la
(sélecteur 1) ;
hiérarchie du DNS est défini par 3 informations :
– Un sélecteur ("matching type field") qui permet de
– Le nom de domaine auquel est accessible le service
choisir entre différentes représentations de l’informaTLS (i.e. le CN des certificats PKIX qui seront sertion sélectionnée par le champ précédent : telle quelle
vis) ;
(0) ou hashée (et avec quel algorithme : SHA-256 (1),
– Le protocole de transport utilisé par le service TLS
SHA-512 (2)).
(e.g. TCP, UDP ou SCTP) ;
Voici un aperçu des différents enregistrements TLSA :
– Le port sur lequel le service TLS est accessible.
Type 0, Certificat, SHA-256 :
Ainsi, un enregistrement TLSA protégeant du contenu,
_443._tcp.www.exemple.tld. IN TLSA (
servi en HTTPS sur le port 443, pour le nom de
0 0 1 d2abde240d7cd3ee6b4b28c54df034b
domaine exemple.tld se verra placé dans la hiérar7983a1d16e8a410e4561cb106618e971 )
chie DNS au Full Qualified Domain Name (FQDN)
_443._tcp.exemple.tld.
Type 1, Subject Public Key Info, SHA-512 :
_443._tcp.www.exemple.tld. IN TLSA (
Un enregistrement TLSA permet de publier deux fa1 1 2 92003ba34942dc74152e2f2c408d29ec
milles d’information :
a5a520e7f2e06bb944f4dca346baf63c
– Restrictives. Deux types d’enregistrements restric1b177615d466f6c4b71c216a50292bd5
tifs existent :
8c9ebdd2f74e38fe51ffd48c43326cbc )
– Type "0" : L’ensemble des enregistrements de
ce type forment la liste exhaustive des ACs ayant
émis des certificats légitimes pour le service proType 2, Certificat, Plain Text :
tégé par ces enregistrements.
_443._tcp.www.exemple.tld. IN TLSA (
– Type "1" : L’ensemble des enregistrements de
2 0 0 30820307308201efa003020102020...)
ce type forment la liste exhaustive des certificats
PKIX pouvant être utilisés par le service protégé
DNS étant une technologie très vulnérable aux atpar ces enregistrements.
taques MITM et aux attaques par empoisonnement de
– Additives (Type "2") : ce type d’enregistrement cache [Bor08, AA04], la RFC 6394 [Bar11] recommande
permet de publier une ancre de confiance ("Trust l’usage de DNSSEC pour protéger les enregistrements
Anchor") qui pourra être utilisée (sauf politique lo- TLSA de types 0 et 1 et le rend obligatoire pour le type
cale spécifiant le contraire) pour valider les certifi- 2.
cats fournis par le service TLS concerné par cet enre- Le treizième brouillon du protocole DANE se propose d’algistrement. Cette fonctionnalité permet notamment ler plus loin et de rendre obligatoire DNSSEC de bout-end’utiliser des certificats auto-signés sans qu’aucun bout pour tous les usages de DANE [HS11].
avertissement ne soit affiché à l’utilisateur.
Cette décision est justifiée par les besoins de résister à
Les enregistrements de type 0 permettent, entre autre, des attaques de type dégradation du niveau de sécurité
de répondre au problème CityBank (déjà abordé plus haut ("downgrade attacks"), et pour limiter les effets des atdans ce document). En effet, compte tenu que certains ad- taques MITM. Ainsi, l’acceptation des enregistrements
ministrateurs utilisent des dizaines de certificats pour un TLSA se fait sur la base de la politique de sécurité suimême service TLS, la taille de la réponse DNS aurait été vante :
1. Groupe de travail DANE – IETF
9
– Si la signature DNSSEC est valide, les enregistrements TLSA devraient ("should") être utilisés pour
essayer de valider le certificat reçu par le serveur
TLS. Si la validation DANE de ce certificat échoue,
la transaction TLS est abandonnée. Si le verdict de
DANE est positif et que le certificat est également
rattachable à une ancre de confiance (qu’elle soit issue d’un enregistrement TLSA valide de type 2, ou
du magasin de certificats du client TLS) alors le petit cadenas jaune est affiché :o) ;
– Si la signature DNSSEC des enregistrements TLSA
est invalide ("Bogus") (pour des raisons de réseau
mal configuré ou d’attaque), la transaction TLS doit
être abandonnée ;
– Si une réponse est non signée, avec un état d’authenticité indéterminé, ou que la validation DNSSEC n’a
pas eu lieu en local et que le canal entre le client
DANE et le résolveur DNS n’est pas sécurisé, alors
les enregistrements TLSA ne doivent pas être utilisés. Dans ce cas, seule la vérification du certificat
contre les certificats du magasin du client TLS est
effectuée (comme si aucune validation DANE n’avait
été entreprise).
Ainsi protégé par DNSSEC, un administrateur utilisant DANE peut restreindre les certificats utilisables (type
0 et 1) sans risque de voir un attaquant utiliser des certificats obtenus illégitimement auprès d’une AC (puisqu’étant
incapable de signer des enregistrements TLSA frauduleux
pour rendre légitime ses propres certificats).
Les enregistrements DANE restrictifs peuvent également
être utilisés afin de "révoquer" un certificat compromis
en attendant que l’AC change son statut officiel (dans les
CRL et les résultats des requêtes OCSP).
De la même manière, un administrateur pourra grâce à
DANE (et aux enregistrements TLSA de type 2) faire
valider des certificats auto-signés ou issus d’une AC inconnue d’un client TLS, sans qu’un attaquant ne puisse
en faire autant, même en position de faire une attaque
MITM, puisqu’il ne sera pas capable d’imiter la signature
DNSSEC nécessaire à la prise en compte de son ancre de
confiance.
Malgré cela, un client utilisant DANE reste tout
de même vulnérable à certaines classes d’attaques
MITM, principalement duês à des faiblesses du protocole
DNSSEC. Pour cela, il nous est nécessaire de revoir en
détail le fonctionnement de DNSSEC.
7.2
7.2.1
Fonctionnement de DNSSEC
Coté serveur DNS
La signature des enregistrements DNS par DNSSEC se
fait traditionnellement hors-ligne, souvent directement sur
le serveur DNS "maître". Elle se fait en utilisant une ou
plusieurs paires de clés cryptographiques (cryptographie à
clé publique).
La signature hors-ligne permet de conserver les clés cryptographiques hors d’atteinte d’un attaquant compromettant un serveur 1 . Les serveurs esclaves ne font alors que
"recopier" la zone et la servir, et restent parfaitement inactifs cryptographiquement vis-à-vis de DNSSEC 2 .
Lors de la signature de la zone DNS, chaque "jeu" d’enregistrements d’un même type ("Ressource Record Set")
se voit associé un enregistrement de type RRSIG. Cet enregistrement représente la signature de ce jeu d’enregistrements, et contient, en plus de la signature, diverses informations la concernant dont la date de signature et sa
date d’expiration et le type d’algorithme utilisé lors de la
signature.
La clé publique associée à la clé privée ayant servi à
signer les enregistrements RRSIG (ce couple est appelé
clé de signature de la zone ("ZSK")) est publiée dans un
enregistrement DNSKEY.
Traditionnellement, il est recommandé (afin de faciliter la rotations des clés) que cet enregistrement DNSKEY
soit lui-même signé par une autre paire de clés cryptographiques (appelée clé de signature de la clé ("Key Signing
Key (KSK)")), dont la clé publique est également publiée
dans un enregistrement DNSKEY.
Le hashé de la clé de signature de la clé (KSK) est
ensuite transmis à la zone parente qui le stocke sous la
forme d’un enregistrement DS (signataire de la zone déléguée (Delegation Signer)).
La zone parente procède également à la signature de sa
zone, et publie son enregistrement DS à sa zone parente,
et ainsi de suite jusqu’à ce qu’on atteigne une ancre de
confiance ("Trust Anchor").
Ce procédé peut être répété jusqu’à la racine du DNS, qui
est elle-même signée 3 .
La transmission de l’enregistrement DS à la zone parente
se fait généralement par une interface dédiée (site web. . .).
Un Second Level Domain (e.g. verisign.com., gouv.fr., . . .
(SLD) publiera généralement son enregistrement DS dans
la zone de son registre par l’intermédiaire de son bureau
d’enregistrement ("registrar").
La non-existence d’un enregistrement était traditionnellement symbolisée par le code d’erreur NXDOMAIN ("No Such Domain"). Un enregistrement inexistant n’étant pas physiquement représenté dans une zone
1. Si la signature se fait directement sur le serveur maître, il peut être judicieux de le configurer comme un serveur "furtif".
2. Le transfert de zone est généralement effectué sur un canal sécurisé, par exemple, avec TSIG [KGG+ 03].
3. Site officiel de la signature de la racine DNS
10
DNS, il ne peut générer un enregistrement RRSIG lors
de la signature de la zone. Pour un attaquant en position
d’effectuer un MITM, il serait alors possible de supprimer
la réponse signée d’un serveur légitime et de renvoyer une
réponse NXDOMAIN (non-signée) pour empoisonner un
résolveur.
Pour palier à ce risque, et signer la non-existence, les
enregistrements de type NSEC ("Next Secure") [JS04]
furent créés. Ces enregistrements signés par la clé de signature de la zone indiquent l’inexistence d’enregistrements entre deux enregistrements nommés. Le problème
est qu’il est alors trivial pour un attaquant d’énumérer
les enregistrements de la zone, ce qui peut être un problème pour certains administrateurs. Les enregistrements
NSEC3 [LSAB08] palient à ce problème en hashant les
noms des enregistrements existants qui figuraient dans les
enregistrements NSEC.
7.2.2
Coté client DNS
la racine, dont les enregistrements DS ).
Si la signature de la réponse de la racine est correcte, le
résolveur récupére les enregistrements NS et DS du SLD
duquel dépend le nom de domaine recherché, et les enregistrements RRSIG de la réponse des serveurs DNS du
TLD.
Il valide les signatures de ces enregistrements (et contrôle
qu’ils sont signés avec une clé dont l’authenticité est vérifiable grâce à l’enregistrement DS récupéré dans la zone
parente), et s’ils sont authentiques, il répète le processus
tout le long de la hiérarchie DNS jusqu’à avoir résolu le
nom de domaine recherché et validé sa signature.
Si lors de la récursion, un nom de domaine rencontré
n’a pas publié d’enregistrements DS dans sa zone parente
(on parle d’une île), alors la validation cesse, mais la récursion peut continuer.
Les enregistrements reçus à partir de ce moment peuvent
avoir été manipulés par un attaquant et doivent être considérés comme non-sûrs. Le résultat de la requête ne peut
plus être considéré comme authentique.
Deux exceptions existent, permettant à la validation
d’être reprise, à partir d’une île :
– Les enregistrements sont signés et le validateur possède une ancre de confiance pour ce nom de domaine.
Le validateur doit donc l’utiliser pour valider ces
nouvelles signatures, quand bien même la zone parente n’avait pas d’enregistrements DS pour cette
zone.
– Le validateur a été configuré avec une ancre de
confiance dans un système de validation alternatif
(DNS Look-aside Validation (DLV)). Dans ce cas, il
effectue une recherche d’enregistrements DLV pour
chaque nom de domaine récupéré afin de déterminer
si des enregistrements DLV sont disponibles pour
celui-ci.
Le résolveur renvoie au proto-résolveur le code d’erreur SERVFAIL si la signature d’une réponse est invalide
("Bogus") ou si une zone dispose d’enregistrements DS
pour une zone fille et que celle-ci renvoie des réponses
non-signées (ce qui peut être dû à une mauvaise configuration du serveur DNS de la zone fille, à du matériel
réseau mal-configuré ou obselète (incompatible avec Extension Mechanisms for DNS (EDNS0) (EDNS) [Vix99]),
ou à un attaquant qui aurait souhaité faire une attaque
par rétrogradation du niveau de sécurité ("downgrade attack")).
Lorsqu’une application souhaite obtenir une information du DNS (que ce soit une adresse IP, ou tout autre type
d’information pouvant être stockée dans le DNS), elle utilise le proto-résolveur ("stub resolver") de sa machine afin
de contacter un résolveur DNS (souvent, par défaut, celui
de son Fournisseur d’Accès à l’Internet (FAI) ou de sa société).
Lors de la requête au proto-résolveur, une application dispose de deux drapeaux relatifs à la résolution sécurisée des
noms de domaines.
– DO (DNSSEC OK) : Ce drapeau permet de requérir que les informations relatives à DNSSEC soient
renvoyées en plus des informations demandées.
– CD (Checking Disabled ) : Ce drapeau permet de forcer le résolveur à renvoyer le résultat de la récursion,
même si les données ne sont pas authentiques (i.e.
cryptographiquement vérifiables) et que la validation
est activée sur le résolveur.
Une fois le processus de résolution terminé et la validation accomplie, le résolveur renvoie au proto-résolveur soit
le code d’erreur SERVFAIL (en l’absence du drapeau CD
et dans le cas d’un incident lors de la résolution (signature
invalide, enregistrements tronqués, . . .)) soit la réponse à
la requête avec le drapeau AD ("Authentic Data") signifiant que la réponse est signée et valide.
Du coté du résolveur/validateur, la résolution
DNSSEC se déroule ainsi.
Le résolveur procède à la récupération des informations
de signature au fur et à mesure du processus de récursion, 7.3 Les problèmes de sécurité de DNSSEC
et les valide grâce à ses ancres de confiance.
Un résolveur récupère les enregistrements NS du Top
7.3.1 Les attaques par rejeu
Level Domain (e.g. com., fr., net., org., . . .) (TLD) duquel
dépend le nom de domaine qu’il cherche à résoudre auprès
DNSSEC est vulnérable aux attaques par rejeu [Ber09].
de la racine, ainsi que les enregistrements DS de ce TLD Même si un attaquant est incapable de forger un nouvel
et les enregistrements RRSIG (pour valider la réponse de enregistrement, les signatures étant effectuées hors-ligne,
11
un enregistrement reste signé pour toute la durée de validité de la signature, car il n’existe aucun mécanisme de
révocation d’une signature d’un enregistrement dans la
norme [YOH+ 08].
Le problème est que le DNS étant une architecture
relativement critique, sa résistance aux pannes est nécessaire. L’un des mécanismes notamment mis en place pour
en assurer sa robustesse est le mécanisme de réplication
maître-esclave.
Le maître définit un enregistrement de type SOA
("Start of Authority") pour chaque zone qu’il sert. Cet enregistrement contient en majorité des informations à destination des esclaves parmi lesquels on retrouve un numéro
de série (qui agit comme un numéro de "version" de la
zone, et permet une détection rapide d’un changement,
sans analyse complète de la zone), un délai de rafraîchissement des zones des esclaves, un intervalle à respecter
entre deux tentatives infructueuses de rafraîchissement, et
un intervalle d’expiration au-delà duquel une zone nonraffraichie est définitivement abandonnée.
Cette dernière donnée est notamment importante car
elle permet à un serveur esclave dont le maitre est injoignable de continuer à servir la zone, et d’éviter un
point critique dans l’architecture (Single Point Of Failure (SPOF)).
Un enregistrement dont la signature est expirée étant
considéré comme un enregistrement invalide, si la signature ne s’effectue que sur le serveur maître, alors il est
nécessaire que la signature ait une durée de vie supérieure
ou égale à l’intervalle avant expiration de la zone nonraffraichie. Si ce n’était pas le cas, un esclave pourrait
continuer à servir les enregistrements mais ceux-ci seront
tous expirés et donc invalides.
Cette situation est donc composée de deux problèmes
antagonistes :
– un impératif de sureté qui requiert que l’intervalle
d’expiration soit long ;
– un impératif de sécurité qui requiert que la signature soit le moins longtemps valide pour limiter la
période de rejeu possible.
Si l’on solutionne le problème en réalisant des signatures dont la validité est égale au Time To Live (TTL)
du jeu d’enregistrements et en signant à la volée les réponses, le problème de sécurité est alors que les serveurs
DNS esclave ont accès à la clé privée pour effectuer ces
signatures.
racine, les registres, et les bureaux d’enregistrement ("registrar") pour ne citer que les indispensables.
Si à ce jour, leur responsabilité est déjà grande, compte
tenu qu’un attaquant peut prendre le contrôle d’un domaine par leur intermédiaire et ainsi se voir accorder un
certificat PKIX en prouvant son contrôle du domaine (possibilité de rediriger le domaine sur les serveurs DNS de l’attaquant), détourner le courrier électronique (modification
des enregistrements MX), ou les visiteurs d’un site web
(modification des enregistrements A ou AAAA), DANE
augmente la criticité de ces acteurs en les rendant responsable d’une partie du chemin de confiance permettant la
publication de certificat (enregistrements TLSA de type
2).
L’Histoire nous a prouvé par plusieurs fois que certains
de ces intermédiaires ne sont pas fiables (que ce soit au niveau technique [Dan08a, Utk11a, Utk11b, Mit11, Dan08b]
ou au niveau politique [udW11b, udW11a]).
7.3.3
La sécurité du dernier kilomètre
Par défaut, le canal entre un résolveur et le protorésolveur est non-sûr.
Il existe diverses méthodes pour le sécuriser.
– Avoir un résolveur local : Placer le résolveur/validateur sur la machine effectuant la requête
est le moyen le plus simple de "sécuriser" la communication entre le proto-résolveur et le résolveur, puisqu’aucune attaque MITM n’est possible (au moins
au niveau réseau). Cette solution n’est pas envisageable car elle implique que l’utilisateur lambda installe lui-même un résolveur sur sa machine 2 ;
– TSIG : Un secret est pré-partagé entre le protorésolveur et le résolveur. Celui-ci est utilisé pour
établir un canal chiffré entre eux. Cette approche
est irréaliste car seul le proto-résolveur par défaut
de GNU/Linux est actuellement capable d’utiliser
TSIG et de toute façon, le déploiement de secret
pré-partagé est impossible à grande échelle (sauf à
inclure le secret dans les box des FAI, ce qui revient
à faire confiance à son FAI et donc à son gouvernement (les FAI étant des sociétés privées soumises au
droit de leur pays)) ;
– SIG(0) : Le résolveur signerait ses réponses avec la
partie privée d’une paire de clés cryptographiques.
Le proto-résolveur, possesseur de la clé publique associée (obtenue par un autre canal), pourrait alors
vérifier la réponse du résolveur. Le conditionnel est
7.3.2 Les attaques contre les intermédiaires
utilisé car au 28 décembre 2011, aucune implémentaL’approche hiérarchique et centralisée du DNS (il
tion de SIG(0) dans un proto-résolveur ou un résoln’existe qu’une seule racine 1 ) place une très grande resveur n’existe, alors que la RFC est vieille d’au moins
ponsabilité et criticité dans les intermédiaires que sont la
une décénnie [3rd00].
1. Les racines alternatives n’ont jamais connu d’essor. Cela pourrait être amené à changer dans un futur proche [Bor11b].
2. Cette installation est cependant grandement automatisable et simplifiée grâce à des solutions telles que DNSSEC-trigger
12
– Techniques de sécurisation de niveau réseau : L’utilisation de Virtual Private Network (Réseau privé
virtuel) (VPN), tels que IPSec pourraient sécuriser
le canal entre proto-résolveurs et résolveurs. Dans la
pratique, ces technologies sont très lourdes à mettre
en place, et donc il est irréaliste d’imaginer que ces
solutions soient déployées pour sécuriser le dernier
kilomètre.
– Valider en local : Même sans avoir un résolveur local,
il est possible de valider en local la signature d’un
jeu d’enregistrements. Pour cela, l’application qui effectue les requêtes doit envoyer ses requêtes avec le
drapeau DO et valider par elle-même la signature.
Le module complémentaire "DNSSEC Validator" de
Firefox effectue par exemple cette validation. Cette
approche implique que chaque application embarque
une bibliothèque de validation (comme libunbound )
et l’utilise correctement, créant beaucoup de code
dupliqué et sensible. Si cette approche est fonctionnelle, elle est donc plus dangereuse.
De fait, la sécurisation du dernier kilomètre reste un
problème ouvert.
– La nécessité de la validation DNSSEC de bout-enbout est pour le moment bloquante puisqu’il n’existe
aucune solution standard et déployable à grande
échelle de sécurisation du dernier kilomètre.
– De nombreux proxy DNS (utilisés par exemple par
les portails captifs, dans les hôtels, bars, gares, aéroports, conférences, . . .) filtrent/cassent les réponses
DNSSEC jusqu’à ce qu’elles en deviennent invalides. Avec DANE, ces réponses invalides se transforment en DoS pour tous les services TLS. Le fait
est que le DoS est plus global puisqu’aucune validation DNSSEC n’est possible dans ce cas.
– L’impossibilité de révoquer explicitement un enregistrement ou un jeu d’enregistrements TLSA (ou une
signature DNSSEC [YOH+ 08]) représente un danger
dans le cas des enregistrements de type 2.
Le tableau n’est cependant pas aussi noir que pourrait
le laisser penser cette critique.
Tout d’abord, DANE est exploitable dans bien des cas
qui n’impliquent pas nécessairement un utilisateur lambda
(communication de serveurs à serveurs). Cela signifie que
la sécurisation du dernier kilomètre est plus facilement réalisable, et qu’il y a un risque moindre de voir les réponses
DNSSEC défigurées ("mangled, scrubbed").
7.4 Vulnérabilités de DANE aux attaques Ensuite, l’équipe de DANE envisage de travailler sur une
MITM
solution équivalente à l’OCSP-stapling pour DNSSEC :
DNSSEC-stapling. On peut cependant s’interroger sur le
La possibilité d’effectuer des attaques par rejeu est pro- bien fondé de l’idée de faire transiter des données DNSSEC
blématique pour DANE notamment vis-à-vis des enregis- à l’intérieur du protocole TLS en vue d’une validation
trements TLSA de type 2.
DANE.
Un rejeu d’un ancien jeu d’enregistrements TLSA de
type 0 ou 1 dont la signature est toujours valide, et contenant une clé compromise n’empire pas la sécurité du mo8 Conclusion
dèle, puisque la validation contre les CRL (ou via OCSP)
doit toujours être faite.
Bien que le besoin soit grand de remplacer ou compléEn revanche, un rejeu d’un enregistrement TLSA de type ter le modèle de sécurité actuellement en place (PKIX),
2 dont la signature est toujours valide et dont la paire aucune des solutions étudiées dans ce document ne réde clé associée est compromise est un véritable problème pond pour l’instant à tous les pré-requis nécessaires pour
puisqu’un attaquant est alors en mesure d’effectuer une voir son adoption immédiate par le grand public.
attaque MITM dont le certificat sera accepté sans avertisMalgré cela, Convergence est probablement la solution
sement, malgré la validation DANE et pire, à cause de
qui serait à privilégier.
DANE.
Son approche permettant d’externaliser la complexité de
validation de la légitimité d’un parti à des tiers permet
en effet de n’avoir à installer sur l’ordinateur d’un utili7.5 Conclusions sur DANE
sateur lambda qu’un unique outil : le client Convergence
Plusieurs points sont bloquants pour l’utilisation et (potentiellement intégré au navigateur). Quelque soit la
le déploiement de DANE tel qu’il est présenté dans le technologie qui sera à l’avenir utilisée pour remplacer ou
brouillon 13 de l’IETF [HS11] :
compléter PKIX, celle-ci sera abstraite sous la forme d’un
– Un nouveau type d’enregistrement est introduit : Notaire rendant un avis positif ou non. Cette abstraction
TLSA. L’Histoire nous a déjà montré qu’en matière permet même de faire confiance simultanément à plusieurs
de DNS, l’inertie était très forte et par plusieurs fois des technologies présentées dans ce document, ainsi qu’à
de nouveaux enregistrements ont mis plusieurs an- de futures encore à développer.
nées à être acceptés (s’ils ont finis par l’être) 1 .
DANE, abstrait par un Notaire, se libérera alors des
1. EDNS, par exemple, est encore indisponible sur certains réseaux bridant les réponses DNS à 512 octets maximum.
13
contraintes de déploiement lourdes dont il souffre actuel- non-révocabilité des signatures DNSSEC (puisqu’un attalement comme la sécurisation du dernier kilomètre lors quant devra alors empoisonner plusieurs Notaires DANE
de la validation DNSSEC. L’usage de plusieurs Notaires pour tromper un client).
DANE permettra également de contourner le problème de
9
Bibliographie
Références
[3rd00]
D. Eastlake 3rd. Rfc 2931 : Dns request and transaction signatures ( sig(0)s ). http://www.ietf.org/
rfc/rfc2931.txt, 2000.
[AA04]
D. Atkins and R. Austein. Rfc 3833 : Threat analysis of the domain name system (dns). http://www.
ietf.org/rfc/rfc3833.txt, 2004.
[Bar11]
R. Barnes. Rfc 6394 : Use cases and requirements for dns-based authentication of named entities (dane).
http://www.ietf.org/rfc/rfc6394.txt, 2011.
[Ber09]
Daniel J. Bernstein. Dns replay attacks. http://dnscurve.org/replays.html, 2009.
[Bor08]
Stéphane Bortzmeyer.
Comment fonctionne la faille kaminsky ?
comment-fonctionne-la-faille-kaminsky.html, 2008.
[Bor09]
Stéphane Bortzmeyer. Sécurité du dns et dnssec. https://2009.jres.org/planning_files/article/
pdf/5.pdf, 2009.
[Bor11a]
Stéphane Bortzmeyer. Des clés dans le dns, un successeur à x.509 ? http://www.bortzmeyer.org/
jres-dane-2011.html, 2011.
[Bor11b]
Stéphane Bortzmeyer. À quoi ressemblera la résolution de noms dans l’internet de demain ? http:
//www.bortzmeyer.org/resolution-de-demain.html, 2011.
[Com11]
Comodo. Comodo report of incident - comodo detected and thwarted an intrusion on 26-mar-2011.
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html, 2011.
[Dan08a]
Dancho Danchev. Hackers hijack dns records of high profile new zealand sites. http://m.zdnet.com/
blog/security/hackers-hijack-dns-records-of-high-profile-new-zealand-sites/3185, 2008.
[Dan08b]
Dancho Danchev.
How was comcast.net hijacked ?
how-was-comcastnet-hijacked/1224, 2008.
[Dis11]
Steve Dispensa. Do the major browsers implement crls ? (and if not, why not ?). http://www.quora.com/
Computer-Security/Do-the-major-browsers-implement-CRLs-And-if-not-why-not, 2011.
[Eck11a]
Peter Eckersley. How secure is https today ? how often is it attacked ? https://www.eff.org/deeplinks/
2011/10/how-secure-https-today, 2011.
[Eck11b]
Peter Eckersley.
Sovereign key cryptography for internet domains.
https://git.eff.org/?p=
sovereign-keys.git;a=blob_plain;f=sovereign-key-design.txt;hb=master, 2011.
[Eck11c]
Peter Eckersley. Sovereign keys : A proposal to make https and email more secure. https://www.eff.
org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure, 2011.
[FI11]
Fox-IT.
Diginotar certificate authority breach "operation black tulip".
http://www.
rijksoverheid.nl/ministeries/bzk/documenten-en-publicaties/rapporten/2011/09/05/
diginotar-public-report-version-1.html, 2011.
[Gar05]
Simson L. Garfinkel. Design principles and patterns for computer systems that are simultaneously secure
and usable. http://simson.net/thesis/, 2005.
[HS11]
P. Hoffman and J. Schlyter. Using secure dns to associate certificates with domain names for tls – draftietf-dane-protocol-13. http://www.ietf.org/id/draft-ietf-dane-protocol-13.txt, 2011.
[Jos06]
S. Josefsson. Rfc 4398 : Storing certificates in the domain name system (dns). http://www.ietf.org/
rfc/rfc4398.txt, 2006.
[JS04]
Ed. J. Schlyter. Rfc 3845 : Dns security (dnssec) nextsecure (nsec) rdata format. http://www.ietf.org/
rfc/rfc3845.txt, 2004.
14
http://www.bortzmeyer.org/
http://m.zdnet.com/blog/security/
[KGG+ 03] S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, and R. Hall. Rfc 3645 : Generic security service algorithm for secret key transaction authentication for dns (gss-tsig). http://www.ietf.org/rfc/rfc3645.
txt, 2003.
[Lan11a]
Adam Langley. Revocation doesn’t work. http://www.imperialviolet.org/2011/03/18/revocation.
html, 2011.
[Lan11b]
Adam Langley. Why not convergence ? http://www.imperialviolet.org/2011/09/07/convergence.
html, 2011.
[LL11]
Ben Laurie and Adam Langley. Certificate authority transparency and auditability. http://www.links.
org/files/CertificateAuthorityTransparencyandAuditability.pdf, 2011.
[LSAB08] B. Laurie, G. Sisson, R. Arends, and D. Blacka. Rfc 5155 : Dns security (dnssec) hashed authenticated
denial of existence. http://www.ietf.org/rfc/rfc5155.txt, 2008.
+
[MAM 99] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. Rfc 2560 : X.509 internet public key
infrastructure – online certificate status protocol - ocsp. http://www.ietf.org/rfc/rfc2560.txt, 1999.
[Mar11]
Moxie Marlinspike. Ssl and the future of authenticity. www.youtube.com/watch?v=Z7Wl2FW2TcA, 2011.
[Mic00]
Silvio Micali. Tree-based certificate revocation system. http://www.google.com/patents/US6097811,
2000.
[Mit11]
Stewart Mitchell. Sql injection blamed for widespread dns hack. http://www.pcpro.co.uk/news/
security/369700/sql-injection-blamed-for-widespread-dns-hack, 2011.
[Moz11]
Mozilla.
Revoking
trust
in
digicert
sdn
bhd
intermediate
certificate
authority.
http://blog.mozilla.com/security/2011/11/03/
revoking-trust-in-digicert-sdn-bhd-intermediate-certificate-authority/, 2011.
[Nig08]
Eddy Nigg. Untrusted certificates. https://blog.startcom.org/?p=145, 2008.
[Pal]
Chris Palmer.
It’s time to fix https.
https://docs.google.com/present/view?id=df9sn445_
188dhqktpcs.
[SEA+ 09] Joshua Sunshine, Serge Egelman, Hazim Almuhimedi, Neha Atri, and Lorrie Faith Cranor. Crying wolf :
An empirical study of ssl warning effectiveness. http://lorrie.cranor.org/pubs/sslwarnings.pdf,
2009.
[SG06]
J. Schlyter and W. Griffin. Rfc 4255 : Using dns to securely publish secure shell (ssh) key fingerprints.
http://www.ietf.org/rfc/rfc4255.txt, 2006.
[Sys]
Cisco Systems. Pki crl vs ocsp. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/
ps6586/ps6638/ps6664/product_data_sheet0900aecd80313df4.pdf.
[udW11a] Des utilisateurs de Wikipedia. Loi d’orientation et de programmation pour la performance de la sécurité intérieure. http://fr.wikipedia.org/wiki/Loi_d%27orientation_et_de_programmation_pour_
la_performance_de_la_s%C3%A9curit%C3%A9_int%C3%A9rieure#Filtrage, 2011.
[udW11b] Des utilisateurs de Wikipedia. Stop online piracy act. http://fr.wikipedia.org/wiki/Stop_Online_
Piracy_Act, 2011.
[Utk11a]
Utkarsh.
Domaining.com hacked.
http://dotsutra.com/domain-names/industry-news/
domaining-com-hacked/, 2011.
[Utk11b]
Utkarsh.
South korean domain registrar gabia hacked.
http://dotsutra.com/domain-names/
industry-news/south-korean-domain-registrar-gabia-hacked/, 2011.
[Vix99]
P. Vixie. Rfc 2671 : Extension mechanisms for dns (edns0). http://www.ietf.org/rfc/rfc2671.txt,
1999.
[YOH+ 08] He Yan, Eric Osterweil, Jon Hajdu, Jonas Acres, and Dan Massey. Limiting replay vulnerabilities in
dnssec. http://cs.ucla.edu/~eoster/doc/npsec_08-revocation.pdf, 2008.
[Zor11]
Zeljka Zorz. French certification authority reveals its private key by mistake. http://www.net-security.
org/secworld.php?id=11144, 2011.
[ZS09]
Michael Zusman and Alexander Sotirov. Sub-prime pki : Attacking extended validation ssl. http://
www.blackhat.com/presentations/bh-usa-09/ZUSMAN/BHUSA09-Zusman-AttackExtSSL-SLIDES.pdf,
2009.
15