RFC 6394 : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
Le projet #DANE (DNS-based Authentication of Named Entities), vise à améliorer et/ou remplacer les certificats #X.509 utilisés dans des protocoles comme #TLS. Ces certificats souffrent de plusieurs problèmes, le principal étant qu’une Autorité de Certification (AC) malhonnête ou piratée peut créer des certificats pour n’importe quelle entité, même si celle-ci n’est pas cliente de l’AC tricheuse. C’est ce qui s’est produit dans les affaires #Comodo et #DigiNotar et ces deux affaires ont sérieusement poussé aux progrès de DANE. Ce premier #RFC du groupe de travail DANE établit les scénarios d’usage : quels problèmes veut résoudre DANE et selon quels principes ?
#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
Excellent rapport d’analyse technique sur la plus grosse bavure qui ait jamais affecté les autorités de certification #X.509. Bonnes explications (malheureusement caviardées dans ce rapport public), notamment sur l’ampleur de l’attaque (le pirate a même réussi à générer des certificats dont le numéro de série n’a pas été enregistré dans la base : il n’a donc pas seulement pu créer des certificats, comme dans l’affaire #Comodo, mais aussi le faire sans qu’on puisse en garder trace).
On ne saura jamais combien d’iraniens ont été emprisonnés, voire tués, suite au piège qu’avait ensuite créé le gouvernement iranien.
Sur la faille Comodo, voir ►http://seenthis.net/messages/14461
Rogue SSL certs were also issued for CIA, MI6, Mossad
►http://www.net-security.org/secworld.php?id=11565
The number of rogue SSL certificates issued by Dutch CA DigiNotar has balooned from one to a couple dozen to over 250 to 531 in just a few days.
As Jacob Appelbaum of the Tor project shared the full list of the rogue certificates, it became clear that fraudulent certificates for domains of a number of intelligence agencies from around the world were also issued during the CA’s compromise - including the CIA, MI6 and Mossad.
Heu ... mais ... faut révoquer tous les certificats ou quoi ?
Parler de « SSL certificate » montre déjà que le journaliste n’a rien compris...
Sinon, oui, il faut révoquer tout #X.509.
Ah, le son du troll le soir au fond des bois... Lauren Weinstein est un vigoureux défenseur des droits et libertés sur l’Internet mais il fait parfois aussi des conneries, comme pour son projet IDONS, pur vaporware annoncé à grands renforts de trompettes mais qui, comme un autre vaporware (DNS-P2P) n’a rien produit.
►http://lauren.vortex.com/archive/000873.html
Ici, Weinstein s’attaque à #DANE (utiliser #DNSSEC pour distribuer des certificats, utilisables par exemple pour #TLS). Il a deux arguments : c’est un déplacement de pouvoir depuis les CA #X.509 vers la mafia du #DNS (pas faux). Et c’est vulnérable aux interventions du gouvernement états-unien (pas faux non plus).
Alors, quel est le problème ? C’est que Weinstein ne regarde pas les alternatives. Pourquoi parle-t-il de la mafia du DNS pour ICANN / registres / BE et pas pour les CA ? Les CA sont meilleurs ? Plus honnêtes ? Plus compétents ? Moins susceptibles d’obéir à un ordre légal de leur État ?
Bref, du pur FUD.
J’ai l’impression qu’il va y en avoir des articles, sur ce sujet des certificats cryptographiques mis dans le #DNS (et sécurisés avec #DNSSEC), dans les prochains mois.
L’#IETF a un groupe de travail sur le sujet, DANE ►http://tools.ietf.org/wg/dane
Cet article est plutôt pro #X.509. Pas la peine de me dire que leur argument sur l’#ICANN et les TLD est faiblard, c’est déjà fait (et très bien) dans les commentaires.
►http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
OVH et Gandi vendent des « certificats SSL ». Techniquement le nom est peut-être pas le bon, mais on se comprend :-)
Pouvoir envoyer le couple login/passwd de manière chiffrée sur le réseau est le minimum. Et quand on a un site tout web2.0 qui peut participer à faire chuter des régimes politiques, le chiffrement est indispensable.
Mais je sais, la sécurité est la grande oubliée du développement Internet de ces dernières années (X.509 semble le confirmer d’ailleurs)
#seenthis a déjà du SSL qui fonctionne, pas besoin que ça soit validé par une entreprise pas fiable pour que ça soit « vraiment » un « bon » certificat.
Le certificat actuel génère une erreur, les geeks s’en contentent, mais il y a bien qu’eux. En plus, c’est à moi de forcer le HTTPS. En 2011, le minimum est d’avoir HTTPS pour login/passwd.
Le pire est que je suis sûr que vous devez adhérer à l’initiative HTTPS Everywhere.
Oui l’action du formulaire de login devrait être en HTTPS.
Le certificat ne génère pas d’erreur, il génère un dialogue d’information qui demande à accepter ou refuser le certificat selon si tu lui fait confiance ou non.
Je te conseille l’extension MonkeySphere (et CertPatrol) pour Firefox pour aider ce travail de confiance (ça se base sur ton cercle de confiance GPG/PGP, bien plus fiable qu’une signature d’une entreprise qui ne vérifie rien à part que la transaction a bien été payée...).
Sinon tu peux aussi faire comme les gens un peu sérieux : effacer les certificats des entreprises « officielles » de ton navigateur/OS afin de vérifier chaque certificat, ainsi tu verra que SeenThis n’est pas différent des millions d’autres sites utilisant TLS ;)
Juste pour dire que je suis tout à fait d’accord avec @bohwaz. C’est pour cela que je pinaillais sur la différence entre TLS et X.509. TLS est très bien et SeenThis devrait l’utiliser davantage. C’est X.509 le problème.
Etant en https, en cliquant sur « Seenthis » ou « Accueil », on passe en http. #seenthis_bug @seenthis
pareil, quand on veut récupérer son mot de passe (ou vouloir en changer), on repasse en http. #seenthis_bug
RFC 6125 : Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using #X.509 (PKIX) Certificates in the Context of Transport Layer Security (#TLS)
Un RFC long et complexe pour un problème difficile. En résumant violemment, il s’agit de savoir quelle identité utiliser lorsqu’un client TLS s’assure de l’authenticité du serveur auquel il se connecte. Par exemple, si un MTA veut transmettre du courrier à bill@example.com, que doit contenir le certificat X.509 du MX d’example.com pour que l’authentification réussisse ? example.com ? D’autres noms, plus spécifiques à ce service, sont-ils possibles ? Comme de nombreux autres protocoles ont des problèmes de ce genre, l’idée avait germé de faire un RFC générique, définissant un cadre et des principes, RFC que les protocoles n’auraient plus qu’à citer. C’est notre RFC 6125.
Un article de Rue89 sur la complicité de #Microsoft dans les piratages de Facebook et de Gmail effectués par la dictature de Ben Ali : pa►http://www.rue89.com/2011/03/18/tunisie-microsoft-complice-de-la-censure-numerique-par-ben-ali-195693
L’article de Rue89 n’a pas été relu par un expert. Il est bourré d’erreurs et Microsoft a beau jeu de les relever : ►http://www.microsoft.com/france/espace-presse/evenements/tribune.aspx
Et les remarques de Microsoft sont quasiment toutes correctes. Pas facile de faire du journalisme sérieux, la moindre des choses est de faire vérifier par quelqu’un qui connait.
Quelques bons articles sur la faille « Comodo » (une autorité de certification #X.509 qui laisse un de ses revendeurs émettre de vrais-faux certificats pour des sites sensibles comme addons.mozilla.org, un site qui est utilisé pour les mises à jour automatiques de Firefox).
Le meilleur article technique est celui du projet Tor : ►https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusi
Une synthèse non-technique pas trop mauvaise : ►http://www.zdnet.com/blog/security/microsoft-warns-fraudulent-digital-certificates-issued-for-high-value-websites/8488
Le message officiel de Mozilla, dont les logiciels ont désormais en interne une liste noire de certificats frauduleux : ►http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates
Le communiqué officiel de Comodo : ►http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
Contrairement à ce que dit ce communiqué, l’exploitation ne nécessite pas le #DNS : ►https://listes.cru.fr/sympa/arc/dns-fr/2011-03/msg00047.html
Comodo se vante que les vrais-faux certificats aient été annulés mais personne ne teste les révocations : ►http://www.imperialviolet.org/2011/03/18/revocation.html
Le craqueur (oui, c’est probablement lui) a expliqué comment il avait
fait : ►http://pastebin.com/74KXCaEZ
Et une très bonne analyse non-technique de la sécurité est en : ►http://erratasec.blogspot.com/2011/03/comodo-hacker-releases-his-manifesto.html
L’étude de l’#EFF montrant que la plupart des autorités de
certification signent n’importe quoi : ►http://www.macworld.co.uk/business/news/index.cfm?newsid=3273112&pagtype=allchandate
Il y a aussi des mauvais articles (comme celui de Wired), je ne les cite pas.
@fil a référencé un article de l’EFF :
►http://seenthis.net/messages/14438
Iranian hackers obtain fraudulent HTTPS certificates: How close to a Web security meltdown did we get? | Electronic Frontier Foundation
►https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https
improperly issued certs, which were for extremely high-value domains including google.com, login.yahoo.com and addons.mozilla.org (this last domain could be used to trojan any system that was installing a new Firefox extension, though updates to previously installed extensions have a second layer of protection from XPI signatures). One cert was for “global trustee” — not a domain name. That was probably a malicious CA certificate that could be used to flawlessly impersonate any domain on the Web.
Comodo also said that the attack came primarily from Iranian IP addresses, and that one of the fraudulent login.yahoo.com certs was briefly deployed on a webserver in Iran.1
#X.509 (mauvaise technologie, à jeter en bloc).