Firefox 3 et les certificats auto-signés
Un article de Frenchmozilla.
Sommaire |
Firefox 3 et les certificats auto-signés
Version 1.0 - 05-09-2008
Il y a eu récemment (durant l'été 2008), beaucoup de discussions à propos des avertissements de Firefox 3 sur les certificats SSL qui sont invalides ou non signés par une autorité connue (« auto-signés »). Il y a eu des commentaires, offrant différents niveaux de soutien ou de critiques, de Lauren Weinstein, Robert Accettura, Slashdot (deux fois), PC World, Nat Tuck, BetaNews et Pingdom. J'ai également eu une discussion similaire et très enflammée lors d'un dîner au State of the Map 2008. Les gens sont également soupçonneux sur les motivations derrière la reconnaissance des certificats EV par Firefox 3.
Cette page explique pourquoi l'interface utilisateur SSL de Firefox 3 a été conçue ainsi, et pourquoi nous pensons que c'est une bonne chose.
Sécurité = Chiffrement * Authentification
Avant de commencer, nous devons comprendre que Sécurité = Chiffrement * Authentification. Un très bon chiffrement * aucune authentification = aucune sécurité. Ceci est un point absolument crucial qui malheureusement n'a pas été pris en compte dans le débat. Il n'y a aucun intérêt à chiffrer vos données avec une clé secrète si vous ne savez pas à qui elle est ni à qui vous l'envoyez. C'est le principe pour une attaque de type « Man in the Middle attack ». Lauren Weinstein a dit :
Mais dans beaucoup de situations, nous ne sommes pas concernés par l'identité en particulier, nous voulons juste avoir le flux cryptographique https: de base actif et fonctionnel.
Mais il n'existe pas de telles situations. Si vous ne savez pas à qui vous parlez, alors le chiffrement est inutile car vous pourriez parler à l'attaquant. (Les certificats auto-signés vous fournissent en fait des moyens pour savoir à qui vous parlez, mais de façon limitée, et nous aborderons ce sujet). Si vous ne faites rien pour vérifier que votre interlocuteur est bien celui que vous croyez ou si vous faites les mauvaises vérifications, alors tout ce chiffrement est une perte de temps.
Certains affirment qu'ajouter le chiffrement, même sans authentification, élève la difficulté en empêchant l'analyse basique des paquets (packet sniffing). Nat Tuck dit :
Espionner une connexion (c-à-d. une liaison sans fil) est bien plus facile que n'importe quelle attaque par usurpation d'identité qu'empêche l'authentification SSL.
Quoi qu'il en soit, ce n'est tout simplement plus vrai. La nouvelle barrière est encore au niveau pointer et cliquer. Les attaques MITM (Man in the middle) sont aussi faciles que ça de nos jours. Pour plus de détails sur cette simplicité, consulter le billet du blog de johnath.
Donc une certaine authentification est requise. Mais de quel ordre ? Regardons trois cas de connexion sécurisée sur le Web. Ils sont classés par ordre décroissant de force d'authentification :
- Vous voulez savoir à quelle organisation vous vous adressez.
- Vous voulez savoir si vous êtes connecté sur le bon nom de domaine.
- Vous voulez savoir si vous pouvez vous connecter de façon répétée vers la même personne ou le même emplacement.
1 : Identité organisationnelle forte
Le scénario 1 s'applique pour les banques ou le commerce en ligne. Plutôt que d'avoir à se souvenir que http://www.bankofamerica.com/ est « Bank of America », alors que http://www.bank-of-america.com/ ne l'est pas, Monsieur Toutlemonde préfère de loin que son navigateur lui dise « Bank of America, Inc. (US) » pour supprimer tout doute. Monsieur Toutlemonde voudrait savoir que quelqu'un a effectivement disparu et être sûr que seule la vraie « Bank of America » des États-Unis peut obtenir un certificat qui dise cela, et s'il est escroqué, que quelqu'un sait où envoyer la police.
C'est, en résumé, ce que les certificats EV (Extended Validation) fournissent. Maintenant, d'autres on dit que c'était ce qu'auraient dû faire les CA (Autorités de certification) depuis toujours, et comment se fait-il qu'elles obtiennent de faire payer maintenant ? Même après avoir noté que les certificats DV (Domain Validated) ne sont pas suffisants, Robert Accettura affirme encore :
Essentiellement, les certificats EV ne sont rien de plus qu'un moyen de faire payer plus. Les certificats EV SSL sont supposés faire ce qu'un certificat signé aurait toujours dû faire.
Cette seconde phrase peut être vraie, bien que l'on puisse argumenter sur la responsabilité de la situation sur le marché des certificats avant les certificats EV. Pendant longtemps, les certificats avec très peu de vérification ressemblaient dans l'interface utilisateur du navigateur à ceux ayant une bonne vérification. Donc, tous les moyens étaient bons pour faire moins de vérification. Mais alors, aucune différenciation dans l'interface utilisateur n'était possible, parce qu'il n'y avait pas de standard indépendant pour définir ce qu'une « bonne vérification » voulait dire. Il y a eu des fautes des deux côtés.
Les prix pour les certificats standards de validation de domaines sont maintenant bas au point d'être réduits à zéro (et à ce prix-là, vous n'avez pas de vérification d'identité du tout). Les certificats EV coûtent cher car les CA font toutes les vérifications définies dans ce document (PDF), et sont auditées pour s'assurer qu'elles le font. Si vous pensez que les certificats EV n'ajoutent pas de protections supplémentaires, dites-nous comment les fraudeurs peuvent passer au travers de ces vérifications. Nous avons aidé à l'écriture de ce standard, et nous corrigerons tout ce qui ne va pas.
Nous pensons que les certificats EV nous donnent un identifiant organisationnel humainement lisible dans l'interface utilisateur du navigateur avec une grande fiabilité sur son authenticité. Il n'existe pas d'autres moyens techniques d'obtenir cette sorte d'identifiant dont on puisse être sûr. Et nous pensons que c'est utile pour aider les gens à connaître l'identité des personnes à qui ils parlent. C'est ce que fournissent les certificats EV : une identité authentifiée.
2 : Vérification de domaine
Le scénario 2 s'applique aux systèmes de messagerie en ligne par exemple. Votre adresse électronique est fred@monfaimail.com, vous voulez donc savoir que vous êtes sur monfaimail.com, et vous voulez du chiffrement, mais vous n'avez pas particulièrement besoin qu'on vous dise qui détient monfaimail.com : vous savez que c'est MonFAI.
Une chose importante à noter est que DNS (Domain Name System)
n'est pas sécurisé : il peut être usurpé, comme Dan Kaminsky l'a récemment démontré. (Dan a quelques [http://www.doxpara.com/?p=1231 pensées intéressantes] sur l'interaction entre les failles DNS et les failles des certificats. Son résumé en une ligne : « une authentification faible conduit au pwnage »). DNSSEC a encore du chemin à faire, et jusqu'à ce qu'il arrive, vous ne pouvez pas avoir la certitude que l'adresse IP que le DNS renvoie quand vous cherchez « monfaimail.com » est correcte. Vous pourriez être envoyé n'importe où. Les certificats SSL d'un tiers de confiance sont le seul moyen de vous assurer que vous êtes vraiment connecté au site que vous avez demandé. C'est le service que vous obtenez avec les certificats DV. Il n'est pas nécessaire que cela vous coûte quelque chose. Les fournisseurs suivants fournissent des certificats gratuits<a name="point1" href="#note1 1] :
- StartCom (Une année de validité, bien que seuls les navigateurs basés sur Gecko et WebKit les reconnaissent)
- Comodo (90 jours de validité)
- Thawte (21 jours de validité)
Sinon, des certificats d'un an de validité reconnus par tous les navigateurs peuvent être ajoutés moyennant la modique somme de 14,99 $ chez certains vendeurs.
Dans un monde idéal, la certitude d'être connecté sur le bon site serait quelque chose qu'Internet devrait fournir gratuitement. DNS a été conçu à une époque où les gens ne pensaient pas que des personnes mal intentionnées essaieraient de le subvertir, et le bon correctif n'a pas encore été déployé. Jusque-là, selon moi, moins de 15 $ par an (ou gratuitement) n'est pas une somme exorbitante à payer pour combler le trou de sécurité.
[Aparté : si l'appartenance de domaine est validée en envoyant un courriel à un contact du domaine, alors ce type de certificat pourrait être obtenu par un attaquant capable de contrôler le DNS de l'autorité de certification ou de le router par des méthodes semblables à celle de Kaminsky, BGP ou des attaques similaires (car elles peuvent intercepter le courriel). Donc, en fait, d'une certaine façon, la sécurité de tels certificats repose sur la sécurité du DNS. Ce qui est inquiétant.]
3 : Répétition de connexion
Le scénario 3 s'applique quand vous voulez avoir l'assurance d'être connecté à la même personne que celle avec qui vous étiez connecté auparavant.
C'est ici que les supporters des certificats auto-signés interviennent. Ils disent souvent : « 14,95 $ c'est encore trop cher. Pourquoi ne puis-je pas signer moi-même mon certificat ? ». Frank souligne que cette forme de l'argument est un non sequitur. La sécurité ou les certificats auto-signés ne sont pas liés au coût des certificats des CA. Mais nous devrions quand même corriger ce problème.
Nous avons déjà établi que si vous n'avez pas d'authentification, vous n'avez pas de sécurité. Les certificats auto-signés fournissent une authentification non nulle si vous faites ce qui suit :
- Confirmez l'empreinte numérique de la clé hors réseau (c-à-d. pas par le Web) à la première connexion.
- Assurez-vous que c'est toujours la même ensuite (le logiciel fait normalement cela pour vous automatiquement).
- Confirmez à nouveau la nouvelle empreinte numérique hors réseau si la clé change.
Si vous faites ces trois choses, vous obtenez une répétition de connexion sécurisée vers tout correspondant contacté hors réseau dans l'étape 1).
En-dehors du fait que cela ne dérange pas beaucoup de gens qui utilisent ce modèle pour SSH de faire l'étape 1, mais en pratique disent juste « OK » et croisent les doigts, nous pensons que personne n'a encore fourni d'interface utilisateur qui rende ce modèle cryptographique (connu sous le terme de Gestion de la continuité de clé - KCM - ou « le modèle SSH ») compréhensible par Monsieur Toutlemonde. Vous ne pouvez pas lui fournir une chaîne de caractères en hexadécimal et vous attendre à ce qu’il la communique par téléphone à sa banque. À la place, il a juste à cliquer sur OK, qui devrait être intitulé – Ouais, peu importe – et espérer que tout aille pour le mieux. La même chose survient lorsqu’il a l’alerte « clé modifiée » même si cela en effraie plus d’un.
La chose primordiale à noter à propos de ce modèle est que le changement de clés fait partie de la vie. Personne n’utilise ou ne devrait utiliser la même clé toute sa vie, une clé compromise ou avérée faible entraîne un changement de clé. L’utilisateur est donc sujet à recevoir sans cesse des alertes, certaines indiquant une situation « OK » , et certaines une situation dangereuse. Nous sommes sûrs qu’aucune interface utilisateur ne pourrait guider Monsieur Toutlemonde à travers cette complexité en toute sécurité.
La recherche ergonomique nous dit que répéter des boîtes de dialogues et des alertes habitue les utilisateurs à cliquer juste sur « ok » - c’est encore le truc « Ouais peu importe ». Si cette boîte de dialogue indique généralement une chose mineure, elle peut néanmoins parfois indiquer une situation dangereuse, ce qui aggrave le problème. Cela peut arriver quel que soit le dialogue affiché par la boîte. Les dessinateurs d’interface utilisateur peuvent travailler pendant un an sur le phrasé, mais qu’importe, il sera finalement et simplement ignoré.
Deuxièmement, il n’existe pas de protection contre les clés compromises. Si quelqu’un s’approprie votre clé privée, il peut se faire passer pour vous à volonté – Et vous ne pourrez rien y faire. La petite histoire de la révocation des certificats SSL a été très pauvre par le passé pour des raisons de licence et de performance, mais cela est en passe de changer avec l’avènement de OCSP, qui sera nécessaire aux certificats EV à partir de 2010. Le problème de clé compromise n’est pas seulement théorique – Presque toutes les clés SSL générées sur les systèmes Debian 18 mois avant mai 2008 sont totalement compromises, en raison d'une faille dans le générateur de nombres aléatoires. Ceux qui attaquent peuvent récupérer la clé privée s’ils connaissent la clé publique.
Il y a aussi un problème de protection de la vie privée – le navigateur doit garder la liste des sites SSL visités (à moins que vous ne vouliez davantage d’alertes sur le changement de certificat) et ne peut pas la nettoyer quand on vide l’historique, etc.
Vous vous dites « OK, ce modèle n’est pas pour Mme Michu. Mais pourquoi ne serais-je pas capable de l’utiliser ? Je comprends les risques. Je promets de confirmer mon empreinte numérique de manière confidentielle à chaque nouvelle connexion ou changement de clé. Vraiment je le promets ».
Le problème majeur ici, qui ne sera jamais assez souligné, est que tant que cela n’est un désir raisonnable que dans une (très petite) communauté de geeks comme nous, nous n’avons pas pu trouver un moyen de rendre cela plus simple pour les geeks que d’utiliser le modèle KCM sans exposer aux risques tous les gens qui utilisent toujours le modèle standard. Les alertes de changement de certificat qui sont monnaie courante dans KCM indiquent une attaque dans un usage normal de SSL. Nous ne voulons pas minimiser le caractère sérieux des alertes qui protègent les utilisateurs en usage normal, ni même la difficulté de les outrepasser.
Qu’en est-il des intranets ? Pourquoi devraient-ils payer ? Il y a deux solutions possibles. La première est d’installer le fichier racine de l’entreprise dans le navigateur. Tout le monde peut le faire ou le service informatique peut utiliser le Client Customizability Kit (CCK) pour créer un Firefox personnalisé – et si Firefox 3 n’est pas supporté par le CCK, il le doit.
Cependant, lancer sa propre certification possède ses propres coûts cachés – que vous découvrez normalement après une clé compromise quand vous devez mettre à jour tous les certificats en une seule fois, et chacun doit apprendre beaucoup de choses sur la cryptographie extrêmement rapidement. Une solution plus simple serait de budgéter quelques petites dépenses de 14,95 $ ou autre, et utiliser le même système de certification que tous les autres utilisent.
Conclusion
Ce problème n’est aussi simple qu’il y paraît. Nous avons beaucoup réfléchi sur ce qui est possible et sécurisé, et ce qui ne l’est pas. Comme tout ce que Mozilla fait, ceci est guidé par le désir de protéger nos utilisateurs et non pas une envie de faire acheter aux gens des certificats SSL (Pourquoi serait-ce un but ?). Nous sommes ouverts à toute suggestion, mais pensons que l’interface utilisateur actuelle est un bon compromis.
Section Bonus : Slashdot Myths Rebuttal
Tout ce qui suit sont des citations ou des idées (traduites) de Slashdot comments.
- Tout certificat peut être compromis en quelques secondes après son émission, […] par conséquent, les certificats n’assurent pas qu’on soit connecté à l’URL indiquée.</dt>
- Un certificat peut être compromis « en quelques secondes après son émission » si par exemple votre site Internet a déjà été piraté lors de son installation – dans ce cas vous avez des problèmes plus graves. Même en prenant en compte cette rare éventualité, la seconde déclaration est seulement vraie s’il n’y a pas d’annulation. En d’autres termes, cela s’avère pour les certificats auto-signés mais pas par exemple pour les certificats EV.</dd>
- Les certifications qui ne coûtent rien ne peuvent pas du tout assurer l’identité.
Beaucoup d’entreprises choisissent d’offrir des services particuliers, qui ont un coût non nul associé, pour des des raisons commerciales.</dd>
- Verisign est un monopole. Les 100 certifications dans Firefox sont des monopoles</dt>
- C’est quelque peu auto-réfutant. Cela dépend de comment vous comptez, il y a plus de 40 certificats différents dans le magasin racine de Firefox, dont beaucoup se trouvent aussi dans les magasins racines des autres navigateurs. Ils fournissent des certificats et des services à un large éventail de prix.</dd>
- En vous opposant aux certificats auto-signés, vous prouvez que vous êtes en faveur du monopole de Verisign</dt>
- Verisign n’a pas un monopole (voir ci-dessus). Cet argument est une sorte d’empoisonnement du puits.</dd>
- Les certificats auto-signés fournissent une meilleure identification qu’aucun autre certificat SSL</dt>
- Un mauvais sens de la sécurité est pire que pas de sécurité du tout.</dd>
- Les certificats coûtent au moins 100 $ par an, les coûts liés à la certification sont faramineux</dt>
- Voir le texte principal. En fait pour beaucoup de personnes ou d’organisations, 100 $ est une limite supérieure à la normale car, à ce prix-là, vous pouvez obtenir un certificat « wildcard » pour autant de sites que vous le souhaitez dans un même domaine.</dd>
- Les certificats chaînés sont inférieurs à ceux émis par le certificat racine.</dt>
- Les certificats chaînés signifient que la certification n’utilise pas leur certificat racine embarqué directement pour la signature, ce qui signifie qu’ils peuvent l’avoir enfermé dans un endroit en sécurité et inaccessible. Par conséquent, les certificats qui sont chaînés sont d’autant plus sûrs. </dd>
- L'autorité de certification soudoie Mozilla pour qu’il mette leur certificat dans Firefox</dt>
- Mozilla ne sollicite ni n’accepte de paiement pour des inclusions dans le magasin racine.</dd>
- Aucun certificat ne fournit une réelle assurance car chacun peut acquérir une certification pour n'importe quelle organisation ou nom de domaine</dt>
- Personne ne devrait pouvoir acquérir un certificat pour un nom de domaine qu’il ne contrôle pas (à moins de les auto-signer). Si vous avez la preuve qu’ils le peuvent, montrez-la. Les certificats EV ne vérifient pas le champ O (Organisation), mais Firefox ne montre pas ce champ dans l’interface utilisateur pour de tels certificats, donc c’est OK.</dd>
- Verisign est une escroquerie car certains ont signé des logiciels malveillants avec du code authentique certifié par Verisign.</dt>
- Les certificats concernent l’identité, pas la vertu.</dd>
- CACert est la seule certification gratuite</dt>
- Voir texte principal.</dd>
- La certification ne fait rien de mieux que ce que ne fait OpenSSL, ce qu’on peut faire nous-mêmes gratuitement.</dt>
- Allez faire un tour sur WebTrust Principles and Criteria pour avoir une idée des niveaux d’intégrité et de sécurité que les systèmes de certification doivent passer.</dd>
<a name="note1" href="#point1">1</a> Et que dit CAcert ? La seule position de CAcert est d’avoir demandé à Mozilla d'être très adaptatif de manière à ce qu'ils puissent s'adapter à nos procédures. Ils n’ont pas encore la vérification « juste mais ferme » que nous demandons mais l’état avancement se trouve ici. (Notez qu'un article de la liste est « nouvelles racines ».) Nous serions ravis de voir ce processus terminé dès que possible, et d'avoir une autre option gratuite, mais vérifiée, dans notre magasin racine.
