La façon dont on gère les certificats à l'heure actuelle me pose problème. Le principe même de devoir recourir à une instance étrangère pour vérifier l'identité d'un serveur présente, selon moi, un risque pour l'indépendance des éditeurs. Pourtant, je suis passé sur Let's Encrypt.
Il y a quelques jours, je vous parlais des certificats, et notamment de Let's Encrypt.
Pour moi, laisser un organisme tiers décider de la validité d'un certificat revient à abandonner notre indépendance. En effet, si nous avons la possibilité de générer des certificats auto-signés, c'est pour pouvoir le faire. Si on peut le faire, faisons-le !
En re-publiant cet article sur LinuxFr.org, je me suis attiré les foudres de ses lecteurs. Cet échange, bien que houleux et m'ayant laissé un goût amer, m'a fait réfléchir à ce qui était le plus important.
Par ailleurs, certains éléments d'actualité me conduisent également à réfléchir différemment. Notamment le cas de Google, qui, dans GMail, va afficher une alerte pour les mails envoyés sans chiffrement.
Bien que l'initiative de Google soit louable, je doute de son intérêt pour les utilisateurs du service. À moins d'être technicien, à quoi bon avertir l'utilisateur que son correspondant utilise un serveur qui ne met pas en œuvre TLS (ou SPF/DKIM) ? La seule chose que cela va provoquer chez l'utilisateur non technicien, c'est la peur.
D'autre part, ma réelle inquiétude est de savoir jusqu'où Google compte aller. Il n'y a qu'un pas à franchir entre afficher une alerte parce que le serveur du correspondant n'utilise pas du tout TLS, et parce qu'il utilise un certificat auto-signé. Surtout qu'en tant qu'entreprise influente, les concurrents pourraient suivre. Je fais un raccourci, mais ça signifierait la mort des serveurs mails auto-hébergés ne souhaitant pas utiliser un service comme Let's Encrypt.
Oui, c'est une niche, les serveurs mails auto-hébergés utilisant un certificat auto-signé. Mais ils existent, et sont là parce que c'est ça Internet: la liberté pour chacun de faire ce qu'il veut de son informatique.
Or, Google, comme à son habitude, augmente la portée de son droit de vie et de mort sur les petits acteurs insignifiants du net. Mais on s'éloigne quelque peu du sujet.
Suite à cette annonce, et suite à mon billet sur LinuxFr, j'ai décidé de passer à Let's Encrypt, et du même coup mettre de côté mes principes. La question est: pourquoi ?
Parce que j'écris pour que mon contenu soit lu, qu'on soit d'accord avec moi ou non. Mon objectif est de faire réfléchir. C'est mon utilité sur Internet. Peut être taper à côté sur le plan technique, mais initier une réflexion, encourager à ne pas faire tout et n'importe quoi parce que Google/Apple/facebook dit que c'est comme ça que les choses doivent être faites.
Par conséquent, afin que mes visiteurs ne soient pas dérangés par l'alerte relative au certificat auto-signé (et non invalide), je suis passé sur un certificat Let's Encrypt. Parce qu'à défaut de m'en passer, je prends ce qu'il y a de moins pire (je sais, encore une remarque qui me vaudra des insultes, peu importe).
Par extension, c'est également ce que j'ai fais sur mon serveur mail, afin de prévenir d'éventuels blocages le jour où les serveurs de mes correspondants décideraient de bloquer les certificats auto-signés.
J'espère simplement qu'un jour, on se rendra compte que pendant des années on a accusé des entreprises comme Google de s'arroger un pouvoir qu'elles n'ont pas à détenir, puis leur donner ce pouvoir parce qu'on a cru ça bon pour le grand public, avant de finalement revenir à un Internet plus authentique et proche de ses valeurs initiales.
# Platitude de discours et syndrome du martyr
Posté par Babelouest (site web personnel) . Évalué à 10.
On est sûrement d'accord sur le fond du débat (décentralisation de l'internet, légitimité des petits acteurs, etc.), mais ton journal ressemble plus à un gamin capricieux qui chiale parce que les gens font pas comme il veut.
C'est dommage, ca partait bien mais ca s'est gâté quand tu as préféré tomber dans les attaques gratuites et les procès d'intention:
On est sur Linuxfr, moi je t'aurais surtout demandé "Comment ?". J'ai l'intention de m'y mettre aussi mais j'ai pas encore franchi le pas et j'aimerais avoir des retours d'expérience.
Au début tu avais un argument contre Google, ca s'est transformé je ne sais pas comment en attaque contre apple et facebook aussi. Qu'est-ce qu'ils ont à voir avec le message d'avertissement de gmail ?
Pourquoi tu dis que tu vas te faire insulter ? Par qui ? Si tu sais que tu vas te faire insulter et que tu le fais quand même, mon copain Robert, avec qui je partage des débats d'idées souvent devant une anisette, il me dit que tu aimes ca te faire insulter.
Peut-être, mais d'après ce que je lis, ca sera pas grâce à toi…
[^] # Re: Platitude de discours et syndrome du martyr
Posté par Richard Dern . Évalué à 2.
Il me semble que Let's Encrypt est suffisamment simple d'utilisation pour qu'il ne soit pas nécessaire que je m'étende sur le sujet.
Ils ont à voir qu'ils font la pluie et le beau temps sur Internet et que pendant des années on (les geeks) a tous dit qu'il ne fallait pas les laisser faire. Aujourd'hui, Google, Apple, facebook, Amazon ont plus de pouvoir que jamais. J'ai étendu ma remarque à des points qui dépassent largement les certificats. Simplement pour exprimer un point de vue. Le but de tout échange entre humains.
J'ai réalisé que peut être, j'étais là pour ça :)
Mon but se limite à faire réfléchir. Pas à changer le monde. Ça, c'est pour les super-héros.
[^] # Re: Platitude de discours et syndrome du martyr
Posté par Babelouest (site web personnel) . Évalué à -1.
Oui j'ai lu la doc, mais c'est ton retour d'expérience qui m'intéresse.
Y'a pas si longtemps, sur ce même site (qui à l'époque tournait sous Templeet), on disait pareil de Microsoft qui allait détruire notre bel internet qu'on a mis tant de temps à construire, les raisons étaient différentes, mais les arguments étaient les mêmes (entre autres la place dans le CA du w3c je crois, ou encore IE et ses plugins, etc.). Autant que je sache, les raisons sont toujours valables pour détester Microsoft quand à son plan de détruire l'internet pour les geeks, mais je ne le vois pas dans ta liste noire, celle où y'a google, apple, facebook et amazon.
Dans tous les cas on est toujours là, plus forts qu'avant, et plus nombreux aussi, mais grâce à ceux qui font, qui expliquent et qui se battent, et en dépit de ceux qui se plaignent qu'on n'y arrivera jamais.
Bon ben ca sera sans moi
Effectivement ton but est très limite. Sais-tu que les super-héros n'existent pas ?
[^] # Re: Platitude de discours et syndrome du martyr
Posté par Richard Dern . Évalué à 0.
Désolé de ne pas être à la hauteur de tes attentes, mais quand j'essayai de sauver le monde, le monde n'était pas plus réceptif, alors j'ai décidé de tenter de simplement le faire réfléchir.
Mais peut être que j'ai encore trop d'ambition.
[^] # Re: Platitude de discours et syndrome du martyr
Posté par pasBill pasGates . Évalué à 4.
C'est pas que tu as trop d'ambition, c'est que tu as tout faux et que tu n'es pas capable de le réaliser. Encore un autre de ces gens qui croient savoir mieux que le reste du monde et se croient incompris.
C'est quand même dingue que dans le même journal tu arrives à nous sortir :
et
Ta grand-mère ne saurait quoi faire avec l'alerte de Google, mais tu veux qu'elle prenne des décisions sur la validité des certificats qu'elle rencontre plutôt que laisser un tiers de confiance le faire.
Je veux dire, à un moment je vais commencer à me dire que tu fais exprès, c'est pas possible d'être déconnecté de la réalité à ce point.
[^] # Re: Platitude de discours et syndrome du martyr
Posté par Richard Dern . Évalué à -8.
Toi, tu gueule parce que je critique les certificats, tu gueule parce que je passe à Let's Encrypt. Faudrait savoir, mets un peu d'ordre dans tes idées avant de gueuler partout où tu passes.
Et puis c'est quoi ton trip avec les grand-mères ?
Par ailleurs, tu noteras que si on cherche des alternatives au fonctionnement actuel (au hasard, DANE, comme cité dans une réponse plus bas) c'est que le fonctionnement actuel ne donne pas entière satisfaction. Vrai ou faux ?
Comme je l'ai précisé dans mon journal, je peux taper à côté sur le plan technique (je ne suis pas humainement en capacité de tout connaître, ergo je ne crois pas "mieux savoir que le reste du monde"). Toi, en revanche, tu semble être absolument convaincu que personne ne peut rien apporter de nouveau. Et ça c'est bien triste, homme de peu de foi.
[^] # Re: Platitude de discours et syndrome du martyr
Posté par pasBill pasGates . Évalué à 4.
Mais mon cher, je ne critiques pas car tu passes à Let's Encrypt, du tout. Je lis ta prose, et tu montres clairement dedans que tu considères que ton idée farfelue est toujours bonne mais que personne ne te comprends, bref, que tu passes à Let's Encrypt à contre-coeur car le monde ne te comprends pas, et je ne parles que de ça : Qu'à un moment faut que tu arrètes avec les oeillères, et te rendes compte que ton idée de certificats self-signed est vraiment bien pire que le mal que tu veux soigner.
LOL. Mais oui, tout à fait ! Le système actuel n'est pas parfait, personne n'a dit le contraire. Tout ce qu'on dit depuis le début est que TON idée est bien pire que le système actuel. Personne n'a jamais dit qu'il ne pouvait pas être amélioré, on a simplement dit qu'il ne serait pas amélioré avec ton idée.
Tu as visiblement beaucoup de mal à comprendre ce que les gens disent vu que ce n'est pas du tout ce que j'ai dit.
# Bof
Posté par Zenitram (site web personnel) . Évalué à 2.
Il y a aussi la liberté des autres de refuser ce qui n'est pas dans la "toile de confiance", par non confiance justement.
On n'est pas obligé d'accepter les gens qui ne souhaitent pas être crédible, ça semble légitime quoique tu en dises.
Que ça finisse en tout serveur mail qui n'a pas de SSL avec un certificat de confiance ne me choque pas.
Hors sujet.
C'est quoi un Internet plus authentique? Celui avec 99% de mails qui sont du spam et une navigation avec des MITM permanents? Perso, je te le laisse.
Ca me fait penser à Calimero, ça manque d'arguments à part ça.
[^] # Re: Bof
Posté par Richard Dern . Évalué à 2.
C'est bien le problème que je pointe: laisser Google (ou qui que ce soit à part soi-même) décider qui est crédible est une erreur à partir du moment où ça empêche les autres d'exister. Je sais, je prévois quelque chose qui n'arrivera peut être jamais, mais encore une fois, je ne fais qu'avertir de la possibilité que ça arrive.
Que ça finisse en tout serveur mail avec un certificat est une bonne chose. Je me répète mais le fond du problème est la confiance qu'on leur accorde, et, encore une fois, ce n'est pas à Google ni à une autre entreprise de décider ce qui est bon ou pas pour les visiteurs. Ça ne relève pas de leur autorité.
Oui, c'est ce que j'ai dis. Remarque useless.
Ah, parce que les certificats changent quelque chose au SPAM ? Parce que les spammeurs ne peuvent pas avoir un certificat signé par Let's Encrypt ? Parce que les spammeurs ne peuvent pas se payer un certificat ? Le spam n'a rien à voir là dedans. Ton argument sur les MITM est plus pertinent, encore que.
Quand je parle d'Internet plus authentique, je parle d'un Internet qu'on n'aurait pas laissé aux mains des GAFA. Mais peut être est-ce déjà trop tard.
Qu'est-ce qui manque d'arguments ? L'objet de mon article est "Pourquoi", j'y réponds: pour être lu. Je ne vois pas ce qu'il y a à argumenter. Par ailleurs, je ne vois pas la comparaison avec Calimero. Je ne me plains pas d'un manque de considération ou je ne sais quoi.
# dommage de ne pas s'être renseigné plus en avant...
Posté par briaeros007 . Évalué à 10.
Let's encrypt a un et un seul intérêt, permettre à tout un chacun d'utiliser un certificat reconnus dans les navigateurs. Point.
Pour les mails, les certificats sont rarement vérifié donc le problème est bien différent.
Et concernant ta tristesse de mettre de coté tes convictions, je trouve particulièrement triste de mon coté que ton site ne soit pas sécurisé par dnssec, et donc ne peut pas utiliser DANE.
DANE est l'alternative que tu cherches, et qui est normalisé, et qui est en voie d'acceptation (entre autre dans postfix etc…).
Avant de raler que le monde t'en veut, peut être faire ce qui peut être fait serait "plus mieux".
(pour ton info, j'ai un site, sur un des domaines j'ai ma CA, DANE etc…, sur l'autre j'ai un certif letsencrypt pour que tout le monde puisse y accéder, et rajouté la CA de letsencrypt en DANE pour ce domaine. Donc c'est faisable sans trop de soucis)
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par bobo38 . Évalué à 1.
C'est bien ce que j'avais compris… Permettre d'avoir des certificats reconnus, gratuitement, sans passer par les organes de certification, et se libérer des effets de bord de l'auto-certification (messages du navigateur pas content etc…)
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd (site web personnel) . É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.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par briaeros007 . Évalué à 2.
dans l'automatisation, dans la gratuité, dans le mode de vérification des renseignements, et dans le fait de limiter la durée des certificats pour limiter les effets du vol de clés.
Ca fait quand même pas mal de changement par rapports à une bonne partie des autres CA où, tant que tu paie, tu peux valider n'importe quel url pas trop connue, même si elle ne t'appartient pas, que le certificat est envoyé par mail, et qu'elle a une durée de 2 à 3 ans.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd (site web personnel) . É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 briaeros007 . Évalué à -2.
ou pas …
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à 0.
Je n'ai jamais dis ça. J´ai simplement constaté le peu de partisans que j'avais. Mais depuis, j'ai relativisé :)
Tu as raison, je vais davantage me renseigner là dessus. Merci de m'en avoir informé.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Ph Husson (site web personnel) . Évalué à -2.
Je comprends pas pourquoi tu acceptes DANE, et plus largement les DNS comme autorité.
Les noms de domaines sont même pires que des CAs comme autorité, car c'est l'argent/le premier arrivé premier servi qui décide qui a quel domaine, alors que pour les CAs, tout les domaines sont égalitaires et ont le droit à leur certificat personnel.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à 0.
Parce que bien que je loue un domaine à un registrar, j'ai le contrôle sur le serveur DNS.
Alors que quand tu loue un certificat, tu ne gère pas la CA.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par pasBill pasGates . Évalué à -2.
Il y a un jour ou il va falloir que tu t'achètes un bouquin et essaye de comprendre le concept de tiers de confiance.
Tu n'as visiblement absolument rien compris au concept qui régit le fonctionnement des CA et pourquoi il a une valeur.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à 0.
Oh, j'ai bien compris le principe de tiers de confiance.
C'est juste que j'ai choisi de ne pas adhérer à ce principe.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Le Gab . Évalué à 4.
Tu utilises une distribution Linux géré par un tier, voire des tiers, non?
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -5.
En effet, et je peux avoir confiance en ces tiers puisque j'ai accès au code source du système.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 15 février 2016 à 11:48.
Ha ha ha…
tu as accès un un code source.
tu n'as aucune idée du code source des binaires que tu as reçu.
bref, tu fantasmes sur une confiance que tu pourrais avoir, n'aimes pas les tiers, tout en les utilisant tout le temps.
Tu ne sais toujours pas de quoi tu parles (tu penses sérieusement pouvoir être sûr que le source fournis correspond au binaire fournis?)
Sérieux, informe-toi avant d'avoir tes idées sur ce qui est fiable ou pas.
PS : sans compter que tu as accès au code source mais que tu ne l'as pas lu.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -5.
Je m'attendais à ce genre de réaction jubilatoire.
Au même titre que tu ne peux pas garantir que le "tiers de confiance" ne va pas te refiler un certificat moisi (c'est déjà arrivé plusieurs fois, juste pour remettre les pendules à l'heure), je ne peux pas garantir que debian ne va pas me refiler un paquet binaire moisi.
Et au même titre que je ne lis pas les sources, tu ne vas pas sonner à la porte du présumé détenteur du certificat, n'est-ce-pas ?
À ma décharge, le principe même d'avoir accès au code source réduit déjà pas mal de risques de se faire refiler n'importe quoi (n'y a-t'il pas d'audit de code, particulièrement depuis les problèmes de openssl ? de cisco ? de juniper ?).
Si tu considère qu'il existe un risque que debian me refile un paquet binaire contenant du code pourri, tu es d'accord pour dire qu'une CA peut valider occasionnellement des certificats plus ou moins douteux. Tes contre-arguments ne valent pas grand chose…
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 15 février 2016 à 12:07.
Il valent exactement ce pourquoi ils sont : tu conspue des tiers de confiance tout en les aimant.
Ca montre tout le problème de ta logique.
Le système de CA ne sont pas parfaits (personne n'a dit le contraire), mais tu te trompes de "combat", et surtout tes argument sont juste rigolos (et donner ta confiance à Debian parce que tu peut lire le code source, désolé, mais c'est une notion tellement fausse qu'on ne peut te croire quand tu dis connaitre le sujet et donc être capable de proposer une solution, tu ne connais en fait rien en terme de notion de confiance)
Voit pas le rapport.
Debian peut mettre une backdoor autant que Juniper, et ça se verra autant (même si il y a un projet de reproductibilité pour justement pouvoir avoir plus confiance, mais ce n'est pas encore prêt)
Oui (PERSONNE ne dit le contraire, il te faudra combien de temps pour l'accepter?), et justement ça te décrédibilise.
Tu dis que c'est ex-aequo, mais tu veux en virer un et pas l'autre.
euh… Non, rien, continue dans ton délire, ce n'est clairement pas toi qui amènera un jour plus de sécurité à Internet.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -3.
Et toi tu me prête des mots que je n'ai jamais écris.
S'il n'y a que ça pour clore la discussion avec toi, d'accord, j'avoue, je n'y connais absolument rien. Je parle sans rien connaitre de la sécurité, de la confiance, ni de l'informatique, de la vie ou du monde. Je te laisse le privilège de nous montrer la voie vers une informatique de confiance.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -4.
Et c'est moi qui ai un problème de confiance…
Tu remets en question la confiance qu'on peut accorder au Logiciel Libre ? Sur LinuxFr ? Sérieusement ? Ben, éclaire moi, encore une fois, de tes lumières: pourquoi ne puis-je pas avoir confiance en mon système en ayant accès à son code source ?
Et cette fois, évite de ne pas répondre à une de mes questions directes, je te prie.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd (site web personnel) . É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 barmic . Évalué à 6.
Ceci n'est pas un problème pour les distributions sources :)
Non le vrai problème c'est qu'il y a beaucoup trop de code et bien trop complexe pour que ce soit intelligible par l'humain. Contribuer à un projet libre et intégrer une faille dedans c'est pas si compliqué que ça en a l'air. Déjà parce que seul un nombre limité de projet prennent en compte la sécurité et il y en a encore moins qui le font correctement. Si on ajoute à ça les différents dépôts de code peu sûre. Les machins à la cpam, pip, gem, goget,… qui n'utilisent pas les stratégies de signatures classiques ou qui sont trompeuses, la plateforme n'assurant aucune garantie sur le code et laissant cette charge à l'utilisateur et ce dernier utilisant ça comme s'il s'agissait des dépôts de sa distribution. Tout ça avec du LL à tous les étages, hein ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par groumly . Évalué à 0.
Sans meme parle de ca, openssh troue distribue par debian pendant 3 ans… Et encore si un mec etait pas tombe sur une collision par hasard, on aurait probablement toujours que 65k cles possibles.
La classe a dallas les audits du libre! With enough eyees, all bugs are somebody else's probleme.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -1.
Apparemment, pour polluer les commentaires, tu es plutôt éloquent. Mais quand on te pose une question, tu l'élude.
Je ne t'en veux pas, tu as une réputation à tenir, et je suis une proie facile. Fais-toi plaisir, c'est mon cadeau pour ce début de semaine :)
Il n'en reste pas moins que vu la verve avec laquelle tu défends tes opinions, j'aurai réellement voulu lire ce que tu avais à écrire à propos de ta remise en question de la confiance qu´on peut accorder à un Logiciel Libre.
À moins que c'était une phrase vide de sens, juste pour faire une phrase.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à -1.
J'avoue que vu que la question montre tellement d'ignorance sur le libre et sur le fonctionnement d'une distro binaire que je ne sais pas comment répondre, surtout par quoi commencer, c'est encore pire que SSL. plantage.
Si la question est sérieuse (ce que je ne pense pas vu les réponses déjà caricaturales dans le refus de réfléchir sur les CA), il faut commencer par lire sur comment on tu peux être sûr qu'un binaire correspond au source (en fait, tu affirmes que le source sert à quelque chose, donc tu devrais toi M'éduquer sur comment tu peux être sûr que le binaire correspond au source, perso moi je ne sais pas comment tu fis).
Bref, tu as fait 2 journaux qui se font démonter sans que tu réfléchisses dessus, donc je ne pense pas que tes questions sont pour avoir une réponse, et je n'ai simplement pas trouvé de côté marrant ou d'utile pour les autres (je pense qu'ils savent tous, car la on part dans la base de base) à répondre, je n'étais pas inspiré.
Je te propose de faire un journal "comment savoir qu'un binaire vient du source donné : parce que".
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à 0.
Sur les deux derniers journaux que j'ai écris, tu es venu me souffler dans les bronches dans… les deux derniers. Ne t'étonne pas que je n'accueille pas tes réponses à bras ouverts.
Et si tu avais un minimum de bonne foi, tu aurais noté qu'au contraire de ce que tu pense, je suis capable de remise en question, cf le commentaire sur DANE.
Mais bon, j'ai vu tes autres commentaires sur d'autres journaux, je ne le prends pas personnellement, tu semble être comme ça avec tout le monde. Si c'est ton but et que tu trouve ça "marrant", ça en fera au moins un que ça amusera. Personnellement, je ne suis pas là pour ça.
Et pour les autres visiteurs: désolé de ces échanges, je ne suis pas là depuis bien longtemps, je ne sais pas qui est qui. Mais une chose est sûre, c'est que je ne pendrais plus la peine de répondre à tes commentaires.
C'est un bon exercice pour la gestion des conflits, mais ça reste éprouvant. Une fois de plus, je ne suis pas venu là pour ça. J'ai plus intéressant à faire que passer mon temps à me défendre face à des attaques absurdes. Je préfère me consacrer aux réponses intéressantes et intelligentes.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par pasBill pasGates . Évalué à 1. Dernière modification le 16 février 2016 à 00:50.
Autant Zenitram (et moi, soyons honnète) a une tendance à être comment dire… direct qui pourrait certainement être améliorée, autant il faut que tu regardes ta manière d'arriver ici, poser une bombe, et être surpris qu'elle t'éclate à la figure.
De manière répétée tu as sorti des trucs complètement loufoques, et ta prose indique clairement que les commentaires que tu as recu en retour, tu n'en tiens pas compte, tu es toujours convaincu que ton "idée" est meilleure que le système actuel.
Ton truc sur le fait que le code est libre, donc "sûr" est une idée loufoque de plus, ce n'est absolument pas le cas pour plein de raisons, et visiblement tu ne t'en rend pas compte non plus.
Il y a un moment oû il faut arrèter avec l'arrogance, te rendre compte qu'il y a plein de choses que tu ne connais ou comprend pas (ce qui est normal, on est tous passé par là), et avoir l'humilité de demander, écouter, mettre des conditionels plutôt qu’asséner des affirmations sur un sujet que tu ne comprends pas totalement.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -1.
Pas du tout. J'espérais qu'on m'oppose des choses que je ne connais/maitrise pas, et ça a été le cas avec DANE, et j'en suis ravi. Mais parce qu'Aeris m'a présenté les choses sans me faire passer pour un "loufoque" comme vous dites, je l'ai accepté et intégré dans ma réflexion (ce qui ne s'est pas vu puisque j'ai passé mon temps à me défendre). Donc perte de temps, perte d'intérêt pour le sujet et je vous raconte pas mon estime de moi. Sérieux, faut que vous arrêtiez de vous en prendre aux gens comme ça. Si vous êtes tellement au dessus de tout ça, bah laissez le bas peuple dans son ignorance, qu'est-ce que ça peut vous faire ? Mais l'attaquer, quel est votre intérêt ? S'amuser à ses dépends ? À quoi bon casser un parcourt initiatique, un pèlerinage, des tentatives osées qui peuvent marcher avec un peu de couilles ?
Vous, comme tu dis, vous êtes directs. Franchement lourds. Et moi, je ne me laisse pas faire. Surtout quand on vient gueuler, et que quand je demande des explications on noie le poisson. Faut que vous admettiez que c'est une attitude franchement pas engageante, parce que ce que vous me reprochez à moi (ne pas me remettre en question) n'a pas l'air de vous avoir effleuré non plus. On peut demander à quelqu'un de faire preuve d'humilité quand on l'est soi-même, autrement on passe juste pour des gros cons.
Vous semblez être aigris, convaincu que rien ne peut venir d'esprits inférieurs aux vôtres. Que quelqu'un qui n'a pas au moins un doctorat n'est personne, et n'a rien d'intéressant à dire. Vous semblez maitriser tellement de sujets importants et techniques, vous pourriez en faire profiter les autres au lieu de leur balancer des os à ronger. On en reparlera, de l'humilité et de la capacité à se remettre en question. On a à apprendre de tout le monde, jeunes, moins jeunes, intelligents, génies, modestes.
C'est pas précisément ce que cherche le Libre à mettre en place ? Permettre à chacun d'apporter ses idées pour améliorer les grands projets ? Vous vous dites Libristes, mais vous parlez d'informatique de confiance, vous semblez défendre Google, facebook. Mais en fait, vous n'adhérez pas du tout à ces principes, n'est-ce-pas ? C'est juste pour travailler sur un marché de niche, choper un diplôme, et se faire un max de thunes parce que le Libre va rapporter dans les années à venir ?
Tous ces commentaires pour moi sont des commentaires de geeks aigris. Et c'est dommage, parce que si seulement on mettait à profit votre énergie qu'actuellement vous utilisez pour détruire les idées des autres…
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par pasBill pasGates . Évalué à -1.
Mais de nouveau, si tu étais arrivé en disant "les gars, j'ai une idée, ça m'a l'air de fonctionner mais je connais pas trop le sujet, vous en pensez quoi ?", on (en tout cas moi) aurait été bcp plus doux. Le problème est que tu es arrivé avec tes grands sabots, sûr de ton fait avec de grosses affirmations. Ça donnait une image d'arrogance, du gars qui croit avoir tout compris, et qui sort une solution complètement…loufoque.
Les explications je te les ai toujours données, que tu ne les aies pas compris c'est une autre histoire.
Je te l'ai dit plus haut, tu aurait proposé la même idée, mais en l'amenant avec des conditionnels, en précisant que tu n'es pas sûr de ce que c'est, etc… tu ne te serais pas pris la même volée de bois vert en retour.
Là tu divagues. Ce n'est pas parce qu'on a descendu ton idée ridicule en flamme qu'on fait ça avec toutes les idées de tout le monde. La tienne était largement pire que tout ce que j'ai pu lire comme idée depuis un moment, et était présentée de manière bcp trop affirmative pour être prise avec des pincettes. En sus, tu es revenu (dans ce journal) en disant assez clairement que n'était pas du tout convaincu par les 4235 personnes qui te disaient que tu étais dans le faux, et que par dépit tu passais a Let's Encrypt, paf, encore une couche d'arrogance en plus.
Oh mais je crois pouvoir dire de manière sûre que plein de gens ont bcp appris des sujets sur lesquels je suis un expert ici. Même si ce qu'ils ont appris allait le plus souvent à l'opposé de leurs notions préconçues sur un OS d'une boite qu'ils détestent de manière irrationnelle.
a) Je ne suis pas libriste, du tout
b) Ce n'est pas parce qu'on trouve ton idée ridicule qu'on défend FB/Google, il n'y pas que 2 options ici.
T'es gentil, ça fait 15 ans que je suis professionel dans l'industrie informatique et je me fous totalement du fait qu'un soft soit libre ou pas. Faut vraiment que tu arrêtes avec tes oeilleres et ta propension à parler de sujets auxquels tu ne connais pas grand chose.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -3.
Ben tu vois, c'est ça la différence qui nous oppose: moi, ça fait vingt cinq ans que l'informatique est ma vie, pas juste professionnelle. Et pour moi, le Libre est absolument fondamental. Pas seulement pour le Logiciel Libre, mais aussi pour ce que ça implique en terme de social, d'humain, d'intellectuel.
Je m'attendais à trouver des gens dans ce genre sur un site comme LinuxFr. J'aurai dû rester chez GNU.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par pasBill pasGates . Évalué à -2.
Ah ben effectivement, ce site n'est pas une secte, il y a des gens avec des opinions diffèrentes dessus. Faut aller ailleurs pour trouver des gens qui pensent tous d'une seule manière et qui sont tout le temps d'accord sur tout.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 3.
Ce n'est pas crédible.
Note : ce n'est pas parce qu'on passe 25 ans dans son bain que nager est sa vie.
Si tu le fais professionnellement, j'espère que ton employeur (si tu en as un) ne tombe pas ici, ni que tu fais directement affaire avec des clients en leur disant autant de contre-vérités.
Pour ça, il faudrait déjà savoir ce qu'est le libre (ce qu'il apporte, ce qu'il n'apporte pas).
Le libre, c'est le droit d'utiliser, étudier, modifier, copier. Quel rapport avec le social, l'humain, l’intellectuel? Tu ne mélangerais pas le libre avec autre chose?
Bon, admettons, tu fais du libre et de l'informatique depuis 25 ans. Par curiosité, parce que ta "page perso" avec 9 post de blog laisse sur la faim, si c'est le résultat de 25 ans d'informatique et de libre.
Si tu peux accepter un conseil : commence par te documenter, sérieusement (pas auprès d’intégristes du libre qui ont autant avec le libre que l'EI avec l'Islam, mais auprès de sources fiables) et considère que tu es tout tout début de l'apprentissage (donc n'apporte pas de solution, ça c'est quand on a étudié le sujet)
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 16 février 2016 à 08:17.
Euh… Qui fait 2 journaux avec des conneries énormes dedans, et sans se remettre en question quand on lui fait remarquer?
On a essayé, mais l'auteur du journal a un problème avec l'humilité et la capacité à se remettre en question.
Oui, on a apprendre. Mais on ne fait pas boire un âne qui n'a pas soif.
Le libre se fout de l'upstream, tu dis que le libre est ta vie donc tu devrais au moins savoir ça.
La, tu ne parlerai pas de communautaire plutôt?
Défendre? Où? On dit juste que tu proposes pire que eux.
Ha ha ha…
désolé, mais alors la tu essayes de nous faire rire le plus possible, je n'arrive personnellement pas à croire qu'il n'y pas d'humour derrière ce semblant de sérieux.
Non, parce que la, plus on pense que tu as tapé le plus loin possible dans les énormités, plus tu en sors.
J'imagine que ça t'amuse de balancer l'énormité qui fera le plus réagir, c'est dommage, parce que si seulement on mettait à profit ton énergie qu'actuellement tu utilises pour sortir les plus grosses énormités…
Note : "idées"? Où? Désolé, tu te fous de notre gueule, je me permet donc de faire tout autant, on joue au même jeu débile.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par pasBill pasGates . Évalué à 0.
Tu nous montres tous ces gens experts en sécurité qui font des revues de code, fuzzing, analyse statique, … des millions de lignes, milliers de projets, qui constituent la distrib Linux que tu utilises ?
Ah oui, pas possible, ça n'existe pas, quasiment personne ne le fait et seules les très gros projets ont les moyens de faire cela en partie.
Mince alors.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -1.
Juste pour recentrer le sujet parce que vous partez tous de travers là: je parlais de la confiance dans les CA qui a été ébranlée au fil du temps ; qu'en tant que libriste, j'aime faire les choses moi-même ; qu'en tant qu'humain je déteste rejeter sur les autres une faute dont j'aurai pu prendre la responsabilité ; qu'on perd le contrôle de ce qu'on a bâti ; que ça ne dérange personne parce que c'est Dieu Google qui a parlé.
Personne ne vous a demandé de tester mon propre niveau de confiance en des tiers. Ça me donne l'impression que vous n'êtes pas capables d'apporter une réponse constructive à "ma prose" sans aller chercher des artifices de comparaisons absurdes.
Tout cela est grotesque, et vous ruinez le fun qu'il y à partager et échanger sur Internet. M'étonne pas que vous ne vous émouviez pas que les relations sociales soient si pourries: c'est vous qui les pourrissez.
Je suis rentré, j'ai vu de la lumière, je me suis dis ça va être sympa ici, plein de gars comme moi qui s'échangent des idées autour d'une pinte, pour une fois que je sors de ma cave. En fait j'ai juste vu des mecs avec un sérieux déficit social, clasher tout ce qui bouge pour le plaisir.
Je me casse. La taverne d'en face sera peut être meilleure.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par pasBill pasGates . Évalué à 1.
Ben on te rappelle simplement que la confiance dans les CA, c'est pas forcément diffèrent que la confiance que tu donnes à plein d'autre entités. Cela a définitivement un rapport avec la choucroute. Tu nous sors une grande prose sur le problème soi-disant critique et horrible que sont les CA, et propose une étape extréme pour y remédier (qui ne fonctionne pas, mais passons outre, je parles d'intention), tout en ignorant un tas d'autre problèmes qui sont tout autant si ce n'est plus critiques d'un point de vue sécurité.
Il est largement plus simple d'insèrer une backdoor dans les nombreux projets libres qui va finir sur ta machine que piquer un certificat d'un site connu à une CA, bref si tu obsèdes sur la sécurité à ce point, tu vises le mauvais problème.
Ensuite si tu aimes faire les choses toi-même, que tu préfères vérifier les certificats à la main (en pratique tu ne peux pas mais tu peux rêver hein…), … ben c'est ton droit, fais seulement. Mais dés le moment ou tu mets ça en publique en disant que tout le monde devrait le faire et que c'est plus sur, alors que ce n'est absolument pas du tout le cas, tu invites les remarques sur le ridicule et la dangerosité de l'approche.
Ben non, le clash s'est fait surtout sur toi et ta manière d'amener ton idée, pas sur tout ce qui bouge. Pas spécialement de raison de faire de ton cas une généralité.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Frank-N-Furter . Évalué à 2.
It remains unclear why or how glibc maintainers allowed a bug of this magnitude to be introduced into their code, remain undiscovered for seven years, and then go unfixed for seven months following its report. By Google's account, the bug was independently uncovered by at least two and possibly three separate groups who all worked to have it fixed. It wouldn't be surprising if over the years the vulnerability was uncovered by additional people and possibly exploited against unsuspecting targets.
Depending on the time of day, the French go either way.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 1.
Je ne pensais pas forcément à des bugs amenant des trous de sécurité alors que plein de monde peut (le mot important est "peut") lire et comprendre le code. C'est encore un cas en plus (la croyance que parce que c'est libre les gens vont lire le code et en détecter les bugs avant les "méchants" a encore la vie dure parmi les gens aimant vivre que sur base de préjugés faux).
Je faisais plus référence à la croyance, on ne sait pourquoi, que parce qu'on file un code source x libre, le binaire fourni est exactement la compilation du code source x (et pas du code source y pas libre et ayant une backdoor en plus), que les gens soient sûrs (pas qu'ils pensent que c'est potentiellement ça, non qu'ils soient sûr et que ça soit leur "modèle de vie") de choses factuellement fausses et qu'un peu d'éducation sur le sujet le montrerai rapidement, personnellement ça me dépasse.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par barmic . Évalué à 3.
Et c'est eux (à qui tu fais confiance) qui choisissent la liste des CA qui, d'après eux, sont de confiance.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -3.
D'où l'idée de mon journal d'origine de dégager les CA.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 2.
Ce n'est pas une idée, juste le passé (avant les CA).
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par briaeros007 . Évalué à 2.
et toi tu pourrais lire les nombreux articles qui montre en quoi le modèle de "tiers de confiance" est tout autant de confiance que le modèle de "l'informatique de confiance" avant de dire qu'il a une valeur (autre que commerciale).
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à -1.
En attendant, il y a un truc qui ne marche pas, et un truc qui marchote.
Je préfère le truc qui marchote.
toujours à critiquer, sans proposer une meilleure solution (non, la solution de l'autre journal n'est pas mieux, c'est encore pire), encore moins la mettre en oeuvre (comme c'est bizarrre).
Différence entre belle théorie et la pratique.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par briaeros007 . Évalué à 2.
y'a un truc qui marche, mais qui n'est pas diffusé, et un truc qui marche pas (certificat comodo quelqu'un ? comment des pays du moyen orient ont réussis à intercepter des courriers de gmail ? ), mais qui est diffusé.
Tu préfères le truc diffusé au truc qui marche, car c'est moins galère pour ton utilisation de tout les jours.
Y'a pas de soucis, mais il ne faut pas être hypocrite pour pouvoir discuter des avantages et inconvénients des différents outils/méthodes
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 3.
Ce n'est pas le sujet (j'ai le contrôle sur mon serveur web et donc le contrôle sur le certificat SSL que je fournis, et? As-tu le contrôle sur le registrar qui est celui qui décide si il pointe ou pas sur tes serveurs DNS? Je ne crois pas…)
Quand je loue un nom de domaine, je ne gère pas le registar.
Bref, le gros soucis est que tu penses avoir la solution alors que tu ne connais déjà pas le problème. A mauvais diagnostic, impossible d'avoir un bon remède (sauf à jouer au loto).
La, on a surtout l'impression qu'un pré-ado ayant étudié 5 minutes un problème pense avoir la solution ultime à un problème qui fait chier des tonnes d'ingénieurs depuis des années.
Le pauvre est incompris… ou pas.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -1.
Heu, oui, mon registrar me permet de spécifier mes propres serveurs DNS. D'ailleurs, je ne suis pas certain qu'il y ait encore des registrars qui ne le permettent pas.
Ce n'est pas mon diagnostic qui n'est pas bon: le système actuel n'est pas satisfaisant. Ce n'est pas moi qui le dit.
L'idée que j'avance n'est peut être pas la meilleure, je n'ai jamais prétendu qu'elle l'était. Je n'ai jamais prétendu que c'était la seule.
Je ne doute pas un instant que d'autres se cassent les dents sur le sujet. Tu en fais partie ?
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 15 février 2016 à 08:56.
Tu peux essayer de comprendre la question?
Tu réponds complètement HS.
J'ai demandé si tu as le contrôle dessus.
Si il faut être encore plus précis : si ton registar décide de changer et de migrer sur ses serveurs DNS, tu peux l'en émpêcher?
Ton registrar te permet de spécifier tes propres serveurs DNS, merci de l'évidence, mais tu "oublies" de dire qu'il peut te virer l'option quand il veut, et qu'il peut mettre ses DNS et pointer sur ses serveurs web quand il veut. Ton registar contrôle tout, aïe. E nfait c'est même pire que SSL et les CA, car impossible de mettre de l' "auto-signé" dedans (le domaine .42 n'étant pas trop accepté par les navigateurs).
Merde alors, te voila sous la coupe d'un tiers de confiance, exactement comme les CA que tu critiques… Ca doit te faire un choc, te voila informé que tu es dépendant à la fois de ton registar et de ton CA.
Mais alors, pourquoi ce caliméro dans le journal précédent et ce journal? Pourquoi alors avoir dit que c'était "par dépit" que tu passais à Let's Encrypt?
Tu dis tout et son contraire en très peu de temps.
Bref, tu n'y connais pas grand chose, tu n'a même pas les idées claires sur ce que toi veux, mais veut changer le monde (que tu ne connais pas).
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Richard Dern . Évalué à -3.
Tu veux vraiment qu'on pousse ce raisonnement plus loin ?
Tu vas forker un projet chaque fois qu'une ligne de code te convient pas ?
Si mon registrar fait un truc qui me plait pas, je change de crémerie. Oui, le même principe s'applique à une CA. Mais perso, je préfère faire les choses moi-même. Quand il sera possible d'être son propre registrar, je serai mon propre registrar. En attendant, oui, je dois me contenter de louer mon domaine. Par contre, on a les outils pour faire ses propres certificats. Autant les utiliser.
Et au passage, tu mélange torchons et serviettes. Un registrar, on lui confie un nom de domaine. Une CA, on lui confie le chiffrement. C'est quand même pas la même chose.
Ça fait deux fois que tu utilise ce terme. Sans vouloir te commander, cite moi une ligne qui te donne cette impression parce que honnêtement, je ne vois pas.
Je réponds à cette question dans mon article.
Et toi tu cherche à m'infantiliser en étant en plus condescendant, sans même avoir la moindre petite idée de mon parcours informatique, ou même de vie. Je t'invite à lire d'autres commentaires plus bas dans ce journal pour voir comment on fait pour répondre à quelqu'un de façon constructive et intéressante. Je n'envisage plus de te répondre tant que tu seras aussi désagréable.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd (site web personnel) . É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 Richard Dern . Évalué à -1.
Oui, exact, je n'ai pas réfléchi à ça.
Ce qui renforce encore l'inexactitude de sa comparaison.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Ph Husson (site web personnel) . Évalué à 3.
Tu as les outils pour faire ton propre registrar.
Juste, de la même manière que pour un certificat, les gens devront configurer leur machine pour l'accepter.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par gouttegd (site web personnel) . É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 briaeros007 . Évalué à 1.
c'est triste d'oublier la brique de base qui est DNSSEC et qui conditionne la sécurité …
Et c'est bien plus facile de valider la sécurité de SES records, validés par SA clé, que la sécurité de tout un CA, où la comprimission d'un seul domaine détruit la confiance de l'ensemble de la chaine.
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par Zenitram (site web personnel) . Évalué à -2.
C'est plus facile, mais les gens ont du mal avec DNSSEC.
tous ces idiots d'admins, vraiment… Ou alors ce n'est pas plus facile, encore un fantasme.
(désolé, mais DNSSEC est notoirement connu pour ne pas être ami avec le mot "facile")
[^] # Re: dommage de ne pas s'être renseigné plus en avant...
Posté par briaeros007 . Évalué à 5.
Je sais qui est ton "notoirement", mais chez moi c'est facile, tout comme IPv6.
Oui ca change, mais légèrement différent != difficile.
# Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . Évalué à 8. Dernière modification le 15 février 2016 à 00:03.
Sois rassuré sur ce point, Google ne peut tout simplement pas virer les connexions qui utiliseraient un certificat auto-signé. Ils ne peuvent même pas bloquer un certificat qui ne correspondrait pas au domaine en question.
Parce qu’on ne sait pas valider un certificat pour STARTTLS.
Et que les RFC sont très claires (par exemple RFC 7672, on ne doit chercher à vérifier ni la chaîne de certification ni le domaine).
Le domaine tout simplement parce qu’on ne sait pas décider quoi valider.
Comme on passe par les MX, un domaine @xxx.fr peut avoir un MX en yyy.fr.
On s’attend à quoi quand on va lancer la connexion STARTTLS dans le certificat ? xxx.fr ou yyy.fr ?
Se pose aussi le problème (et en particulier pour Google lui-même justement) qu’un même serveur mail peut servir X domaines différents (c’est le cas des serveurs de Google, ils hébergent @lemonde.fr par exemple), et que le certificat présenté peut ne pas être valide pour le domaine du destinataire (si tu écris à @lemonde.fr, tu recevras un certificat en mx.google.com).
Et la chaîne de confiance non plus n’est pas vérifiable. Le RFC 7672 indique bien
Ici, c’est surtout parce que SMTP est opportuniste. Si l’établissement de la connexion TLS échoue, l’émetteur retente avec une connexion plain/text.
On a donc intérêt à être le plus laxiste possible et à autoriser tout et n’importe quoi (y compris SSLv2/SSLv3, RC4, DES ou pire, un certificat expiré, de domaine invalide ou de CA inconnue) afin d’obtenir au moins la sécurité du tuyau (la sécurité du destinataire n’est pas possible avec SMTP sans DNSSec et TLSA) plutôt que pas de sécurité du tout.
Google ne peut donc pas se permettre de blacklister un serveur qui aurait un certificat invalide (self-signed ou domaine invalide).
Let’s Encrypt n’a aucun intérêt ici, la chaîne de validation ne peut ni ne doit être vérifié.
Un certificat auto-signé fera parfaitement l’affaire sans diminuer la sécurité, sauf à intégrer DNSSec et DANE/TLSA, mais alors Let’s Encrypt devient un enfer sur Terre, puisque RFC 7672 indique qu’on ne peut pinner que sur le certificat ou sur la clef (CA ou intermédiaire explicitement interdits sur SMTP), qui sont par défaut renouvelés tous les 90j et posent donc de gros problèmes d’intégration avec DNSSec.
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Richard Dern . Évalué à 3.
Merci pour ces précisions très instructives.
Me voilà quelque peu rassuré sur ce point.
[^] # Re: Google ne peut pas exclure les self-signed
Posté par briaeros007 . Évalué à 1.
Je suis entièrement d'accord avec toi, mais je vais couper les cheveux en quatres quand même :
Dans ce cas on utilise les extensions X509 et on applique un Subject Alternative Name :)
(Ca demande de refaire le certif à chaque fois qu'un nouveau domaine est accepté)
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 15 février 2016 à 11:29.
Oui mais ça n’a aucun intérêt en terme de sécurité.
L’interdiction de vérifier la chaîne de certification fait que n’importe qui peut fournir un certificat contenant un CN ou SAN valide pour le domaine en question (et conduira au mieux à renvoyer en plain/text par derrière si tu fais la vérification du CN/SAN, ce qui est encore pire…).
[^] # Re: Google ne peut pas exclure les self-signed
Posté par KiKouN . Évalué à 2.
En terme de sécurité, cela permet d'éviter l'écoute passive (sniff simple). Mais pas l'écoute active où il faut mettre en place quelquechose (mitm ou autre). C'est pas top mais mieux que rien.
J'ai déjà vu sur des serveurs vérolés des "ngrep pass". Cela aura au moins le mérite de ne pas se faire piquer un mot de pass aussi bêtement.
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . Évalué à 2.
Une attaque passive n’est pas facilitée ou non par le CN ou SAN du certificat. Le simple fait d’avoir du chiffrement suffit (et du coup il vaut mieux ne pas faire de vérification et avoir une couche de chiffrement que de faire la vérif et de fallback en clair).
Si on est actif, SMTP est fucked de base :
[^] # Re: Google ne peut pas exclure les self-signed
Posté par claudex . Évalué à 6.
Pas convaincu, il y a vraiment des algos trop faciles à casser pour ne pas les virer, ça donne juste un faux sentiments de sécurité. Qu'on soit plus tolérant qu'en HTTPS, je comprends, mais sinon il vaut mieux faire un fallback en clair, quitte à avoir une alerte à ce niveau pour s'en rendre compte.
Il y a DNSSEC pour ça
Si tu n'as pas confiance dans ton lan, ce n'est pas SMTP le problème.
« 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: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . Évalué à 1.
Le problème est que justement, on n’a AUCUN alerte.
Et il vaudra toujours mieux avoir du chiffrement, aussi pourri soit-il que pas de chiffrement du tout.
Oui, mais combien le déploie ?
Là on cause MTA vers MTA, donc c’est tout sauf du LAN.
La NSA s’amuse à faire ce genre de truc niveau réseau mondial.
[^] # Re: Google ne peut pas exclure les self-signed
Posté par claudex . Évalué à 2. Dernière modification le 20 février 2016 à 17:21.
Ça, ça ne dépend que de toi. Par exemple, Google prévient quand il ne sait pas faire de TLS (enfin, c'est en cours de dépoiement).
Donc, pourquoi tu parle de ARP poisining ?
Qu'ils interceptent le trafic avec l'aide des transitaires, je veux bien. Mais qu'il viennent faire de l'ARP poisining chez moi, j'ai comme un doute.
« 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: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 20 février 2016 à 17:41.
C’est une rustine qui n’a aucun sens technique.
Tu ne peux PAS savoir à l’avance si chiffrement il y aura ou non.
Ce n’est pas parce que le message précédent a été chiffré que le tien le sera.
Tu peux tomber sur un MX différent, non sécurisé.
Tu peux tomber sur un bout de réseau soumis à STARTTLS-drop (par exemple via un routeur turc) alors que les précédents étaient clean.
Tu peux tomber pile au moment où les admins sys du destinataire se sont gauffrés sur la config du serveur, en ont mis un nouveau mal configuré, ont une panne qui fera que tu passeras sur leur secondaire bien moins sécurisé, etc.
Bref, ce n’est pas parce que tu vois un cadenas rouge que ça partira en clair, et inversement un cadenas vert ne te garantit absolument pas que ça sera chiffré.
Le seul moyen de réellement t’assurer de la sécurité… c’est d’avoir déjà envoyé ton mail !
Parce que tu peux faire du ARP poisining même en dehors de ton LAN ?
Turmoil https://nsa.imirhil.fr/pages?filter=turmoil&size=10
Turbine https://nsa.imirhil.fr/pages?filter=turbine&size=10
Discoroute https://nsa.imirhil.fr/pages?filter=discoroute&size=10
Quantum https://nsa.imirhil.fr/pages?filter=quantum&size=10
Foxacid https://nsa.imirhil.fr/pages?filter=foxacid&size=10
[^] # Re: Google ne peut pas exclure les self-signed
Posté par claudex . Évalué à 3.
Comment ? Parce que par définition, l'ARP ne sort pas du LAN.
Aucun de ces projets ne parle d'ARP, sauf si j'ai loupé un truc.
« 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: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 20 février 2016 à 21:08.
L’ARP ne sort pas du LAN, mais le poisonning peut venir d’en dehors du LAN.
Ce n’est pas de l’ARP spoofing à proprement parlé, mais ça fait des trucs tout aussi dégeu sur plus ou moins toutes les couches du réseau (TCP, DNS, routage, web, JS…).
J’ai aussi oublié, dans le cadre de Google justement, le programme MUSCULAR, et sa célèbre image du bidouillage de la NSA sur le LAN de Google en vue de se placer sur les nœuds d’interco des datacenters (corrigé depuis par Google via du chiffrement y compris en échange interne). Donc non, ton LAN n’est pas plus safe que le reste :)
[^] # Re: Google ne peut pas exclure les self-signed
Posté par claudex . Évalué à 3.
Déjà, ce n'est pas un cas courant qui se produit avec des configurations courantes, il faut une machine dans le LAN pour que ça vaille la peine.
Bien sûr qu'il y plein de moyen, c'est pour ça que j'ai réagis uniquement sur le point de l'ARP qui n'est pas utilisé pour ces attaques.
Encore une fois, ça ne parle pas d'ARP poisining, il s'agit juste d'écouter entre deux liens.
Mouais, tout le monde n'a pas un LAN aussi grand de Google, c'est souvent relativement aisé de faire l'inventaire. D'ailleurs, je n'ai vu de mention que c'était dans un LAN, ça peut très bien être routé du côté de Google et ça reste la même chose pour la NSA.
« 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: Google ne peut pas exclure les self-signed
Posté par Ambroise . Évalué à 1.
Remarque: tu peux parfaitement ne pas renouveler ta clé tous les 90 jours. Mais pour cela, il faut utiliser un autre client que celui proposé de base avec Let's encrypt. Et dans ce cas, tu pourras faire des truc chouette avec DNSSEC (et/ou HSTS et HPKI) sur la clé.
# cacert ?
Posté par karteum59 . Évalué à 6.
Puisqu'on parle de CA : désolé de relancer le débat avec une question de débutant alors que c'est peut-être évident pour plein de monde, mais 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 ? En particulier, je lis des choses comme
=> Lapin compris en quoi "la fenêtre est ouverte 1 mètre plus loin"… (à mon niveau, ce que j'ai vu au FOSDEM c'est que effectivement ils vérifiaient sérieusement l'identité des gens).
Question subsidiaire: en quoi Let's Encrypt est-il mieux que cacert ?
[^] # Re: cacert ?
Posté par gouttegd (site web personnel) . É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: cacert ?
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 15 février 2016 à 17:03.
Trolleur!
En résumé grosse maille (et j'assume, je caricature, quoique pas tant que ça):
- Un problème de communication
-- Dire que le système de CA c'est de la grosse merde (note : je ne remet pas en cause que c'est de la merde, mais pour le moment c'est la merde qui pue le moins donc on fait avec, et CACert ne résout rien de la puanteur du système) par design puis proposer une CA, c'est risible pour les utilisateurs potentiels
-- Dire que les autres CA et les navigateurs sont des merdes en sécurité, que eux ils savent trop plus mieux bien que tous les autres ce qu'il faut faire en sécurité, et ensuite demander à ces dernier d'être acceptée comme CA digne de confiance, n'est pas forcément la meilleure méthode pour se faire acceptée.
- Un problème technique
-- Faire chier les demandeurs avec l'équivalent (voir pire car pas toujours du monde près de chez toi alors que les autres CA font à distance) de ce qu'il faut d'un certificat EV (validation étendue) pour ensuite te filer un certificat DV (de base), ça cloche quelque part
-- A ma connaissance ils sont super à la bourre techniquement (SHA-256, CT Certificate Transparency etc…)
-- Refuser un audit de sécurité par tes pairs, pour avoir autre chose que "promis on fait de la sécu, ayez confiance", ça ne donne pas confiance (ni aux utilisateurs ni aux navigateurs web)
-- Avoir un certificat signée par une CA pas dans les principaux navigateurs revient à avoir un certificat auto-signé (d'une pourquoi alors se faire chier à faire signer le certificat, et de deux tu peux lire ce que les gens pensent de l'auto-signé dans les commentaires des journaux de l'auteur du journal)
- Un problème financier
-- Être incapable de récupérer ~200 k$ / an mondialement (ça en fait des donneurs potentiels) pour un truc de ce type, c'est pas plus rassurant sur la capacité de l'équipe à tenir dans le temps. (pourquoi 200? de tête il faut payer entre 50 et 100 k$ / an / entreprise pour être dans IE ou Safari)
Sachant que chaque différent problème a un impact sur l'autre, l'ensemble est… (censuré ;-) ).
Normal que tu ne comprennes pas, personne à part eux ne comprend. un certificat DV (celui de base) a pour but de vérifier que le domaine atteint est celui visé. Pour ça il suffit d’envoyer un mail au webmasteur (adresse email dans le whois du domaine). On se fout de savoir "tes papiers d'identité et la correspondance de la photo avec ton visage." Ils proposent une sécurité en plus pour une confiance en plus, OK, mais c'est… En plus? Il faut déjà faire la base non? (comme être dans les navigateurs).
Il créent une "super toile de confiance avec vérification d'identité", mais personne dans les navigateur (ni Debian, tu parles d'une honte, être viré de Debian très au fait des libertés, faut le faire quand même dans le niveau de confiance bas…) n'a confiance en eux. Et ils ne se posent aucune question en allant au FOSDEM faire des signing party? euh…
Même les admins LinuxFr ont abandonné, je te laisse en déduire le niveau du problème.
Note : oui, je sais, il reste des adorateurs de CACert ici, désolé d'être factuel et de ne pas mettre les problèmes sous le tapis juste parce que ça se dit "tourné vers la liberté", la personne a demandé ce qui cloche, "rien, on est trop géniaux et les autres sont des cons" n'est pas une réponse pertinente.
Tout ce qui est écrit au dessus (problèmes de sécurité, confiance, finances), Let's Encrypt le résout (plus d'experts en sécurité, plus d'audit par ses pairs, engagement des navigateurs, financement sécurisé pour les prochaines années).
Let's Encrypt, c'est CACert au niveau du prix (son seul avantage par rapport à d'autres CA vu que CACert ne résout aucun problème des CA) sans les inconvénients.
Prenons donc Let's Encrypt et laissons mourir CACert (je pensais CACert mort mais j'ai aussi entrevu le stand au FOSDEM, certes, mais on s'approche de la nécrophilie)
PS : pour ceux qui me voient en adorateur des CA, rappel. J'ai pris du temps autant pour expliquer un problème des CA autant que pour expliquer le problème CACert, alors merci de ne pas partir dans le délire "tu les detestes bla bla bla", tout ce que je dis est factuel (vous pouvez expliquer en quoi ce serait faux), et je base mon explication sur une analyse, je me fous de qui aime ou pas tel truc (je m'intéresse au résultat) et j'ai pris le temps d'écrire pour expliquer le problème (pourquoi il faut éviter la chose), pas pour taper sur CACert gratuitement (je me fous complet de CACert l'entité, si ils proposent quelque chose de correct je dirai que c'est correct).
[^] # Re: cacert ?
Posté par karteum59 . Évalué à 3.
OK, donc si je résume
OK ça je peux le comprendre…
Bof, peut-être, mais ça n'explique pas en quoi CAcert est catastrophique ou en quoi "la porte est blindée et la fenêtre est ouverte" ni pourquoi ils se sont fait virer de Debian et n'ont pas réussi à se faire intégrer dans les CAs de Mozilla/Chromium/… Je jugerais au contraire plutôt ça positivement non ? (et qui peut le plus peut le moins…)
Il y a vraiment eu refus, ou bien déficit de financement ?
Oui mais en même temps ma question de départ c'était : "pour quelle raison Mozilla (et autres) ont-ils refusé de les intégrer ?" et non "en quoi cacert est-il moins bien que X pour l'utilisateur" ? tu le répètes à plein de reprises "personne dans les navigateur (ni Debian, tu parles d'une honte, être viré de Debian très au fait des libertés, faut le faire quand même dans le niveau de confiance bas…) n'a confiance en eux (…)" mais sans expliquer pourquoi, et encore plus loin à ma question "en quoi Let's Encrypt est-il mieux que cacert ?": tu réponds la même chose "c'est supporté par les navigateurs". OK mais pourquoi cette différence de traitement ? pourquoi est-ce que "personne n'a confiance en eux" ? (Let's Encrypt est supporté par la fondation Mozilla donc évidemment supporté par le navigateur eponyme, mais je ne vois pas ça comme un avantage technique mais comme une conséquence "politique" logique ! Du coup encore une fois ma question concerne plutôt : quels sont les détails techniques/de communication / politiques qui ont entrainé la marginalisation de cacert ?)
Jusque là je n'ai relevé que deux points factuels/techniques
=> est-ce que ça résume toute l'histoire ou est-ce que j'ai loupé des trucs ?
[^] # Re: cacert ?
Posté par Zenitram (site web personnel) . Évalué à -2.
Tu fais comme si c'était mineur
Ce n'est pas bof
Refus. Ils ont commencé, Mozilla était semblait être ok pour faire gratos (et Debian l'avait gratos), et ils ont retiré la demande.
Tu plaisantes? Tu ne vois pas le lien entre les deux?
ben si. J'ai pris le temps d'expliquer, mais la réponse semble ne pas te convenir.
Aucune différence de traitement.
(par exemple, si un CA n'éprouve pas le besoin d'être dans les navigateurs, c'est quand même gênant non? Est-ce la faute des navigateurs?)
La, il faut que tu lises toute la prose sur CACert, mais le résumé t'a été donné.
Tu as loupé tout ce qui est écrit dans le commentaire auquel tu réponds, pour en extraire que 2 trucs dont 1 hyper mineur. Euh…
Si tu ne veux pas l’analyser car ne répond pas comme tu voudrais entendre, ça ne changera pas les faits.
Bon, désolé, je croyais que la question était sérieuse, j'avais répondu sérieusement et me suis trompé de niveau de discussion et j'ai donc perdu mon temps à être sérieux, je repasse en mode rigolo (faut vraiment pas être sérieux ici, on te fait comprendre que ça sert à rien)
[^] # Re: cacert ?
Posté par karteum59 . Évalué à 2.
OK, mais ça semble étrange quand même… Il n'y avait vraiment aucune autre contrepartie demandée par Mozilla qui rendait le truc impossible ? On a des liens où ils expliquent le pourquoi de leur refus ?
cacert est moins bien que les autres pour l'utilisateur précisément parce qu'ils ne sont pas inclus dans les navigateurs. On est bien d'accord et il n'y a pas débat là dessus. Mais ce n'était pas ma question.
Je le répète : ma question était "pour quelle raison Mozilla (et autres) ont-ils refusé de les intégrer ?". J'ai compris qu'ils avaient refusé un audit. OK donc poursuivons : pourquoi ont-ils refusé un audit ? Est-ce que c'est uniquement parce que "ils sont à la bourre techniquement" ?
Tu as expliqué qu'ils étaient à la bourre techniquement et avaient refusé un audit, et qu'ils communicaient mal. OK. ça n'explique pas pour autant pourquoi ils ont refusé un audit (c'est quoi les contreparties / leurs arguments pour justifier leur refus ?). La dette technique est-elle si large pour qu'ils refusent un audit ? est-ce ce point qui fait que "personne n'a confiance en eux" ? pourquoi d'après toi "ils refusent d'être dans les navigateurs" ?
Donc pour toi, l'équipe cacert "n'éprouve pas le besoin d'être dans les navigateurs" ? C'est vraiment une situation choisie par l'équipe cacert ? (oui j'avoue que j'ai du mal à croire ça, m'enfin…)
"toute la prose" == précisément, si tu as des liens…
Eh non, si on enlève ce qui relève de ton avis, je n'ai rien trouvé d'autre qui explique pourquoi cacert refuse un audit / "ne souhaite pas" être inclus dans les navigateurs / "personne n'a confiance en eux". Donc ça se résume en 1°/ ils sont à la bourre techniquement, 2°/ ils refusent un audit, 3°/ ils communiquent mal. C'est peut-être suffisant pour ne pas avoir confiance en eux à ce stade, mais est-ce vraiment insoluble, pour peu qu'on prenne le temps de comprendre où ça coince ?
Eh bien si, la question était sérieuse. J'ai un compte cacert (créé au FOSDEM) que je n'ai à ce jour jamais utilisé (précisément parce que "ça ne sert à rien" tant que ça n'est pas supporté par les navigateurs). Je trouve que vérifier sérieusement l'identité physique des gens est quelque chose de plutôt positif pour un CA, mais je n'ai pas d'avis au delà de ça (mais libre à toi de ne plus répondre et rester "en mode rigolo" comme tu dis…)
[^] # Re: cacert ?
Posté par gouttegd (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 0. Dernière modification le 16 février 2016 à 08:34.
1/ (…) while we propagate our own root. c'est en cours.
2/ Mozilla et Google en sponsor, je crois qu'ils ont eu un mot à dire dessus ;-).
Plus sérieusement, IdenTrust ne fait pas ça "parce qu'il a envie", car joue sa crédibilité dessus, donc si il a signé Let's Encrypt, c'est que la sécurité doit être assez bonne.
Et vu autrement, on peut dire aussi que c'est parce que Let's Encrypt voulait être accepté, au contraire de CACert qui n'en fait pas une priorité.
Si il n'y avait que ça comme problème avec les CA… Mais on a pour le moment rien trouvé de mieux (qui marche, hein), donc on fait avec (une petite sécurité comme avec les CA est mieux que rien du tout comme avec Richard Dern ou CACert)
[^] # Re: cacert ?
Posté par gouttegd (site web personnel) . É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 (site web personnel) . É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 (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 1. Dernière modification le 16 février 2016 à 10:49.
Faut arrêter les conneries : d'accord les CA ne sont pas terribles, mais dire que ça n'apporte aucune sécurité est du mensonge (il y a un différence énorme quand même entre signé par soit même et signé par une CA reconnue comme relativement fiable par ton navigateur ou OS, nier cette différence et dire que les CA accepteront Mallory tranquille est du pur troll)
Ca dit au moins que c'est dans la toile de confiance (pas parfaite, mais qui en pratique marche, même pour Google car les faux certificats ont été détectés et neutralisés)
Et à défaut de tout changer, on ajoute des choses comme Certificate Transparency pour rajouter encore plus de confiance (si tu veux faire des exemples personnels, ma transparence est la, mais on peut aussi parler de la transparence de LinuxFr depuis qu'ils ont abandonné CACert).
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é.
Tu plaisantes la? 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…
En pratique, les CA font le taf bien mieux que tout ce qu'on a imaginé pour le moment, et dire que c'est pareil que auto-signé est injuste.
Je te défie de faire accepter par les navigateurs un certificat pour mon domaine qui serait "elles ne servent à rien d’autre aujourd’hui qu’éviter les messages d’avertissements" (j'imagine toutefois que tu n'es pas de la NSA, après si on parle de la NSA capable de faire pression sur les CA, c'est autre chose, bien autre chose…)
[^] # Re: cacert ?
Posté par gouttegd (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 0. Dernière modification le 16 février 2016 à 11:26.
Limiter à 3 cas plutôt que 3 millions, je trouve ça déjà pas mal.
Et encore une fois, Google et compagnie essayent de trouver mieux. Si tu penses savoir faire mieux, n'hésite pas à les conseiller. Mieux, hein, pas un truc théorique qui ne marche pas en pratique.
Euh… J'avais compris!
Je répond comme exemple que justement tu surestimes le besoin de sécurité.
J'ai utilisé les mails non chiffrés pour négocier des contrats à 7 chiffres, et ça n'a posé problème à personne (et je parie que les concurrents en lices n'ont jamais eu accès aux autres offres).
Bref, ton "besoin" de super sécurité est pour des montant plutôt à 9 chiffres (et encore), soit pas très courant.
Ca marche très bien aussi contre mon FAI, les mafias, et en fait tout ce qui n'est pas étatique.
Si tu es en Iran et que ton certificat google.com est signé par le gouvernement Iranien (tu as viré ce CA en qui tu n'as pas confiance), ça marche aussi direct (pas de première victime), et ça ne se fera pas souvent (Chrome pourra très bien virer la CA devant ça), et en plus maintenant on a la certificate pinning pour Google, bref ça en fait des outils.
C'est déjà BEAUCOUP.
[^] # Re: cacert ?
Posté par gouttegd (site web personnel) . É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 Aeris (site web personnel) . Évalué à 2.
Dans le cas de SMTP (et uniquement dans ce cas), les CA sont sans intérêt.
La présence des MX et de STARTTLS, qui ne sont PAS authentifiés (sauf si MX protégé par DNSSec ET MTA émetteur vérifiant DNSSec ET ne fallbackant pas en clair en cas d’erreur, soit 0.0000001% des cas), casse toute possibilité de confiance en SMTP+STARTTLS. Le seul intérêt est de chiffrer (un tiers autre que le serveur en face n’accédera pas aux données), non d’authentifier (je cause avec le bon tiers).
Si tu es en position de faire du MITM, alors tu ne t’attaqueras pas au certificat, mais tu usurperas un MX ou tu vireras STARTTLS (93% du trafic SMTP, y compris vers Google, est downgradé en plain/text si tu es en Turquie par exemple).
[^] # Re: cacert ?
Posté par groumly . Évalué à 1.
Et comment tu fait pour faire confiance au chiffrement si tu ne garantit pas que la personne qui t'envoit la cle est la bonne?
TLS a besoin des 2 pour marcher, Le but c'est de creer un canal de communication sur dans un reseau pas sur du tout. Ca commence par garantir a qui on parle (via des tiers de confiance) et ensuite enchanger des cles de facon fiable entre 2 personnes qui se font confiance.
Si t'as psa la premiere etape, la deuxieme ne sert pas a grand chose.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: cacert ?
Posté par barmic . Évalué à 4.
L'AC racine peut en principe poser son veto (je ne sais plus si elle est en mesure de révoquer unitairement un certificat d'une AC intermédiaire, mais elle peut au moins révoquer toute l'AC) quand elle le souhaite c'est un contrôle tout de même important.
Après il y a pleins de cas où les listes de révocations ne sont pas vérifiées…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: cacert ?
Posté par gouttegd (site web personnel) . É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 barmic . Évalué à 3.
Je trouve ça dommage. Je crois que c'est tout de même utilisé dans certains contexte. Moi je m'en suis servis avec des certificats dans des cartes d'accès et je crois que la Belgique s'en sert pour ses cartes d'identité numérique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Drôle
Posté par Physche . Évalué à 2.
Moi je trouve ça drôle que Google impose aux émetteurs d'e-mails de chiffrer la connexion au serveur SMTP de Google alors que les e-mails eux mêmes restent en clair et visibles par Google.
Comme si c'était gênant pour Google que d'autres fournisseurs de services aient également accès au contenu de ces e-mails.
En plus, ils ont le culot d'écrire "did not encrypt this message" dans leur avertissement, alors que c'est la connexion au serveur SMTP de Google qu'ils demandent à être chiffré. Le message, lui, restera bel et bien en clair de toutes façons.
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 15 février 2016 à 19:23.
Pourquoi?
Oui, et si tu as une meilleure solution qui marche (non, PGP ne marche pas la dessus) avec un webmail sans faire confiance à l'hébergeur de mail, on prend. en attendant, la réalité est que ça ne marche pas.
Ce n'est pas le sujet, mais bon j'imagine que tu veux juste troller.
Si tu ne veux pas troller, c'est pour éviter les MITM et autre sniffers comme… L'objectif de LinuxFr quand ils font du HTTPS, tu veux dire que LinuxFr te fait rigoler?
Oui, et c'est pas le problème soulevé. Et?
si tu n'as pas confiance en ton hébergeur, pourquoi ne pas en changer?
[^] # Re: Drôle
Posté par zurvan . Évalué à 1.
j'ai vu un nouveau petit cadenas rouge lors de la rédaction (depuis gmail) d'un message vers un utilisateur rebelle, qui n'utilise pas les services de google. J'ai été un peu attéré de lire ça :
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Drôle
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 16 février 2016 à 13:56.
qui n'utilise pas le chiffrement comme toute bonne pratique en 2016 (et avant).
Que vient faire "les services de google" dans ton histoire? rien, à part que tu veux cracher sur google mais qu'il semble que tu es en manque de raisons valables.
Ici, le fautif est alice.it, et seulement lui, aucun lien avec Google.
Google ne fait pas attention à la sécu, c'est un connard
Google fait attention à la sécu, c'est un connard
Dans tous les cas Google perd avec zurvan, en fait c'est voulu.
Perso, bien que le message soit limite, ok, j'ai plutôt été atterré de voir cette attaque gratuite contre Google. Après, ce genre de chose (mentir pour pouvoir cracher sur quelque chose) ne devrait pas me surprendre, certes…
[^] # Re: Drôle
Posté par briaeros007 . Évalué à 7.
moi, admin tout seul dans mon coin qui n'adhère pas aux "cloud" et héberge mon propre serveur de mail, n'ai pas de petit cadenas rouge lorsque j'envoie un mail à google.
DKIM -> protocole ouvert et standard
SPF -> protocole ouvert et standard
STARTTLS -> protole ouvert et standard.
Les demandes de googles sont légitimes. J'ai envie de dire "enfin un qui fait quelque chose de bien".
Pour info, les microsoft &co n'hésites pas à te mettre en blacklist sans raison (enfin si, tu as une ip qui ne leur convient pas, car celle d'un client de FAI, donc tu n'as pas le droit de faire de l'autohébergement…)
[^] # Re: Drôle
Posté par Nairwolf . Évalué à -3.
J'ai aussi constaté ce petit cadenas avec mon adresse Gmail. J'aimerai mieux comprendre ce que cela signifie. Effectivement, le message n'est pas chiffré puisqu'il est disponible sur un hébergeur et accéssible avec le webmail Gmail.
Tu dis que c'est la connexion au serveur SMTP de Google qui est chiffré (dans le cas où le cadenas est vert) ? Ce n'est pas normalement ce que j'ai lorsque je me connecte sur mail.google.com ?
[^] # Re: Drôle
Posté par gouttegd (site web personnel) . Évalué à 5. Dernière modification le 16 février 2016 à 20:01.
La connexion est chiffrée lorsque ton client mail se connecte au serveur SMTP d’expédition de Google pour soumettre un mail à envoyer à un correspondant. Mais ça ne concerne que le premier tronçon du trajet (entre ton ordinateur et Google).
Sur le tronçon suivant, lorsque le serveur de Google établit une connexion avec le serveur du destinataire, la connexion n’est pas nécessairement chiffrée. Elle ne peut l’être que si les deux extrémités du tronçon permettent le chiffrement. Google le permet de son côté, mais si le destinataire ne le permet pas, alors Google envoie le mail en clair (pas trop le choix…).
Or, si tu peux facilement vérifier que la connexion entre ton ordinateur et le serveur d’envoi est chiffrée, tu n’as en revanche aucun moyen de savoir si la connexion du tronçon suivant le sera (ça se passe uniquement entre Google et le fournisseur de messagerie du destinataire)… sauf à ce que Google t’en informe spécifiquement, ce qui est précisément ce dont il est question ici.
(Historiquement, l’énorme majorité des connexions de serveur à serveur étaient non chiffrées, parce que les serveurs supportant le chiffrement étaient rares — et donc le cas où à la fois le serveur émetteur et le serveur destinataire supportaient le chiffrement étaient encore plus rares. C’est en train de changer depuis quelques années, en partie sous la poussée de Google justement.)
[^] # Re: Drôle
Posté par Nairwolf . Évalué à 3.
Ok, merci de l'explication.
Donc, le premier tronçon (mon ordi jusqu'au serveur webmail de Google) est sécurisé si je suis en https, c'est ça ? Pour le second tronçon, entre le serveur Google jusqu'au serveur du destinataire, c'est ce qu'affiche désormais Google directement dans le webmail, n'est-ce pas ?
Néanmoins, c'est chiffré par Google, mais Google conserve bien la possibilité de lire le contenu de mon message, n'est-ce pas ? Parce que je trouve le message d'information de Google assez piégeur car ils disent affirmer si le message est chiffré ou non, mais ne disent pas pour qui il est chiffré. Pour un utilisateur non averti, cela peut porter à confusion.
[^] # Re: Drôle
Posté par gouttegd (site web personnel) . Évalué à 3.
Oui.
(En réalité mon explication partait du principe que tu utilisais un client lourd, mais le principe reste grosso modo le même si tu utilises le webmail — c’est du HTTP et non plus du SMTP, mais c’est chiffré quand même.)
Oui. C’est du chiffrement de point à point : le message est en clair chez toi, il est transmis chiffré jusqu’à Google qui le déchiffre, le rechiffre à nouveau pour l’envoyer au serveur du destinataire qui le re-déchiffre et le stocke (en clair) jusqu’à ce que le destinataire le réclame, à ce moment-là il est re-chiffré encore une fois et finalement déchiffré sur l’ordinateur du destinataire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.