Après il y a pleins de cas où les listes de révocations ne sont pas vérifiées…
Les CRLs ne sont plus vérifiées par personne ou presque. Firefox et Chrome ne les supportent même plus (ce n’est même plus une option laissée à la discrétion de l’utilisateur, ces navigateurs ne prennent plus du tout en charge les CRLs).
La révocation dans le monde PKIX ne fonctionne pas (pas plus pour un certificat intermédiaire que pour un certificat terminal). Il faut une action explicite et ad hoc des éditeurs pour blacklister un certificat quand on détecte qu’il a été utilisé à mauvais escient :
Our current method of revoking certificates in response to major incidents is to push a software update. Microsoft, Opera and Firefox also push software updates for serious incidents rather than rely on online revocation checks.
C’est une des raisons pour lesquelles Let’s Encrypt délivre des certificats valables 90 jours, contre un, deux ou trois ans pour la plupart des autres CA.
Ca marche très bien aussi contre mon FAI, les mafias, et en fait tout ce qui n'est pas étatique.
Ça par contre je n’en mettrais pas ma main à couper. Des CA ont déjà signé des certificats intermédiaires à des clients privés (comme TrustWave déjà cité), ce n’est pas réservé aux gouvernements ou organisations affiliées.
Ça doit surtout marcher contre ceux qui n’ont pas assez d’argent à y mettre (ce qui je te l’accorde élimine déjà pas mal de monde).
même pour Google car les faux certificats ont été détectés et neutralisés
Détectés a posteriori. Cool pour les visiteurs suivants, mais d’aucune utilité pour les premières victimes.
Le gens envoient un simple mail non chiffré, et ça marche très bien. Il faut arrêter de vouloir mettre de la sécurité "top secret" pour tout et n'importe quoi, une sécurité non adaptée au besoin de sécurité n'est pas de la sécurité.
Non mais ça c’était une blague, hein. Désolé, je n’ai pas de contrat à te proposer.
N'importe quel tenancier de bar perdu dans lequel je vais le peut. Récupérer un certificat valide (accepté par les navigateurs) de mon domaine, ça serait plus difficile…
Ah, là OK. Je n’avais pas envisagé ce type d’adversaire, gros fail de ma part en effet. Je concède l’apport en sécurité dans ce cas de figure.
Je tenterai de sauver la face en disant qu’en écoutant les promesses des CA, on serait quand même en droit d’attendre beaucoup plus de leur part qu’une protection contre un adversaire du niveau d’un « tenancier de bar perdu ».
une petite sécurité comme avec les CA est mieux que rien du tout
Il va sérieusement falloir que tu m’expliques quelle est la « petite sécurité » apportée par les CA…
De deux choses l’une :
a) Mon adversaire n’est pas en position de faire du MITM et doit se contenter d’attaques passives. Dans ce cas je n’ai pas besoin d’authentifier ton serveur, j’ai juste besoin de chiffrement pour être sûr que personne ne puisse lire le traffic.
b) Mon adversaire est actif et en position de faire du MITM. Dans ce cas l’authentification du pair est un préalable indispensable à la confidentialité, le chiffrement seul ne peut suffire.
Le cas a) est celui où les CA ne servent à rien, par principe (les CA servent à authentifier le pair et il n’y a pas besoin d’authentification dans ce modèle de menace). Un certificat signé par une CA reconnue n’apporte ici rien de plus qu’un certificat auto-signé ou signé par une CA non-reconnue, en tout cas sur le plan de la sécurité (le certificat signé apporte à l’utilisateur l’absence de message d’avertissement, mais ce n’est pas de la sécurité).
Le cas b) est celui pour lequel les CA existent.
En pratique, ce n’est évidemment pas moi qui décide des capacités de mon adversaire, je dois donc supposer que je suis dans le cas b).
Dans le cas b) donc, si je me connecte sur (ce que je crois être) ton site et que je vois un certificat auto-signé, je n’ai aucune certitude d’être réellement sur ton site et non sur la façade mise en place par Mallory.¹
Si je vois un certificat signé par une CA reconnue (donc si je ne vois rien, en fait, parce que le navigateur est silencieux dans ce cas de figure)… je n’ai toujours aucune certitude d’être réellement sur ton site et non sur la façade mise en place par Mallory. Sauf à supposer que Mallory est incapable d’obtenir un certificat valide, ce qui me paraît pour le moins douteux de la part d’un adversaire par ailleurs capable de faire du MITM.²
Je vois bien le confort en tant qu’utilisateur (connexion silencieusement acceptée, pas de messages d’avertissement), mais où est la sécurité que devaient m’apporter les CA ?
Dans les deux cas (certificat auto-signé ou signé par une autorité reconnue), je me retrouve à transmettre à Mallory des informations que je destinais à toi seul.³
Le fait que ton certificat soit signé par une CA reconnue ne m’a pas apporté de quelconque sécurité, même pas une « petite sécurité ». En fait, ton certificat n’entre même pas en ligne de compte — je ne l’ai jamais vu, je n’ai vu que celui présenté par Mallory.
Je ne propose pas, à l’image de l’auteur du journal) de se passer des CA (enfin, si, mais pas avant que les alternatives soient mieux déployées, si elles le sont un jour). Que ça me plaise ou non, elles sont là et le comportement (regrettable) des navigateurs interdit de s’en débarasser. Mais je persiste et signe, elles ne servent à rien d’autre aujourd’hui qu’éviter les messages d’avertissements (donc à résoudre un problème qui n’existerait pas sans elles, ou sans l’attitude des navigateurs de les considérer comme indispensables).
¹ Bon, en l’espèce, si je me connecte sur mediaarea.net et que le certificat présenté est auto-signé (ou signé par CAcert), je me douterai qu’il y a quelque chose de louche. :D Mais c’est uniquement parce que j’ai eu des infos supplémentaires à ton sujet par un canal séparé.
² Ne serait-ce que parce que si Mallory peut faire du MITM, il ne devrait pas avoir de mal à flouer les procédures de vérification auxquelles se livrent les CA avant de délivrer un certificat Domain-Validated.
³ Et c’est dommage, parce que j’avais un super contrat à te proposer à propos de MediaInfo, mais du coup c’est Mallory qui va me faire une meilleure offre. :)
Quoiqu’en y repensant, il n’est pas impossible que l’appui de Mozilla et Google ait joué en amont dans la décision de IdenTrust de signer Let’s Encrypt.
Mozilla et Google en sponsor, je crois qu'ils ont eu un mot à dire dessus ;-).
Sur la situation actuelle, non : le fait que Firefox et Chrome acceptent les certificats de Let’s Encrypt est strictement une conséquence de la signature de IdenTrust, Mozilla et Google n’ont rien eu à faire pour ça.
Au contraire, s’ils avaient voulu s’y opposer, ils n’auraient pu faire autrement qu’implémenter une solution ad hoc, comme blacklister explicitement le certificat intermédiaire de Let’s Encrypt.
Sur la situation future (l’éventuelle acceptation du certificat racine de Let’s Encrypt) : j’espère bien que le fait que Mozilla et Google sponsorisent Let’s Encrypt ne jouera aucun putain de rôle dans la procédure d’évaluation. On doit attendre de Let’s Encrypt qu’ils répondent aux mêmes critères que ceux appliqués aux autres CA candidates. Sinon bonjour le message : « l’évaluation, les audits, tout ça c’est pour les autres, comme ces péquenots de CAcert — mais vous vous mangez à la même table que nous, on ne va pas vous ennuyer avec ça ».
IdenTrust ne fait pas ça "parce qu'il a envie", car joue sa crédibilité dessus
Oui, parce que les CA qui ont déjà signé des sous-CA à tort et à travers ont vu leur crédibilité très écornée, right. TrustWave ne s’en est jamais remis d’ailleurs. Ou pas.
OK mais pourquoi cette différence de traitement ? pourquoi est-ce que "personne n'a confiance en eux" ?
Il n’y a pas de différence de traitement (en tout cas pas entre Let’s Encrypt et CAcert). Les navigateurs ne font pas plus « confiance » à Let’s Encrypt qu’à CAcert. Ni l’une ni l’autre n’a son certificat racine dans les magasins des navigateurs.
Si les certificats de Let’s Encrypt sont acceptés sans sourciller par les navigateurs, c’est seulement parce que IdenTrust (une CA dont le certificat racine est dans le magasin des navigateurs) a signé leur certificat intermédiaire. Les navigateurs n’ont pas eu leur mot à dire là-dessus.
C’est un des problèmes du modèle X.509 justement : on fait confiance à une CA (qui en principe a montré patte blanche, admettons), et celle-ci peut silencieusement transmettre cette confiance à autant d’autorités intermédiaires qu’elle veut (y compris des autorités qui ne sont pas sous son contrôle direct), sans aucun contrôle des navigateurs.
Dans le cas de Let’s Encrypt, ça ne s’est pas fait silencieusement parce que Let’s Encrypt a évidemment largement communiqué sur sa propre création, mais il y a des milliers d’autres sous-CA dans la nature dont la signature du certificat n’a pas été accompagnée d’une telle publicité.
Concrètement : on ne sait pas à qui on fait confiance, ni même à combien de « qui » ?
Note : je ne critique pas le principe des certificats intermédiaires, qui ne sont pas une mauvaise idée en soi. C’est même une très bonne idée dans le cas où les certificats intermédiaires appartiennent à la même entité que le certificat racine : ça permet de garder la clef du certificat racine dans un coffre-fort d’où elle ne sort presque jamais, seules les clefs des certificats intermédiaires devant être accessibles (et donc, potentiellement, vulnérables) pour signer les certificats des clients.
Le problème, c’est que techniquement il n’y a aucune différence entre un certificat intermédiaire interne à la CA, et un certificat intermédiaire remis à une entité distincte qui va de fait constituer une CA indépendante (à laquelle les navigateurs feront implicitement confiance même s’ils n’ont jamais vu l’audit de l’entité en question). On ne peut pas faire confiance à un type de certificat intermédiaire sans faire confiance à l’autre.
quelqu'un peut-il réexpliquer ce qui cloche avec cacert et pourquoi ils n'arrivent pas à se faire accepter parmi les CA installées avec les navigateurs habituels ?
Si tu es motivé pour chercher, je me souviens que patrick_g avait posté il y a quelque temps un lien vers une explication détaillée de la part d’une des personnes impliquées dans la procédure d’audit de CAcert.
Lapin compris en quoi "la fenêtre est ouverte 1 mètre plus loin"…
Je ne sais pas à quoi faisait référence l’auteur de cette métaphore, mais le fait est que les vérifications strictes que font CAcert sont tout aussi inutiles que les vérifications strictes que font les autres autorités de certifications. Pourquoi ? Parce que même si toi tu te soumets aux vérifications de CAcert pour obtenir un certificat pour ton domaine, Mallory peut obtenir un certificat valide pour ce même domaine auprès d’une autre autorité de certification qui serait moins regardante.
effectivement ils vérifiaient sérieusement l'identité des gens
Donc si je me connecte à ton site et que je vois un certificat signé par CAcert, je saurai que c’est réellement toi qui est derrière. C’est bien, mais ce n’est pas ce dont j’ai besoin.
Ce dont j’ai besoin, en tant que visiteur, c’est d’un système qui empêche Mallory (l’attaquant actif) de me présenter son site en me faisant croire que c’est le tien. Et ça, ton certificat signé par CAcert ne peut pas me le garantir.
Mais c’est totalement indépendamment de CAcert : tu aurais un certificat EV remis en main propre par le PDG de Verisign que ce serait la même chose.
en quoi Let's Encrypt est-il mieux que cacert ?
Une seule chose : Let’s Encrypt est reconnu par les navigateurs et ne provoquera pas de message d’avertissement.
Tu remets en question la confiance qu'on peut accorder au Logiciel Libre ? Sur LinuxFr ? Sérieusement ?
Je crois qu’il est très sérieux, et pire encore, qu’il a… il a… raison. ¹
Ce n’est pas parce qu’on est sur LinuxFr.org qu’on doit forcément penser que le libre est une réponse magique à tous les problèmes.
En l’espèce, le libre accès au code source est une condition nécessaire à l’établissement de la confiance, mais en aucun cas une condition suffisante.
pourquoi ne puis-je pas avoir confiance en mon système en ayant accès à son code source ?
Demande-toi par exemple quelle(s) garantie(s) tu as que le code fourni correspond bien à celui qui a permis de générer les binaires que tu utilises…
(Et non, recompiler les sources et comparer ce que tu obtiens avec ce qu’on te fournit n’est pas une solution : la reproductibilité de la compilation n’est pas une mince affaire.)
Si mon registrar fait un truc qui me plait pas, je change de crémerie. Oui, le même principe s'applique à une CA.
Non, justement. Seul ton registrar peut te faire une crasse, donc tu peux en changer pour un autre si ça arrive.
Mais n’importe quelle CA peut émettre un certificat pour ton domaine. Si une CA autre que celle tu as choisie émet un certificat frauduleux, tu peux bien changer de CA, ça ne servira strictement à rien.
Merde alors, te voila sous la coupe d'un tiers de confiance, exactement comme les CA que tu critiques…
Tu es sous la « coupe » d’un tiers de confiance bien précis que tu as choisi.
Avec les CA, « le » tiers de confiance est en réalité :
un ensemble de plusieurs centaines d’autorités de certification ;
que tu n’as pas choisi ;
qui peuvent déléguer leur pouvoir de signature à n’importe qui à n’importe quel moment (pour rappel, c’est ce qui permet à Let’s Encrypt d’exister, car cette CA n’a pas encore passé l’examen pour avoir son propre certificat racine intégré dans les magasins des navigateurs), de sorte que le nombre réel de « tiers de confiance » n’est en réalité même pas connu, encore moins l’identité de chacun ;
auxquelles tu accordes la même confiance, de sorte que la confiance globale du système est celle de la moins fiable des CA (il peut y avoir 99% de CA parfaites et irréprochables, ça ne sert à rien s’il y a 1% de CA malhonnêtes et/ou incompétentes) ;
dont plusieurs ont déjà montré qu’elles n’étaient pas digne de confiance.
À part ça ces quelques menus détails, tu as raison, c’est bien sûr « exactement » la même chose…
Non. Let’s Encrypt n’est pas la seule CA à délivrer des certificats DV gratuitement. Sa particularité dans ce domaine, c’est de ne faire que ça, alors que chez les autres CA les certificats gratuits sont typiquement des produits d’appels.
dans le mode de vérification des renseignements
Non. Let’s Encrypt vérifie que tu as un semblant de contrôle sur le domaine que tu demandes. C’est ce que font toutes les CA qui délivrent des certificats Domain-Validated, il n’y a rien de nouveau ou d’unique là-dedans.
Par contre, je rajoute que Let’s Encrypt a, par rapport aux autres CA, une bonne stratégie marketing, capable de faire oublier qu’ils sont une CA comme les autres.
Permettre d'avoir des certificats reconnus, gratuitement, sans passer par les organes de certification
Non. Let’s Encrypt est un organe de certification, en rien différent des centaines d’autres reconnues par les navigateurs et qui fournissent aussi des certificats Domain-Validated (certains aussi gratuitement).
La seule particularité de Let’s Encrypt tient dans l’effort d’automatisation côté client.
This website contents and images are Copyright by tecmint. All rights are reserved. Backlinks and links of our documents are encouraged. However, you may not copy or repost any article from this website without the written consent of the website owner.
Et aucune mention d’une license CC (ou d’une quelconque autre license libre) dans cette page. Bref, c’est pas libre, point.
À mon avis, de deux choses l’une :
a) Dans la mention « This work is licensed under a (cc) BY-NC », l’expression « This work » désigne en fait le site lui-même (en gros, son design), qui serait libre alors que le contenu ne l’est clairement pas.
Ou
b) La mention de la licence CC BY-NC a juste été mise là parce que c’est tendance de dire qu’on fait du libre.
Ne devrait-il pas écrire orthographe avec sa nouvelle orthografe ? ou font-il juste de la comm en appliquant qu’une partie minime de la réforme ?
Ne devrais-tu pas lire les liens que tu cites ? Ou critiques-tu ce que tu imagines que la réforme contient ?
La réforme ne propose pas d’éradiquer systématiquement le « ph ». Dans le cas particulier de « nénuphar », elle propose de le supprimer pour rétablir ce qui était son orthographe d’origine.
Savez-vous que ce mot s’est toujours écrit avec un f jusqu’en 1935 ? […] Mais en 1935, on s’est trompé en pensant que le mot était de la famille du mot grec nymphéa, alors on a décidé de l’écrire avec ph. Depuis lors, on s’est rendu compte de l’erreur. Le mot vient du persan et le ph n’est pas du tout justifié. On réserve la graphie ph aux mots qui viennent du grec (lettre phi). Donc on écrira nénufar, mais on ne touche pas à éléphant ni à philosophie ! [et je rajoute : ni à orthographe]
Il est juste dit qu'il est moins pourri que ce que vous proposez en alternative.
For the record, je n’ai jamais proposé de faire purement et simplement l’impasse sur l’authentification du tiers et de se contenter d’une protection contre les attaques passives.
J’ai déjà exposé plusieurs fois ma « proposition », basée sur l’utilisation simultanée d’un ensemble de méthodes d’authentification au lieu se reposer sur les seules CA. Méthodes qui peuvent intervenir en complément des CA ou en remplacement, selon le crédit que tu es disposé à leur accorder.
Extended Validation. Des certificats que l’autorité de certification ne délivre qu’après avoir tout mis en œuvre pour vérifier que le demandeur est bien celui qu’il prétend être — par opposition aux certificats Domain-Validated, où la CA vérifie seulement que le demandeur a un certain contrôle sur le nom de domaine demandé.
Et attention, c’est du sérieux ⸮ Un certificat EV, tu le payes cher, mais tu en as pour ton argent. Les vérifications sont tellement strictes que personne ne peut obtenir un certificat en ton nom, et par un effet mystérieux connu sous le nom de « je paye un max donc c’est mieux », tu apportes à tes visiteurs la garantie que personne ne peut non plus obtenir un certificat DV (qui concrètement a la même valeur, à part que l’affichage est moins joli dans le navigateur) auprès d’une autre CA.
Un cert auto signe ou rien du tout, c'est strictement pareil, et celui qui déploie ca au mieux est en plein délire, au pire incompetent.
Je ne voulais pas répondre à ça (je commence à avoir ras-le-bol de répéter toujours la même chose lors de chaque discussion sur TLS, X.509 et PKIX), mais quand je vois que le commentaire est à +9, je ne peux pas laisser passer…
Allez, dernière fois.
Contre les attaques purement passives, les CA n’apportent rien, un certificat auto-signé suffit complètement. La seule raison d’être des CA est de prévenir les attaques actives de type MITM, en garantissant que le type à qui on parle est bien celui que l’on croit.
Or en l’état actuel du système PKIX, les CA n’apportent pas cette garantie. Quand je me connecte sur example.com et que mon navigateur ne me dit rien du tout, je n’ai aucune certitude que je suis bien sur le bon site : je peux être sur le site d’un attaquant qui a obtenu un certificat « valide » auprès de l’une quelconque des centaines de CA racines qui ont la confiance absolue de mon navigateur, ou de l’une quelconques des innombrables sous-CA.
Les CA ne servent à rien. Elles me laissent complètement vulnérable au type même d’attaques contre lequel elles sont supposées me protéger.
La seule différence aujourd’hui entre un certificat auto-signé et un certificat signé par une CA reconnue, c’est que l’un provoque la panique du navigateur alors que l’autre est accepté sans broncher. Mais la sécurité fournie est la même : une sécurité contre les attaques passives uniquement, sans aucune protection contre l’homme du milieu.
Je vous laisse continuer à vous auto-persuader du contraire.
(Demandez-vous quand même, à l’occasion, pourquoi tant de monde perd du temps sur HPKP, DANE, Certificate Transparency, et autres dispositifs complémentaires supposés pallier les carences de PKIX. Qu’ils sont cons ces ingénieurs sécurité, s’ils lisaient linuxfr.org ils sauraient que PKIX n’a pas besoin de ça.)
Posté par gouttegd .
En réponse au journal À propos des certificats.
Évalué à 2.
Dernière modification le 02 février 2016 à 01:26.
Je rappelle que la solution originelle de Richard consistait à virer tous les certificats des CA, et de faire du Trust On First Use. Solution qui a fait rire tout le monde ici, et vous êtes les deux seuls à ne pas comprendre. Il ne vous est alors pas venu à l'esprit que vous faisiez fausse route ?
Ce n’est pas parce que la solution est maladroitement proposée qu’elle est à écarter d’emblée.
Je suis d’accord que demander aux visiteurs de faire tout le boulot eux-mêmes est irréaliste.
Mais avec le support des sites visités (épinglage des clefs publiques) et le support des navigateurs (qui se chargent eux-mêmes d’assurer le suivi des certificats de manière transparente pour l’utilisateur), les solutions du type Trust-on-First-Use ne sont pas aussi ridicules que tu sembles le croire.
En tout cas, elles sont suffisamment pas ridicules pour que les « centaines d’ingénieurs sécurité » de Google et de Mozilla décident d’implémenter HPKP dans Chrome et Firefox, et que ceux de Microsoft y réfléchissent (« under consideration »). Tant il apparaît nécessaire à tout ce beau monde de ne pas se fier aux seules CA…
C’est grosso modo le principe de Convergence : on récupère le certificat depuis plusieurs endroits en misant sur le fait qu’un attaquant ne peut pas faire du MITM partout. La différence étant que Convergence passe par des notaries là où tu proposes de passer par des nœuds Tor.
Si tu expliquais comment l'utilisateur peut vérifier que c'est bien la bonne qu'il contact
Il ne vérifie pas. Ce n’est pas pour rien qu’on parle de Trust-On-First-Use ou de Leap-Of-Feath…
TOFU ne protège pas d’un MITM lors de la première connexion, c’est un fait. Mais il protège les connexions ultérieures, ce que le système PKIX ne fait pas.
Le TOFU, ça ne marche que dans certains contextes.
Rien ne dit que ça ne marcherait pas dans le contexte de HTTPS. D’ailleurs, c’est l’une des principales pistes pour pallier les déficiences de PKIX, c’est pour ça qu’on a inventé l’épinglage des clefs publiques dans les en-têtes HTTP (HPKP).
Un autre point, est que le certificat peut changer pour plein de raison, sans que l'utilisateur en soit averti, il n'a donc aucun moyen de savoir en cas de changement si c'est légitime ou pas.
Ce n’est pas parce que les navigateurs acceptent sans sourciller qu’un certificat puisse changer à tout moment (en absence d’extension chargée précisément de surveiller ça, comme CertPatrol ou assimilée) que c’est une bonne idée de changer de certificat à l’improviste.
Toutes les méthodes d’épinglage des clefs, que ce soit dans les en-têtes HTTP (HPKP), dans le DNS (DANE), ou même pré-chargées dans le navigateur, vont exiger des administrateurs de serveurs TLS un peu plus de rigueur et d’anticipation dans la gestion de leurs certificats, et c’est une bonne chose.
[^] # Re: Faux ingénu
Posté par gouttegd . En réponse au journal Monsanto, Zika Hoax. Évalué à 5.
Déconne pas avec ça, c’est vachement dangereux le monoxyde de dihydrogène.
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 2.
Les CRLs ne sont plus vérifiées par personne ou presque. Firefox et Chrome ne les supportent même plus (ce n’est même plus une option laissée à la discrétion de l’utilisateur, ces navigateurs ne prennent plus du tout en charge les CRLs).
La révocation dans le monde PKIX ne fonctionne pas (pas plus pour un certificat intermédiaire que pour un certificat terminal). Il faut une action explicite et ad hoc des éditeurs pour blacklister un certificat quand on détecte qu’il a été utilisé à mauvais escient :
Adam Langley
C’est une des raisons pour lesquelles Let’s Encrypt délivre des certificats valables 90 jours, contre un, deux ou trois ans pour la plupart des autres CA.
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 3.
Ça par contre je n’en mettrais pas ma main à couper. Des CA ont déjà signé des certificats intermédiaires à des clients privés (comme TrustWave déjà cité), ce n’est pas réservé aux gouvernements ou organisations affiliées.
Ça doit surtout marcher contre ceux qui n’ont pas assez d’argent à y mettre (ce qui je te l’accorde élimine déjà pas mal de monde).
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 3.
Détectés a posteriori. Cool pour les visiteurs suivants, mais d’aucune utilité pour les premières victimes.
Non mais ça c’était une blague, hein. Désolé, je n’ai pas de contrat à te proposer.
Ah, là OK. Je n’avais pas envisagé ce type d’adversaire, gros fail de ma part en effet. Je concède l’apport en sécurité dans ce cas de figure.
Je tenterai de sauver la face en disant qu’en écoutant les promesses des CA, on serait quand même en droit d’attendre beaucoup plus de leur part qu’une protection contre un adversaire du niveau d’un « tenancier de bar perdu ».
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 3.
Il va sérieusement falloir que tu m’expliques quelle est la « petite sécurité » apportée par les CA…
De deux choses l’une :
a) Mon adversaire n’est pas en position de faire du MITM et doit se contenter d’attaques passives. Dans ce cas je n’ai pas besoin d’authentifier ton serveur, j’ai juste besoin de chiffrement pour être sûr que personne ne puisse lire le traffic.
b) Mon adversaire est actif et en position de faire du MITM. Dans ce cas l’authentification du pair est un préalable indispensable à la confidentialité, le chiffrement seul ne peut suffire.
Le cas a) est celui où les CA ne servent à rien, par principe (les CA servent à authentifier le pair et il n’y a pas besoin d’authentification dans ce modèle de menace). Un certificat signé par une CA reconnue n’apporte ici rien de plus qu’un certificat auto-signé ou signé par une CA non-reconnue, en tout cas sur le plan de la sécurité (le certificat signé apporte à l’utilisateur l’absence de message d’avertissement, mais ce n’est pas de la sécurité).
Le cas b) est celui pour lequel les CA existent.
En pratique, ce n’est évidemment pas moi qui décide des capacités de mon adversaire, je dois donc supposer que je suis dans le cas b).
Dans le cas b) donc, si je me connecte sur (ce que je crois être) ton site et que je vois un certificat auto-signé, je n’ai aucune certitude d’être réellement sur ton site et non sur la façade mise en place par Mallory.¹
Si je vois un certificat signé par une CA reconnue (donc si je ne vois rien, en fait, parce que le navigateur est silencieux dans ce cas de figure)… je n’ai toujours aucune certitude d’être réellement sur ton site et non sur la façade mise en place par Mallory. Sauf à supposer que Mallory est incapable d’obtenir un certificat valide, ce qui me paraît pour le moins douteux de la part d’un adversaire par ailleurs capable de faire du MITM.²
Je vois bien le confort en tant qu’utilisateur (connexion silencieusement acceptée, pas de messages d’avertissement), mais où est la sécurité que devaient m’apporter les CA ?
Dans les deux cas (certificat auto-signé ou signé par une autorité reconnue), je me retrouve à transmettre à Mallory des informations que je destinais à toi seul.³
Le fait que ton certificat soit signé par une CA reconnue ne m’a pas apporté de quelconque sécurité, même pas une « petite sécurité ». En fait, ton certificat n’entre même pas en ligne de compte — je ne l’ai jamais vu, je n’ai vu que celui présenté par Mallory.
Je ne propose pas, à l’image de l’auteur du journal) de se passer des CA (enfin, si, mais pas avant que les alternatives soient mieux déployées, si elles le sont un jour). Que ça me plaise ou non, elles sont là et le comportement (regrettable) des navigateurs interdit de s’en débarasser. Mais je persiste et signe, elles ne servent à rien d’autre aujourd’hui qu’éviter les messages d’avertissements (donc à résoudre un problème qui n’existerait pas sans elles, ou sans l’attitude des navigateurs de les considérer comme indispensables).
¹ Bon, en l’espèce, si je me connecte sur mediaarea.net et que le certificat présenté est auto-signé (ou signé par CAcert), je me douterai qu’il y a quelque chose de louche. :D Mais c’est uniquement parce que j’ai eu des infos supplémentaires à ton sujet par un canal séparé.
² Ne serait-ce que parce que si Mallory peut faire du MITM, il ne devrait pas avoir de mal à flouer les procédures de vérification auxquelles se livrent les CA avant de délivrer un certificat Domain-Validated.
³ Et c’est dommage, parce que j’avais un super contrat à te proposer à propos de MediaInfo, mais du coup c’est Mallory qui va me faire une meilleure offre. :)
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 2.
Quoiqu’en y repensant, il n’est pas impossible que l’appui de Mozilla et Google ait joué en amont dans la décision de IdenTrust de signer Let’s Encrypt.
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 4.
Sur la situation actuelle, non : le fait que Firefox et Chrome acceptent les certificats de Let’s Encrypt est strictement une conséquence de la signature de IdenTrust, Mozilla et Google n’ont rien eu à faire pour ça.
Au contraire, s’ils avaient voulu s’y opposer, ils n’auraient pu faire autrement qu’implémenter une solution ad hoc, comme blacklister explicitement le certificat intermédiaire de Let’s Encrypt.
Sur la situation future (l’éventuelle acceptation du certificat racine de Let’s Encrypt) : j’espère bien que le fait que Mozilla et Google sponsorisent Let’s Encrypt ne jouera aucun putain de rôle dans la procédure d’évaluation. On doit attendre de Let’s Encrypt qu’ils répondent aux mêmes critères que ceux appliqués aux autres CA candidates. Sinon bonjour le message : « l’évaluation, les audits, tout ça c’est pour les autres, comme ces péquenots de CAcert — mais vous vous mangez à la même table que nous, on ne va pas vous ennuyer avec ça ».
Oui, parce que les CA qui ont déjà signé des sous-CA à tort et à travers ont vu leur crédibilité très écornée, right. TrustWave ne s’en est jamais remis d’ailleurs. Ou pas.
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 4. Dernière modification le 16 février 2016 à 08:20.
Il n’y a pas de différence de traitement (en tout cas pas entre Let’s Encrypt et CAcert). Les navigateurs ne font pas plus « confiance » à Let’s Encrypt qu’à CAcert. Ni l’une ni l’autre n’a son certificat racine dans les magasins des navigateurs.
Si les certificats de Let’s Encrypt sont acceptés sans sourciller par les navigateurs, c’est seulement parce que IdenTrust (une CA dont le certificat racine est dans le magasin des navigateurs) a signé leur certificat intermédiaire. Les navigateurs n’ont pas eu leur mot à dire là-dessus.
C’est un des problèmes du modèle X.509 justement : on fait confiance à une CA (qui en principe a montré patte blanche, admettons), et celle-ci peut silencieusement transmettre cette confiance à autant d’autorités intermédiaires qu’elle veut (y compris des autorités qui ne sont pas sous son contrôle direct), sans aucun contrôle des navigateurs.
Dans le cas de Let’s Encrypt, ça ne s’est pas fait silencieusement parce que Let’s Encrypt a évidemment largement communiqué sur sa propre création, mais il y a des milliers d’autres sous-CA dans la nature dont la signature du certificat n’a pas été accompagnée d’une telle publicité.
Concrètement : on ne sait pas à qui on fait confiance, ni même à combien de « qui » ?
Note : je ne critique pas le principe des certificats intermédiaires, qui ne sont pas une mauvaise idée en soi. C’est même une très bonne idée dans le cas où les certificats intermédiaires appartiennent à la même entité que le certificat racine : ça permet de garder la clef du certificat racine dans un coffre-fort d’où elle ne sort presque jamais, seules les clefs des certificats intermédiaires devant être accessibles (et donc, potentiellement, vulnérables) pour signer les certificats des clients.
Le problème, c’est que techniquement il n’y a aucune différence entre un certificat intermédiaire interne à la CA, et un certificat intermédiaire remis à une entité distincte qui va de fait constituer une CA indépendante (à laquelle les navigateurs feront implicitement confiance même s’ils n’ont jamais vu l’audit de l’entité en question). On ne peut pas faire confiance à un type de certificat intermédiaire sans faire confiance à l’autre.
[^] # Re: cacert ?
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 4.
Si tu es motivé pour chercher, je me souviens que patrick_g avait posté il y a quelque temps un lien vers une explication détaillée de la part d’une des personnes impliquées dans la procédure d’audit de CAcert.
Je ne sais pas à quoi faisait référence l’auteur de cette métaphore, mais le fait est que les vérifications strictes que font CAcert sont tout aussi inutiles que les vérifications strictes que font les autres autorités de certifications. Pourquoi ? Parce que même si toi tu te soumets aux vérifications de CAcert pour obtenir un certificat pour ton domaine, Mallory peut obtenir un certificat valide pour ce même domaine auprès d’une autre autorité de certification qui serait moins regardante.
Donc si je me connecte à ton site et que je vois un certificat signé par CAcert, je saurai que c’est réellement toi qui est derrière. C’est bien, mais ce n’est pas ce dont j’ai besoin.
Ce dont j’ai besoin, en tant que visiteur, c’est d’un système qui empêche Mallory (l’attaquant actif) de me présenter son site en me faisant croire que c’est le tien. Et ça, ton certificat signé par CAcert ne peut pas me le garantir.
Mais c’est totalement indépendamment de CAcert : tu aurais un certificat EV remis en main propre par le PDG de Verisign que ce serait la même chose.
Une seule chose : Let’s Encrypt est reconnu par les navigateurs et ne provoquera pas de message d’avertissement.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 6.
Je crois qu’il est très sérieux, et pire encore, qu’il a… il a… raison. ¹
Ce n’est pas parce qu’on est sur LinuxFr.org qu’on doit forcément penser que le libre est une réponse magique à tous les problèmes.
En l’espèce, le libre accès au code source est une condition nécessaire à l’établissement de la confiance, mais en aucun cas une condition suffisante.
Demande-toi par exemple quelle(s) garantie(s) tu as que le code fourni correspond bien à celui qui a permis de générer les binaires que tu utilises…
(Et non, recompiler les sources et comparer ce que tu obtiens avec ce qu’on te fournit n’est pas une solution : la reproductibilité de la compilation n’est pas une mince affaire.)
¹ Aïeuh, ça fait mal aux doigts d’écrire ça. :D
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 6.
Non, justement. Seul ton registrar peut te faire une crasse, donc tu peux en changer pour un autre si ça arrive.
Mais n’importe quelle CA peut émettre un certificat pour ton domaine. Si une CA autre que celle tu as choisie émet un certificat frauduleux, tu peux bien changer de CA, ça ne servira strictement à rien.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 7.
Tu es sous la « coupe » d’un tiers de confiance bien précis que tu as choisi.
Avec les CA, « le » tiers de confiance est en réalité :
À part ça ces quelques menus détails, tu as raison, c’est bien sûr « exactement » la même chose…
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 6.
Non. Let’s Encrypt n’est pas la seule CA à délivrer des certificats DV gratuitement. Sa particularité dans ce domaine, c’est de ne faire que ça, alors que chez les autres CA les certificats gratuits sont typiquement des produits d’appels.
Non. Let’s Encrypt vérifie que tu as un semblant de contrôle sur le domaine que tu demandes. C’est ce que font toutes les CA qui délivrent des certificats Domain-Validated, il n’y a rien de nouveau ou d’unique là-dedans.
Par contre, je rajoute que Let’s Encrypt a, par rapport aux autres CA, une bonne stratégie marketing, capable de faire oublier qu’ils sont une CA comme les autres.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 8.
Non. Let’s Encrypt est un organe de certification, en rien différent des centaines d’autres reconnues par les navigateurs et qui fournissent aussi des certificats Domain-Validated (certains aussi gratuitement).
La seule particularité de Let’s Encrypt tient dans l’effort d’automatisation côté client.
# Copyright Policy
Posté par gouttegd . En réponse au message Licence cc-by-nc avec restrictions ? [résolu]. Évalué à 2.
La page Copyright Policy lève toute ambiguïté :
Et aucune mention d’une license CC (ou d’une quelconque autre license libre) dans cette page. Bref, c’est pas libre, point.
À mon avis, de deux choses l’une :
a) Dans la mention « This work is licensed under a (cc) BY-NC », l’expression « This work » désigne en fait le site lui-même (en gros, son design), qui serait libre alors que le contenu ne l’est clairement pas.
Ou
b) La mention de la licence CC BY-NC a juste été mise là parce que c’est tendance de dire qu’on fait du libre.
[^] # Re: Nénufar
Posté par gouttegd . En réponse au journal Non aux réformes de l’orthographe !. Évalué à 10.
Ne devrais-tu pas lire les liens que tu cites ? Ou critiques-tu ce que tu imagines que la réforme contient ?
La réforme ne propose pas d’éradiquer systématiquement le « ph ». Dans le cas particulier de « nénuphar », elle propose de le supprimer pour rétablir ce qui était son orthographe d’origine.
[^] # Re: gmail
Posté par gouttegd . En réponse au journal Google passe devant Apple et annonce 1 milliard de comptes Gmail.... Évalué à 3.
C’est apparemment possible : https://accounts.google.com/SignUpWithoutGmail
(Et j’aurais d’ailleurs aimé le savoir avant de créer, moi aussi, un compte Google/GMail dont je ne me sers que pour accéder au Play Store…)
Mais il y a une autre option pour ceux pour qui c’est déjà trop tard (comme moi donc) : supprimer l’adresse GMail du compte Google.
[^] # Re: What's the point ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 0.
For the record, je n’ai jamais proposé de faire purement et simplement l’impasse sur l’authentification du tiers et de se contenter d’une protection contre les attaques passives.
J’ai déjà exposé plusieurs fois ma « proposition », basée sur l’utilisation simultanée d’un ensemble de méthodes d’authentification au lieu se reposer sur les seules CA. Méthodes qui peuvent intervenir en complément des CA ou en remplacement, selon le crédit que tu es disposé à leur accorder.
Voici ce qui était je pense la formulation la plus précise que j’ai écrite. C’est toujours ce que j’utilise actuellement, grâce à mon plugin Uzbl.
Malheureusement, implémenter ça pour des navigateurs plus complexes que Uzbl, comme Firefox ou Chrome, est largement hors de ma portée.
[^] # Re: Let's Encrypt
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 5.
Extended Validation. Des certificats que l’autorité de certification ne délivre qu’après avoir tout mis en œuvre pour vérifier que le demandeur est bien celui qu’il prétend être — par opposition aux certificats Domain-Validated, où la CA vérifie seulement que le demandeur a un certain contrôle sur le nom de domaine demandé.
Et attention, c’est du sérieux ⸮ Un certificat EV, tu le payes cher, mais tu en as pour ton argent. Les vérifications sont tellement strictes que personne ne peut obtenir un certificat en ton nom, et par un effet mystérieux connu sous le nom de « je paye un max donc c’est mieux », tu apportes à tes visiteurs la garantie que personne ne peut non plus obtenir un certificat DV (qui concrètement a la même valeur, à part que l’affichage est moins joli dans le navigateur) auprès d’une autre CA.
Ou pas.
[^] # Re: What's the point ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 8.
Je ne voulais pas répondre à ça (je commence à avoir ras-le-bol de répéter toujours la même chose lors de chaque discussion sur TLS, X.509 et PKIX), mais quand je vois que le commentaire est à +9, je ne peux pas laisser passer…
Allez, dernière fois.
Contre les attaques purement passives, les CA n’apportent rien, un certificat auto-signé suffit complètement. La seule raison d’être des CA est de prévenir les attaques actives de type MITM, en garantissant que le type à qui on parle est bien celui que l’on croit.
Or en l’état actuel du système PKIX, les CA n’apportent pas cette garantie. Quand je me connecte sur example.com et que mon navigateur ne me dit rien du tout, je n’ai aucune certitude que je suis bien sur le bon site : je peux être sur le site d’un attaquant qui a obtenu un certificat « valide » auprès de l’une quelconque des centaines de CA racines qui ont la confiance absolue de mon navigateur, ou de l’une quelconques des innombrables sous-CA.
Les CA ne servent à rien. Elles me laissent complètement vulnérable au type même d’attaques contre lequel elles sont supposées me protéger.
La seule différence aujourd’hui entre un certificat auto-signé et un certificat signé par une CA reconnue, c’est que l’un provoque la panique du navigateur alors que l’autre est accepté sans broncher. Mais la sécurité fournie est la même : une sécurité contre les attaques passives uniquement, sans aucune protection contre l’homme du milieu.
Je vous laisse continuer à vous auto-persuader du contraire.
(Demandez-vous quand même, à l’occasion, pourquoi tant de monde perd du temps sur HPKP, DANE, Certificate Transparency, et autres dispositifs complémentaires supposés pallier les carences de PKIX. Qu’ils sont cons ces ingénieurs sécurité, s’ils lisaient linuxfr.org ils sauraient que PKIX n’a pas besoin de ça.)
[^] # Re: Quel le problème en fait ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 2. Dernière modification le 02 février 2016 à 01:26.
Ce n’est pas parce que la solution est maladroitement proposée qu’elle est à écarter d’emblée.
Je suis d’accord que demander aux visiteurs de faire tout le boulot eux-mêmes est irréaliste.
Mais avec le support des sites visités (épinglage des clefs publiques) et le support des navigateurs (qui se chargent eux-mêmes d’assurer le suivi des certificats de manière transparente pour l’utilisateur), les solutions du type Trust-on-First-Use ne sont pas aussi ridicules que tu sembles le croire.
En tout cas, elles sont suffisamment pas ridicules pour que les « centaines d’ingénieurs sécurité » de Google et de Mozilla décident d’implémenter HPKP dans Chrome et Firefox, et que ceux de Microsoft y réfléchissent (« under consideration »). Tant il apparaît nécessaire à tout ce beau monde de ne pas se fier aux seules CA…
[^] # Re: What's the point ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 5.
C’est grosso modo le principe de Convergence : on récupère le certificat depuis plusieurs endroits en misant sur le fait qu’un attaquant ne peut pas faire du MITM partout. La différence étant que Convergence passe par des notaries là où tu proposes de passer par des nœuds Tor.
Malheureusement le développement de Convergence semble complètement arrêté.
[^] # Re: Quel le problème en fait ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 2.
Il ne vérifie pas. Ce n’est pas pour rien qu’on parle de Trust-On-First-Use ou de Leap-Of-Feath…
TOFU ne protège pas d’un MITM lors de la première connexion, c’est un fait. Mais il protège les connexions ultérieures, ce que le système PKIX ne fait pas.
[^] # Re: Quel le problème en fait ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 2.
Rien ne dit que ça ne marcherait pas dans le contexte de HTTPS. D’ailleurs, c’est l’une des principales pistes pour pallier les déficiences de PKIX, c’est pour ça qu’on a inventé l’épinglage des clefs publiques dans les en-têtes HTTP (HPKP).
Ce n’est pas parce que les navigateurs acceptent sans sourciller qu’un certificat puisse changer à tout moment (en absence d’extension chargée précisément de surveiller ça, comme CertPatrol ou assimilée) que c’est une bonne idée de changer de certificat à l’improviste.
Toutes les méthodes d’épinglage des clefs, que ce soit dans les en-têtes HTTP (HPKP), dans le DNS (DANE), ou même pré-chargées dans le navigateur, vont exiger des administrateurs de serveurs TLS un peu plus de rigueur et d’anticipation dans la gestion de leurs certificats, et c’est une bonne chose.
[^] # Re: Quel le problème en fait ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 10.
Ouais, demande à Zenitram ce qu’il en pense…