L'Electronic Frontier Foundation (EFF), qui défend la liberté d'expression sur Internet, a publié hier un article concernant l'attaque Man-in-the-middle contre les utilisateurs de Google en Iran, qui a eu lieu en douce pendant deux mois.
Une nouvelle fois, la vulnérabilité des systèmes de chiffrement sur le web basés sur des autorités de certification est mis en lumière : encore une fois l'attaquant a obtenu un certificat frauduleux d'une autorité (cette fois-ci DigiNotar). L'attaque a été détectée via le navigateur Google Chrome car celui-ci embarque en dur des vérifications pour les certificats de Google.
Pour mémoire je vous rappelle les deux entrées dans l'aide du site LinuxFr.org concernant le certificat SSL/TLS de LinuxFr.org et alertes dans les navigateurs et la réponse à la question Pourquoi ne prenez pas un certificat SSL/TLS gratuit ou payant de chez Machin qui est par défaut dans un navigateur ? Ce dernier lien comporte notamment des pointeurs vers des affaires précédentes autour des certificats SSL/TLS et des autorités de confiance (Comodo, Microsoft et Tunisie, Defcon 2010, CCC 2010, Verisign 2003/2004).
Aller plus loin
- Iranian Man-in-the-Middle Attack Against Google Demonstrates Dangerous Weakness of Certificate Autho (124 clics)
- Observatoire SSL de l'EFF (70 clics)
- Mozilla Security : DigiNotar retiré des autorités de confiance chez Mozilla (131 clics)
- Certificat SSL/TLS de LinuxFr.org et alertes dans les navigateurs (99 clics)
- Pourquoi LinuxFr.org ne prend pas un certificat SSL/TLS gratuit ou payant de chez Machin qui est par (223 clics)
- Blog Orange Sécurité : Un certificat SSL frauduleux pour *.google.com (90 clics)
- Clubic : Google met en garde contre de nouveaux certificats SSL frauduleux (62 clics)
# boucler la boucle ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
Au lieu d'avoir une chaine de confiance, n'est-il pas possible de faire une boucle ? En gros, que le site web envoie un js ou que le navigateur envoie des informations au serveur pour vérifier le certificat ?
"La première sécurité est la liberté"
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Lapin compris.
Aucun intérêt : si le serveur n'est déjà pas le bon mais celui d'un intercepteur, il répondra sans aucun doute ce que ton navigateur attend.
[^] # Re: boucler la boucle ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
Le site web peut envoyer du code JavaScript à faire exécuter sur le navigateur web pour un affichage avec un warning, ou bien le JS peut renvoyer les informations vers le site web.
Pour éviter l'attaque MiM, il faudrait que la réécriture ne soit pas trivial du tout, ou très couteuse en temps de calculs (genre 1000 tours de SHA-2 comme CRC).
"La première sécurité est la liberté"
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Bah, l'attaquant n'aurait qu'à remplacer ce code JavaScript par du rien…
Il ne faut pas compter sur le contenu transmis pour garantir quoi que ce soit, puisque ce contenu n'est garanti que s'il n'y a pas d'attaque.
[^] # Re: boucler la boucle ?
Posté par oinkoink_daotter . Évalué à 2.
A la CA, en fait.
C'est le but d'OSCP et des CRL : vérifier avant utilisation qu'un certificat n'a pas été révoqué !
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Acronym overflow.
[^] # Re: boucler la boucle ?
Posté par oinkoink_daotter . Évalué à 4.
Ok, reprenons.
Il y a déjà des mécanismes embarqués dans le navigateur inter^W web qui permettent de vérifier si un certificat est valide :
- les CRL (certificate revocation list) qui sont des listes signées par les autorités de certification contenant les certificats révoqués. Normalement l'URL ou aller la chercher est embarquée dans le certificat.
- OSCP qui permet au brouteur d'aller interroger une autorité de certification sur la validité d'un certificat qu'elle a généré(quand c'est bien implémenté, ie: pas de réponse "ok vazy" = problème).
Normalement quand le brouteur n'arrive pas à faire la vérification d'un certificat, il ne devrait pas laisser l'accès au site.
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Très bien, sauf que ces mécanismes ne répondent absolument pas au problème principal de sécurité, qui est la corruption d'une autorité de certification, qui est présenté ici.
[^] # Re: boucler la boucle ?
Posté par oinkoink_daotter . Évalué à 1.
Non, mais ça montre qu'il y a des solutions techniques qui existent pour limiter la casse quand on s'en rend compte.
A part rentrer à la main toutes les clefs publiques en vérifiant toutes les empreintes dans ton magasin de clef, tu ne pourras pas éviter le problème du tiers de confiance qui merde (la CA, le brouteur, ton pote qui te refile une clef "de confiance", etc). Et je ne vois pas comment faire autrement avec une solution qui "scale" (ie qui marche out of the box à l'échelle d'Internet/Web).
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Un réseau de confiance à la PGP ?
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Pour ceux qui opposeraient qu'un réseau de confiance est trop compliqué à construire, je rappellerai que de tels systèmes n'ont rien de moins que le système pyramidal X.509, mais uniquement une caractéristique de *plus* : la possibilité d'avoir plusieurs signatures sur un certificat.
Par conséquent, un système de réseau de confiance permet de faire tout ce qu'un modèle pyramidal permet. En particulier, il est tout à fait possible d'implémenter un modèle pyramidal ou hybride à partir d'un système de réseau de confiance.
[^] # Re: boucler la boucle ?
Posté par syntaxerror . Évalué à 1.
C'est le but du projet "perspectives" http://perspectives-project.org/
Au lieu de faire confiance à la CA, le certificat est validé par un contrôle de vraisemblance au cours du temps, de manière décentralisée.
Petit inconvénient, l'extension firefox ne cohabite pas bien avec certpatrol (http://patrol.psyced.org/) qui permet de détecter les changements de certificats.
[^] # Re: boucler la boucle ?
Posté par lamiricore . Évalué à 3.
Un AO quoi!
[^] # CACert et sa CRL
Posté par Antoine . Évalué à 3.
Anecdote intéressante, la CRL de CACert fait plus de 4 Mo, ce qui rendrait son utilisation plutôt acrobatique dans le cadre d'un client interactif (type navigateur Web) :
(quant à TUNIX-httpscreen, je ne connais pas et le site http://www.tunix.nl/ semble uniquement en néerlandais...)
[^] # Re: CACert et sa CRL
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Ce qui pose d'ailleurs souci avec Opera, car le fichier n'est pas caché très longtemps (quelques minutes) et se rendre sur un site signé par CACert occasionne le téléchargement complet de la liste à nouveau, et le site n'est pas affiché avant ça, soit ~15-20 secondes de latence à chaque site rencontré, horrible.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: CACert et sa CRL
Posté par Larry Cow . Évalué à 2.
C'est tout le dilemme de la révocation de certificats SSL. Soit on met souvent à jour la liste de révocation, et on fait chier le monde (d'autant plus que la liste augmente en taille). Soit on met à jour plus rarement, et on encourt le risque d'une fuite exploitée entre temps.
Et ce n'est pas vraiment mieux avec OCSP (le protocole de vérification de validité), puisqu'il suffit à l'attaquant de rendre le serveur OCSP inaccessible pour que le client se rabatte sur la dernière info connue.
Une solution (chiante) est de délivrer des certificats pour une courte durée, ce qui fait qu'ils n'encombrent pas les CRLs trop longtemps en cas de pépin (ils deviennent vite invalides rien que par la date). Ou d'en délivrer peu. Bref, rien de très compatible avec le modèle actuel, qui encourage très peu de très gros opérateurs.
[^] # Re: CACert et sa CRL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais si tes certificats sont souvent changé, dans un mode décentralisé, il y a aura peu de "contre-signature", non ?
"La première sécurité est la liberté"
[^] # Re: boucler la boucle ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Un « web of trust » à la GPG donc ? Le contraire d'un système centralisé à base d'autorité(s) de confiance.
[^] # Re: boucler la boucle ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Plutôt un deuxième canal de vérification du certificat par le code HTML.
"La première sécurité est la liberté"
[^] # Re: boucler la boucle ?
Posté par oinkoink_daotter . Évalué à 2.
J'ai un peu de mal à comprendre le principe, en fait. Si tu as un gars qui fait du MITM, comment pourras-tu garantir que ton canal de vérification est intègre ? Si tu peux faire le calcul attendu, hors éléments secrets, je ne vois pas ce qui pourrait empêcher ton attaquant de renvoyer les bonnes valeurs (à toi, ou au serveur) ...
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Pire : l'attaquant peut tout simplement faire sauter le code de vérification, c'est beaucoup plus simple.
[^] # Re: boucler la boucle ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Monkeysphere. Dommage qu'il nécessite de laisser tourner un agent Monkeysphere.
# Un autre lien
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Un article qui analyse les problèmes du modèle SSL : http://lair.fifthhorseman.net/~dkg/tls-centralization/
[^] # Re: Un autre lien
Posté par Pseudo007 . Évalué à 2.
Je ne vois pas où est la critique du modèle SSL (Secure Sockets Layer).
# Mises à jour Debian
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Debian vient aussi de retirer l'autorité de certification DigiNotar de ses paquets ca-certificates (Debian Security Advisory DSA-2299-1) et nss (DSA 2300).
[^] # Re: Mises à jour Debian
Posté par claudex . Évalué à 2.
D'après Wikipédia ( http://en.wikipedia.org/wiki/Diginotar ), Mozilla, Microsoft et Google l'ont aussi retiré. Mais on apprend aussi qu'il s'agit de l'autorité de certification du gouvernement néérlandais, notamment pour les impôts en ligne (Mozilla a whitelister les certificats du gouvernement à sa demande, mais il n'est pas sûr qu'ils n'aient pas été compromis).
Petite anecdote, le site web est attaqué avec succès depuis 2009 par des pirates turques et iraniens.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mises à jour Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ce qui est amusant, avec ces autorités nationales, c'est qu'elles donnent aux États la possibilité d'émettre pour leur propre usage des certificats usurpant l'identité d'autres acteurs. Autrement dit, de jour à l'homme du milieu sans que cela puisse être détecté par les utilisateurs. Mais après tout, les autorités de certification privées ont aussi ce pouvoir… :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.