ça me rappelle les affirmations de Google récemment : on a réparé Gmail les gars, c’est désormais à l’abri de la NSA.
Tout cela reste des affirmations gratuites.
Ma question était sérieuse : j’ignore s’il existe un processus chez Debian de revue collaboratif du code sensible pour rendre difficile un noyautage. Est-ce le cas ?[/quote]
Si tu regardais un peu la structure des projets, tu verrais que les modifications se font à coup de patch donc de fichiers diff commentés. Il est extrèmement facile de voir les modifications faites à chaque fois et de voir les raisons pour. Les différents développeurs vérifient chacun les modifications des autres, mainteneurs regardent les pourquoi des modifications proposées dans une release afin de voir si elles doivent être descendues dans les versions stables. Les bidouilleurs qui cherchent une spécificité précise explorent également le code et les patchs, les entreprises utilisant le code dans un cadre sensible l’ont également surement fait peut être en payant des sociétés d’audit de code. Donc oui, ça n’a rien à voir avec ce qu’affirme Google et non ce ne sont pas des affirmations gratuites. Il y a des raisons d’être parano, mais beaucoup sont plus justifiées que celle ci.
[quote=“haleth”]
M’enfin, il ne faut pas oublier que le protocole TLS est intrinséquement troué, puisqu’il se base sur de fausses assertions.
De fait, 100% des implémentations de TLS sont insécures.[/quote]
Quelles fausses assertions?
Le fait que toi, particulier, tu puisses avoir une confiance totale dans plusieurs milliers de groupuscules inconnus, dont tu as la preuve qu’un certain nombre fait n’importe quoi.
Quel rapport avec le fait que si tu charges la clef D78A5C23CEA8D8FF et que tu l’insères dans tes clefs apt, tu sois sûr que tu es sur mon dépot? (Le préalable étant de me faire confiance). Quel rapport avec le fait que tu es sûr d’être ici sur le même site que celui d’hier et des jours précédents parce que le certificat est valide?
[quote=“fran.b”][quote=“haleth”]
M’enfin, il ne faut pas oublier que le protocole TLS est intrinséquement troué, puisqu’il se base sur de fausses assertions.
De fait, 100% des implémentations de TLS sont insécures.[/quote]
Quelles fausses assertions?[/quote]
Le raisonnement n’est bon qu’en apparence: il n’y a pas de sécurité qui puisse être totale. Qui à une certitude à 100% n’a plus besoin de s’assurer de rien. Le fonctionnement d’une technique et sa sécurité sont deux questions distinctes.
Ben je suis pas sur d’être sur ton dépot, je ne te connais pas
Et je ne suis pas sur d’être sur debian-fr.org (enfin, quasiment sur, en revanche je n’ai aucune idée de la protection de mes données).
[quote]
Le raisonnement n’est bon qu’en apparence: il n’y a pas de sécurité qui puisse être totale. Qui à une certitude à 100% n’a plus besoin de s’assurer de rien. Le fonctionnement d’une technique et sa sécurité sont deux questions distinctes.[/quote]
Tout à fait.
En revanche, je suis sûr, lorsque j’utilise ssh par exemple, que le fonctionnement et la sécurité son valide.
Et je suis sûr qu’une sécurité basé sur l’espérance que visa, swisscom ou turktrust ne font pas n’importe quoi, ne vaut pas grand chose.
En encore, je n’ai que 500 certificats sur ma machine, il existe des milliers d’autorités de certifications …
Le fonctionnement de TLS est valide, la sécurité ne l’est pas, loin de là (en cherchant un peu, vous trouverez surement des exemples de “oups, nous avons par le plus grand des hasards signés ce qu’il ne fallait pas”).
Enfin bref, TLS me protège toujours contre mon voisin, c’est ça de gagné;
Ben je suis pas sur d’être sur ton dépot, je ne te connais pas
Et je ne suis pas sur d’être sur debian-fr.org (enfin, quasiment sur, en revanche je n’ai aucune idée de la protection de mes données).[/quote]
Bien sûr que si, tu es assuré que le site appartient au propriétaire de la clef CEA8D8FF et a lui seul. Tu trouves cette clef sur pgpkeys.mit.edu par exemple (mais pas seulement) ou bien dans tes clefs personnelles, clefs que tu peux avoir signée auparavant afin d’avoir la garantie à 100%. De même tu est sûr que tu es sur le site de celui qui a déposé le certificat à savoir:
www.debian-fr.org pour l’organisation référencée GT30783740, et ce jusqu’au 12 septembre à 16:56. Tu as plein d’autres renseignements dans le certificat qui te permette d’identifier immédiatement qui possède le site avant de te connecter dessus.
[quote]
Tout à fait.
En revanche, je suis sûr, lorsque j’utilise ssh par exemple, que le fonctionnement et la sécurité son valide.
Et je suis sûr qu’une sécurité basé sur l’espérance que visa, swisscom ou turktrust ne font pas n’importe quoi, ne vaut pas grand chose.
En encore, je n’ai que 500 certificats sur ma machine, il existe des milliers d’autorités de certifications …[/quote]Comment es tu sûr que lorsque tu fais une connexion ssh, tu la fais sur la bonne machine? Le protocole de ce point de vue est exactement le même avec comparaison du certificat avec celui que tu as accepté la première fois. Comme pour les sites https, tu dois soit faire confiance la première fois (panneau d’avertisement de firefox et message d’avertissement de ssh), soit faire confiance à un service d’authentification (n’existe pas pour ssh pour des raisons évidentes: trop de machines et pas d’intérêt), soit controler par toi même par déplacement physique.
[quote]Le fonctionnement de TLS est valide, la sécurité ne l’est pas, loin de là (en cherchant un peu, vous trouverez surement des exemples de “oups, nous avons par le plus grand des hasards signés ce qu’il ne fallait pas”).
[/quote]Lesquels? Cite précisement? Si c’est le cas, je peux te garantir que la société gérant les dits certificats a immédiatement fermé boutique: les certificats te garantissent la correspondance entre le site auqel tu es connecté et le site que tu veux avoir. Il n’est en aucun cas un gage de fiabilité ou de respectabilité du site. Tu es sûr d’une chose: quand tu as un site sans message d’avertissement, ce site est le même que celui où tu avais été le jour précédent. C’est le but de l’authentification TLS.
Ensuite le système propose un cryptage. Celui ci est extrêmement efficace et repose sur un échange préalable d’une très longue clef de chiffrage symétrique, échange fait par chiffrage asymétrique (inviolable à ce jour mais lent). La clef symétrique ne sert qu’un temps limité puis une deuxième clef est négociée. etc. Excepté si tu connais la clef du serveur (technique de la NSA avec la bénédiction de Microsoft par exemple), tu ne peux intercepter les messages. Le système est fiable à partir du moment où ton interlocuteur est fiable.
Rien à voir donc avec une fragilité de SSL par rapport à SSH. Les deux t’assurent l’identité de ce qu’il y a à l’autre bout (SSH t’authentifie sur le serveur en plus) et les deux assurent la confidentialité des échanges, tout cela à condition d’avoir confiance à la machine à l’autre bout (serveur SSH ou WEBS). Il n’est pas possible d’en demander plus.
[quote]
soit controler par toi même par déplacement physique.[/quote]
T’as tout compris;
[quote]
www.debian-fr.org pour l’organisation référencée GT30783740, et ce jusqu’au 12 septembre à 16:56. Tu as plein d’autres renseignements dans le certificat qui te permette d’identifier immédiatement qui possède le site avant de te connecter dessus.[/quote]
Ouais, et si, par malheur, dans mon navigateur, j’avais une autre clef, disons 00:C0:85:80:08:30:69:02:5C:F7:98:CC:68:AB:25:65:CF, avec un certificat qui me dit qu’il appartient à www.debian-fr.org, et ce jusqu’au 12 septembre à 16h56 : comment puis-je savoir s’il ment, ou s’il dit la vérité ? Dans les deux cas, le piti cadenas sera vert, et je n’ai aucun moyen de connaitre l’évolution de cette clef dans le temps : si ce certif est signé, c’est qu’il est valide. Ouais, non en fait : s’il est signé, c’est que quelqu’un dit qu’il est valide.
Je ne peux pas savoir si je suis sur le “vrai” site, je suis obligé de me dire : ok, les 2k autorités de certifs sont valides, font un bon boulot et pas une n’aurait signé un certificat invalide.
J’ai du mal.
[quote]
Si c’est le cas, je peux te garantir que la société gérant les dits certificats a immédiatement fermé boutique[/quote]
Non, l’anssi n’a pas encore fermé boutique.
[quote]
Tu es sûr d’une chose: quand tu as un site sans message d’avertissement, ce site est le même que celui où tu avais été le jour précédent. C’est le but de l’authentification TLS.[/quote]
Ho que non.
Je suis sur d’une chose : si j’ai un site sans message d’avertissement, ce que l’une autorité de certif me dit : ce site est le bon. Et je peux donc être tombé ailleurs (sur un autre site, chez un autre propriétaire) sans en avoir la moindre idée.
C’est problèmatique, d’autant plus lorsque l’on considère la liste des autorités de certifications …
Petite annecdote, Firefox et Chromium “blacklist” des CA. C’est révélateur, non ?
Je ne remet pas en question la couche cryptographie, elle est très bien et fonctionne parfaitement dans tout les cas. RSA, AES et dh restent solides.
En revanche, ton erreur est ici : “Les deux t’assurent l’identité de ce qu’il y a à l’autre bout”. SSH m’assure que le mec en face était le même qu’hier, et était le même depuis que j’ai stocké la clef publique.
TLS ne me l’assure pas.
Le problème des autorités dites de confiances est intrinséque.
En apparte, tu peux aussi faire de l’autentification de client en HTTPS (globalement: avec une couche TLS), c’est très peu utilisé parcqu’inadapté à une consultation web dite “classique”, mais trouvable dans certaines boites.
Y’a dla doc ici : httpd.apache.org/docs/trunk/ssl/ … allclients
[quote=“haleth”][quote]
soit controler par toi même par déplacement physique.[/quote]
T’as tout compris;
[quote]
debian-fr.org pour l’organisation référencée GT30783740, et ce jusqu’au 12 septembre à 16:56. Tu as plein d’autres renseignements dans le certificat qui te permette d’identifier immédiatement qui possède le site avant de te connecter dessus.[/quote]
Ouais, et si, par malheur, dans mon navigateur, j’avais une autre clef, disons 00:C0:85:80:08:30:69:02:5C:F7:98:CC:68:AB:25:65:CF, avec un certificat qui me dit qu’il appartient à debian-fr.org, et ce jusqu’au 12 septembre à 16h56 : comment puis-je savoir s’il ment, ou s’il dit la vérité ? Dans les deux cas, le piti cadenas sera vert, et je n’ai aucun moyen de connaitre l’évolution de cette clef dans le temps : si ce certif est signé, c’est qu’il est valide. Ouais, non en fait : s’il est signé, c’est que quelqu’un dit qu’il est valide.
Je ne peux pas savoir si je suis sur le “vrai” site, je suis obligé de me dire : ok, les 2k autorités de certifs sont valides, font un bon boulot et pas une n’aurait signé un certificat invalide.
J’ai du mal.
[/quote]Absolument pas, le site ne validera qu’un seul certificat et il n’y a qu’un seul certificat appartenant à debian-fr.org. D’où provient ton deuxième certificat? Soit tu l’as installé de force manuellement (j’entends en tripatouillant iceweasel car il n’accepte pas qu’un site ait deux certificats valides), soit ton navigateur est tolérant et tu dois changé de navigateur (consulte les sources de ton navigateur). Après le site va prouvé qu’il correspond bien à ce certificat par vérifcation qu’il possède bien la clef privé associé au certificat. Si il ne l’a possède pas, ton navigateur doit l’expulser. Je ne vois vraiement pas comment tu peux te retrouver dans la situation que tu décris. La signature n’est pas un vague fichier disant OK, la signature demande la possession d’une clef d’authentification que seul le site original possède. Ton navigateur ne reconnait qu’un seul certificat par site et que les certificats venant d’organismes d’une liste précise et ceux que tu as accepté. Point. Donc la situation que tu décris ne peut arriver à moins que tu es saboté ta machine. Dans ce cas toute ta machine est compromise de toute façon.[quote][…][/quote]En gros tu dis que tu ne fais pas confiance aux agences. Bon, libre à toi, je me demande comment tu peux faire confiance au courrier de tes impots, à ta banque et aux terminaux de cartes bleues mais passons. En quoi cela signifie que TLS est une passoire. Il te suffit de virer les dites organisations indignes de ta confiance voire n’en mettre aucun et tu n’auras que des sites de confiance, sites qu’à chaque fois tu authentifieras par ta méthode préférée, et qui à partir de ce moment là seront clairement identifiés à chaque fois que tu te reconnecteras. Tu confonds solidité du protocole et confiance en ceux qui l’appliquent. Le protocole TLS est à l’heure actuelle sûr, comprendre aussi sûr que les acteurs que tu acceptes de mettre en jeu le sont (tu as le choix de ces acteurs donc tu peux te libérer de toutes tes craintes).
En ce qui concerne l’affaire de l’ANSSI, tu ne peux pas être concerné, il s’agit de certificats locaux, à usage interne, utilisés au trésor public afin de pouvoir controler le trafic WEBS (par une technique «man in the middle» qui au lieu d’être validé par une autorité locale, l’ont été par l’autorité publique (c’est la fameuse erreur humaine). Sur une question de principe c’est grave car une autorité publique a délivré un faux certificat (une machine locale au lieu de machines google), d’un point de vue pratique tu t’en fous à moins que les DNS soient également modifiés et que le dit serveur soit rendu public. C’est sur le principe qu’effectivement c’est une erreur grave. Ça a eu beaucoup moins de conséquences que par exemple l’erreur de 2006 sur openssh dont les paquets openssh-blacklist sont les traces.
Faisons un lab.
Tu crée un certicat “CA”, comme un vrai.
Tu le rajoutes dans ton navigateur.
Tu fait un certificat pour www.debian-fr.org.
Tu fait un certificate request avec, tu le signes avec ton “CA”.
Tu installes ce beau monde sur un serveur web à toi.
Tu modifies les DNS (/etc/hosts) pour faire pointer www.debian-fr.org vers ta machine.
Tu tapes debian-fr.org dans ton navigateur.
Résultat :
Le piti cadenas est présent, tout baigne, l’utilisateur est “sur le bon site”. Presque…
J’espère, par cette exemple, t’avoir un peu éclairé sur l’affaire
Et comment fais-tu pour modifier les serveurs DNS utilisés par ta cible ?
Dans ta situation la machine est déjà compromise avant même d’utiliser TLS.
Et comment fais-tu pour modifier les serveurs DNS utilisés par ta cible ?[/quote]
DNS (DNSSEC n’est pas utilisé partout encore), IP et ARP sont moyennement sûr.
Pour en revenir au sujet de la compromission de Debian, il faut voir plusieurs choses :
- une entreprise américaine doit se plier aux demandes de la NSA Appel, MS, IBM ou RH n’ont pas le choix avec interdiction d’en parler, pour un projet communautaire libre international ce n’est pas la même histoire
- il ne suffit pas d’un développeur fou pour compromettre Debian mais plutôt d’une ribambelle
- le contrat social Debian stipule qu’ils ne cachent rien de leur problème c’est d’ailleurs pour ça qu’on est tant informé quid des autres ?
- Les développeurs Debian utilisent une infrastructure très rodée pour communiquer (PGP) ils l’utilisent avec soin (avec les keysigning parties) de l’avis de snowden himself ce n’est pas demain que la NSA percera PGP
Tout ça ne garantie rien, des erreurs passent toujours qu’elles soient volontaires (de la part de la NSA, du GCHQ ou d’une entreprise) ou non, mais ça limite la gravité des problèmes. Par ailleurs ce qui est intéressant c’est la gestion des problèmes et Debian est plutôt rapide et totalement transparent.
[quote=“haleth”]Faisons un lab.
Tu crée un certicat “CA”, comme un vrai.
Tu le rajoutes dans ton navigateur.
Tu fait un certificat pour debian-fr.org.
Tu fait un certificate request avec, tu le signes avec ton “CA”.
Tu installes ce beau monde sur un serveur web à toi.
Tu modifies les DNS (/etc/hosts) pour faire pointer debian-fr.org vers ta machine.
Tu tapes debian-fr.org dans ton navigateur.
Résultat :
Le piti cadenas est présent, tout baigne, l’utilisateur est “sur le bon site”. Presque…
J’espère, par cette exemple, t’avoir un peu éclairé sur l’affaire[/quote]
Tu dis des choses fausses:
Ta manoeuvre fonctionnera chez toi car tu as accepté le faux certificat volontairement, mais le gars d’à coté que tu veux duper sera insensible à tes manoeuvres. La question est comment tu fais pour le duper lui. La réponse est soit en forçant les autorités à accepter ton certificat ce qu’elles ne feront pas sauf à définitevement se compromettre, soit en lui demandant d’accepter un certificat ce qu’il ne fera pas, le certificat doit être valider par les organisations reconnues, soit en lui demandant de mettre une fausse organisation dans son navigateur (ce que font les organisations sensibles pour surveiller le https).
Par ailleurs /etc/hosts est n’est pas un DNS, ne mélange pas.
Si tu me dis que tu peux faire ça sur la machine du voisin, je te réponds betement que dans ce cas, toute sa machine est compromise. Encore une fois une attaque «man on the middle» à l’heure actuelle (c’est ce que tu fais finalement sauf que toi c’est «men on the middle qui ne renvoit rien au site d’origine») ne peut se faire sans une faute grave de l’utilisateur: acceptation d’un certificat non reconnu par qui que ce soit (avertissement de ton navigateur) ou non prise en compte des messages d’avertissement d’usurpation du site.
[quote=“fran.b”]La réponse est soit en forçant les autorités à accepter ton certificat ce qu’elles ne feront pas sauf à définitevement se compromettre,[/quote]ppppppp
Tu vous vraiment une confiance importante en vers les CA classiques (= qui sont installées de base dans la plus part des logiciels utilisants TLS).
Pourtant des grossière erreur sont avérée en.wikipedia.org/wiki/Certificat … compromise [1] et tu pourra noter que VeriSign et COMODO sont toujours installés par défaut. C’est une pure question de force, VeriSign a signé des certificats pour des services importants (très utilisés, administratif,…) retirer cette CA c’est beaucoup gêner les utilisateurs donc on ne fait rien. Je pensais à un moment que tu parlais d’utiliser des extensions comme SSLGuard qui te permettent au premier accès à un site d’enregistrer le certificat et de lever une alerte en cas de changement de ce dernier.
D’autre part, il y a un problème conceptuel de monté en charge des CRL. Pour une petite autorité pas de problème mais pour un pays (pourtant ce serait cool d’avoir un certificat avec notre carte d’identité). Il faut générer des autorités intermédiaires par blocs de N certificat ce que je n’ai jamais vu.
Que les implémentations de SSL/TLS n’ont pas de problème de sécurité je suis d’accord, mais l’utilisation actuelle est celle qu’on mérite : on ne s’intéresse pas à la sécurité, on a une sécurité moyenne.
[1] : là il est question des problèmes connus et reconnus uniquement
[quote=“MisterFreez”][quote=“fran.b”]La réponse est soit en forçant les autorités à accepter ton certificat ce qu’elles ne feront pas sauf à définitevement se compromettre,[/quote]ppppppp
Tu vous vraiment une confiance importante en vers les CA classiques (= qui sont installées de base dans la plus part des logiciels utilisants TLS).
Pourtant des grossière erreur sont avérée en.wikipedia.org/wiki/Certificat … compromise [1] et tu pourra noter que VeriSign et COMODO sont toujours installés par défaut.[…]Que les implémentations de SSL/TLS n’ont pas de problème de sécurité je suis d’accord, mais l’utilisation actuelle est celle qu’on mérite : on ne s’intéresse pas à la sécurité, on a une sécurité moyenne.
[1] : là il est question des problèmes connus et reconnus uniquement[/quote]
Je n’ai pas dit l’inverse, mais il y a une différence entre faire des erreurs et signer un certificat falsifié volontairement contredisant un autre certificat existant. Je ne crois pas que cela ait (encore) été fait.
En ce qui conerne ta dernière remarque, tu as un certificat, c’est celui de tes impots, et tu peux avoir également une clef GPG (elle me sert pour authentifier des papiers genre relevé de notes).
On parle de sécurité, il n’y a pas de différence entre une erreur et une attaque. Ce serait comme dire que personne n’a jamais attaqué une centrale nucléaire, on juste oublié de faire tel ou tel vérification. En l’occurrence, il faudrait que je remette la main sur une étude qui avait montré que des CA publique validait des certificats pour localhost par exemple.
Le nombre de foyer fiscal est bien plus faible que le nombre de citoyens 
(la problématique est exponentiel avec le nombre de certificat, il faut gérer ceux qui perdent leur certificat, se font voler leur machine, oublie leur mot de passe,… tout ça demande des procédure dantesque qui ne sont généralement pas acceptable pour l’utilisateur moyen du moins pas pour les cas généraux).
Pour ta clef PGP, c’est différent, la révocation ne se fait pas de la même façon et tu n’a pas des listes de révocation potentiellement très grandes et qui se valident en [mono]O(n)[/mono]
[quote=“MisterFreez”]
On parle de sécurité, il n’y a pas de différence entre une erreur et une attaque. Ce serait comme dire que personne n’a jamais attaqué une centrale nucléaire, on juste oublié de faire tel ou tel vérification. En l’occurrence, il faudrait que je remette la main sur une étude qui avait montré que des CA publique validait des certificats pour localhost par exemple.
[/quote]La même différence qu’entre donner deux mots de passe identiques à deux personnes ne le sachant pas et donner volontairement un mot de passe à une personne identique à une deuxième identifiée. Du point de vue théorique, c’est une faille, du point de vue pratique c’est tout de même différent.[quote]
Le nombre de foyer fiscal est bien plus faible que le nombre de citoyens (la problématique est exponentiel avec le nombre de certificat, il faut gérer ceux qui perdent leur certificat, se font voler leur machine, oublie leur mot de passe,… tout ça demande des procédure dantesque qui ne sont généralement pas acceptable pour l’utilisateur moyen du moins pas pour les cas généraux).[/quote]exact
fran.b, tu fais de la mauvaise fois ?
J’ai crée un certif de CA et l’ai ajouté dans mon navigateur parcque je suis suis pas un CA, mais y’en a plein, et plein qui font n’importe quoi.
Et donc, n’importe quel CA peut signer n’importe quel certificat, présenté par n’importe qui, et le voisin sera très sensible.
Et pour info, /etc/hosts fait parti du système de nom de domaines (Domain Name System, DNS)
Après, je suis d’accord avec toi : aucun CA n’a pour l’instant avoué avoir ce genre de pratique. À chaque fois, il s’agit “d’erreurs”.
vv222, au passage, je te susurre de te renseigner sur le DNS poisonning. Tu peux aussi, au passage, te renseigner sur le même sujet avec les protocoles ARP et DHCP.
J’ai un rétroportage de MATE pour Wheezy sur le feu, mais je vais suivre tes conseils de lecture dès que je me libère une petite heure.
[quote=“haleth”]fran.b, tu fais de la mauvaise fois ?
J’ai crée un certif de CA et l’ai ajouté dans mon navigateur parcque je suis suis pas un CA, mais y’en a plein, et plein qui font n’importe quoi.
Et donc, n’importe quel CA peut signer n’importe quel certificat, présenté par n’importe qui, et le voisin sera très sensible.
Et pour info, /etc/hosts fait parti du système de nom de domaines (Domain Name System, DNS)
Après, je suis d’accord avec toi : aucun CA n’a pour l’instant avoué avoir ce genre de pratique. À chaque fois, il s’agit “d’erreurs”.
vv222, au passage, je te susurre de te renseigner sur le DNS poisonning. Tu peux aussi, au passage, te renseigner sur le même sujet avec les protocoles ARP et DHCP.[/quote]
Fin du débat. Tu mélanges tout. Je te suggère de lire attentivement le blog de Stéphane Bortzmeyer en ce qui concerne les DNS. Il est très facile de se croire plus honnête et meilleur que les autres, comme on n’est pas spécialement exceptionnel, en général cela conduit à «tous pourris et malhonnêtes sauf moi (spécialement les grandes organisations)».
Pour tout le reste, mis à part ta manoeuvre élémentaire (que j’avais évoquée ici), tu te contentes de généralités et d’affirmations gratuites type [quote]…un CA, mais y’en a plein, et plein qui font n’importe quoi[/quote] sans donner de références précises. Que le système repose sur une délégation, c’est évident. Que tu considères cette délégation comme indue, ça se voit. Tu déplaces une discussion technique (le protocle est-il sûr) en une discussion morale (je suis honnête et les CA sont tous pourris) ce qui n’est absolument pas le débat.
