Chaque fois qu'on parle de sécurité sur le Web, voir sur Internet, SSL est très souvent la réponse. Ce protocole permet de sécurisé les communications avec des algorithmes de chiffrement évolués que je ne peux contester, je n'en ai pas les connaissances.
Par contre ce que je peux contester, c'est l'architecture basée sur un tiers de confiance. En effet, le SSL repose sur une entité en qui on doit la pleine et entière confiance afin de transmettre nos messages privés sans qu'un intermédiaire puisse les lire, connu sous le nom de CA (pour Certificate Authority). C'est ce CA qui va attester que Google est bien Google, Microsoft est bien Microsoft, ... Et vous n'avez pas d'autre choix de croire en cette entité.
Dans un monde parfait, ça fonctionne. Si chaque être humain était animé par un désir de protéger son prochain, nous n'aurions aucune crainte à avoir. Mais le monde n'est pas parfait et l'on peut le voir notamment dans les diverses résultats de EFF SSL Observatory que certains grands noms, comme Verisign, ne prennent pas la peine de faire leur travail correctement et signe des certificats pour des noms de domaine comme localhost ou webmail (voir page 45), par exemple. Ce document nous apprend aussi qu'il y a une prolifération de sous-CA (par exemple Deutsche Telekom a signé 252 CA). Il y'a aussi des certificats EV (Extended Validation, validation étendue, qui propose un vrai contrôle de la validité du demandeur et qui coûte beaucoup plus cher) qui ne respectent pas les règle EV ...
Bref un véritable fiasco, mais un machine à fric.
Il y'a aussi la sécurité des autorités de certification qui entre en jeu. Et là, c'est pas mieux : neuf certificats pour sept domaines, comme www.google.com, mail.google.com, login.yahoo.com, login.skype.com, login.live.com, addons.mozilla.org et un septième qui ne semble pas être un nom de de domaine, ont été générés frauduleusement. D'après l'annonce, l'attaquant a obtenu un nom d'utilisateur et mot de passe pour accéder à l'outil de signature de certificat.
Bien entendu c'est l'Iran qui l'a fait, ça a été fait par un état et donc c'est la grande classe (clinical accuracy), donc Comodo ne pouvait rien faire (si, si, dans le communiqué).
Dans le message sur le blog de Comodo, il est dit que l'attaquant a obtenu le nom d'utilisateur et le mot de passe d'un partenaire pouvant générer des certificats. Ça modère tout de suite l'attaque. Une simple attaque par ingénierie social suffit (et oui je lis "Social Engineering: The Art of Human Hacking"). Donc l'attaque étatique super balaise, est-ce juste pour couvrir de l'incompétence ?
Je n'en sait rien. Par contre ce que je sais : pouvoir générer des certificats SSL valide avec un simple nom d'utilisateur et un mot de passe, c'est ridicule. Pour accéder à mon compte en négatif à la banque c'est déjà plus sécurisé !
Donc voilà, la sécurité de vos communications sur le Web et Internet ne tient qu'à un nom d'utilisateur et un mot de passe. Je serais pas là aujourd'hui, je vais déposer des fleurs sur la tombe de la vie privé de l'internaute inconnu.
# Bis repetita
Posté par Ymage . Évalué à -10.
Si tu n'as rien à te reprocher, tu n'as rien à cacher.
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: Bis repetita
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
C'est pertinent. C'est une réflexion qui vient souvent. Mais généralement les gens qui font cette réflexion oublie que l'on doit parfois se cacher des criminels aussi. Si un criminel obtient des informations pertinentes sur moi, grâce à un formulaire d'inscription sur un site ou un courrier gmail à un ami, il peut se faire passer pour moi par téléphone auprès de : ma société de carte de crédit, ma banque, mon opérateur téléphonique, ...
J'ai essayé, début de cette semaine, d'obtenir des informations auprès de ma société de carte de crédit en ne mentionnant pas les montants de mes factures et mon numéro de carte de crédit. Figure-toi que ça a marché avec des informations simples et facilement accessible (adresse, date de naissance, ...). Ça peut-être le point de départ d'une attaque permettant de me subtiliser de l'argent, me faire chanter, m'arnaquer, ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Bis repetita
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Absolument, je suis toujours effaré de la quantité d'informations que je peux récupérer juste par téléphone sans être contraint de prouver qui je suis... dans ces moments là on se dit que ça doit être quand même pas trop compliqué de pourrir la vie de quelqu'un si on le veut vraiment.
[^] # Re: Bis repetita
Posté par nicolas . Évalué à 10.
Je ne sais plus où est-ce que j’ai lu ça. À propos de la problématique de la confidentialité des données. Mais ça disait, en substance, qu’il fallait faire un compromis entre la confidentialité et la circulation des informations. Car, mettons dans une agence d’espionnage, avoir les informations trop cloisonnées peut être plus dangereux que de prendre le risque de les voir tomber chez l’ennemi ; il faut que les agents connaissent la situation pour pouvoir faire correctement leur boulot.
Sans prendre des cas aussi extrême, c’est pareil pour la vie de tous les jours : s’il fallait montrait patte blanche à la moindre demande de renseignement on n’avancerait pas…
[^] # Re: Bis repetita
Posté par Grunt . Évalué à 5.
Sans prendre des cas aussi extrême, c’est pareil pour la vie de tous les jours : s’il fallait montrait patte blanche à la moindre demande de renseignement on n’avancerait pas…
Mouais. Sauf que le numérique fournit justement des moyens rapides et fiables de montrer patte blanche sans y passer 8 jours. Un mail signé par ma clef GPG ça ne peut être que moi qui l'envoie.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Bis repetita
Posté par zebra3 . Évalué à 4.
Sauf si on te vole ta clef GPG, ce qui au final revient aux mêmes nécessités qu'IRL : surveiller ses données et sa vie privée (même s'il est vrai que le numérique permet plus de choses que l'IRL comme la révocation d'une clef).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Ou si tu la confies volontairement à quelqu'un d'autre. Mais un message signé par une clef connue est toujours mieux que pas signé du tout. En fait on n'a aucune certitude sur le fait qu'une clef privée soit à la disposition de son propriétaire théorique et lui seul, mais ce dont on est sûr, c'est que si ce n'est pas le cas, c'est sa faute.
[^] # Re: Bis repetita
Posté par Thomas Douillard . Évalué à 0.
Si il se fait pirater son ordi et piquer sa clé, c'est de sa faute ? Personne n'est vraiment à l'abri.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Oui, c'est sa faute, sa responsabilité du moins. Pour ce genre de cas il faut qu'il ait ailleurs un certificat de révocation tout prêt, sinon ce sera vraiment sa faute, pour le coup.
[^] # Re: Bis repetita
Posté par Thomas Douillard . Évalué à 2.
Dans un monde idéal ou tout le monde a été formé à la question, ou il y a pas de faille de sécurité dans les ordis, jamais (et non, ce n'est pas - forcément - de la responsabilité de l'utilisateur si il y a une faille sur son ordi, les mises à jours sont pas instantanées, il existe des failles non encore corrigées)
Et un monde ou toute l'infrastructure nécessaire est en place. On en est encore loin, en fait.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Non non, je maintiens, si quelqu'un ne fait pas assez attention à sa clef privée et qu'il se retrouve avec quelqu'un d'autre qui y a accès, c'est sa faute, point. Quand on correspond avec quelqu'un en chiffrant avec sa clef publique, s'il y a un problème, c'est le problème du destinataire.
C'est comme quand tu mets des objets dans un coffre de ta banque : tu n'es pas sûr qu'ils ne seront pas volés, seulement que s'ils le sont, ce sera la faute de ta banque.
[^] # Re: Bis repetita
Posté par Zenitram (site web personnel) . Évalué à -1.
Tu ne serais pas pour la peine de mort pour la moindre faute toi?
Dans la vie réelle, on a le droit à l'erreur, et la serrure est changée, la clef volée ne sert alors plus à rien. Celui qui perd la clé paie pour sa bêtise, mais un peu, pas à vie.
Il faut donc prévoir tout le mécanisme de révocation, et qu'il marche, sans complexité pour l'utilisateur, avant d'essayer de "vendre" le bousin à Mr tout le monde. On en est très loin, il suffit de voir le bordel que c'est dans des navigateurs diffusions à des millions de copies avec les certificat Comodo volés... Aujourd'hui, la technologie n'est clairement pas mûre.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Non, pourquoi ?
Bien sûr, je n'ai jamais dit le contraire. Si quelqu'un se fait voler sa clef, c'est son problème, mais ça n'implique pas de le condamner à crever comme une merde.
[^] # Re: Bis repetita
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est la qu'on diffère de point de vue : de mon point de vue, c'est son problème uniquement si on est capable de fournir des outils (non complexe) pour le faire. Et pour le moment, on en est pas capable (j'ai essayé par exemple rapidement OpenPGP pour Thunderbird, je n'y comprend absolument rien entre toutes les possibilités de gestion, génération de clef, serveur, révocation, arghhh, j'imagine qu'une personne encore moins technique que moi doit carrément fuir, surtout quand en face on lui répond que c'est bizarre ses mails, il y a des trucs avant et après le message incompréhensibles - Quand Thunderbird n'a pas le plugin OpenPGP, il affiche cash le contenu PGP).
Un clé, une serrure, un changement de serrure, c'est facile. A quand de bons outils pour les clefs numériques?
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Et si quelqu'un n'a pas lu le code de la route avant de prendre le volant ? Dieu sait que ce n'est pas simple, le code de la route, en plus le lire demande de savoir lire, ce qui est diablement compliqué.
J'ai essayé par exemple rapidement Oui-Oui en vacances, je n'y comprends absolument rien entre tous ces caractères et symboles de ponctuation, arghhh, j'imagine qu'une personne moins technique que moi doit carrément fuir à la vue d'un simple bouquin, surtout quand il n'y a même pas d'illustrations.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Pour expliciter mon point de vue : je considère qu'il y a des sujets tout à fait importants qui sont compliqués par nature — la lecture, l'écriture, les mathématiques, le chiffrement…) — et qui nécessitent un apprentissage indispensable, qui parfois n'a rien d'attirant et doit être imposé — c'est le cas pour la lecture, l'écriture et les mathématiques.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ah, dernière chose, n'en déduisez pas que je nie l'intérêt de toute simplification. Ce qui peut être simplifié doit l'être. Ainsi la numération positionnelle simplifie considérablement la pratique des mathématiques.
En revanche, je pense qu'il est faux de considérer qu'une solution est mauvaise parce qu'elle n'est pas intuitive. Certaines requièrent nécessairement un apprentissage. Dans le cas de la cryptographie, on ne peut pas couper aux notions de clef privée, clef publique, signature, chiffrement, certification et révocation.
[^] # Re: Bis repetita
Posté par Zenitram (site web personnel) . Évalué à 1.
Certes. Mais des fois c'est compliqué pour pas grand chose. J'ai quelques exemples en tête :
Deux exemples de complexité pour le plaisir, qui n'apportent rien sauf le plaisir de la complexité, mais auquel on affirme que c'est normal que c'est compliqué, car par nature c'est difficile. Ben non, on peut faire autrement, et simple. Et j'ai l'impression que pour le moment, côté GPG/PGP/Signature électronique autre je sais pas, on est pas encore au point niveau simplification possible à faire. Je ne connais pas assez pour en être sûr, mais je pense qu'il est possible de simplifier ce qui est présenté à l'utilisateur pour la gestion des clés et des signatures électroniques.
[^] # Re: Bis repetita
Posté par Shuba . Évalué à 5.
Mouais, le comportement des boites automatiques c'est quand même de paser à la vitesse supérieure quand ça accélère, ce qui est quand même le contraire de ce qu'il faut faire en descente en montagne. alors ça marche aux USA, où t'as tellement peu de gens qui prennent des routes montagneuses que c'est pas grave s'ils savent pas qu'il y a un réglage frein à moteur sur leurs boites, mais ça parche pas en france, où une grande partie de la popoulation fait de la route de montagne au moins une fois par an.
Et c'est valable aussi en montée, j'ai pas encore vu une boite automatique qui sache mieux préparer un virage que moi (il faudrait qu'elle sache qu'un virage approche...).
[^] # Re: Bis repetita
Posté par Adrien . Évalué à 2.
En Nouvelle-Zélande les boites de vitesses automatiques sont très répandues, pourtant leurs îles ne sont absolument pas plates…
[^] # Re: Bis repetita
Posté par Shuba . Évalué à 3.
Cool, une bonne proportion de 4 millions d'habitants ça fait... Ah pas pas beaucoup au final. En France, c'est une bonne partie d'une population bien plus importante qui emprunte les routes de montagne chaque année pour aller skier. Et je suis bien content qu'il n'y en ait pas trop qui cassent leurs freins en descente parce qu'ils ont une boite auto et ne savent pa ce qu'est un frein à moteur.
J'ai deux reproches assez distincts à faire à la boite automatique:
Lorsque les utilisateurs sont mal éduqués, pas de frein à moteur, donc risque de sur-usure des freins en descente (il y a malheureusement eu pas mal d'accidents liés à ce problème).
Fondamentalement, c'est moins efficace qu'une boite manuelle, parce qu'adapter le régime du moteur est fortement lié à la connaissance de la route, ce qu'à ma connaissance une voiture n'a pas. Ou alors il va falloir me donner un exemple d'un pilote qui conduit mieux en montagne avec une boite automatique.
[^] # Re: Bis repetita
Posté par claudex . Évalué à 3.
Sans compter que ça consomme plus (sauf peut-être les boîtes récentes), et que les États-Unis sont réputé pour leur essence pas cher.
« 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: Bis repetita
Posté par zebra3 . Évalué à 2.
Pas si sûr.
Si les boîtes automatiques donnent l'impression de consommer plus, c'est parce qu'en Europe, elles sont la plupart du temps présentes dans des modèles haut de gamme et associées à des moteurs à forte cylindrée.
Même sans boîte automatique, ces voitures consomment de toute façon beaucoup d'essence.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bis repetita
Posté par claudex . Évalué à 2.
Non, je parle des chiffres des constructeurs pour une voiture avec le même moteur. Mais il me semble que récemment ces chiffres soient sensiblement les mêmes, ce qui n'était pas le cas il y a quelques années.
« 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: Bis repetita
Posté par Zenitram (site web personnel) . Évalué à 1.
En pratique, les tests de conso effectués sur les boites manuelles sont à "vitesse constante", pas un mec dont l'objectif est de consommer le moins possible, et ce mec sait comment faire pour, il est formé pour. Les chiffres des constructeurs, on leur fait dire un peu ce qu'on veut... Sauf que le test de base n'est pas objectif (fait par un pro, par par monsieur tout le monde, dans des conditions de circulation ne nécessitant pas des freinages et accélérations)
En pratique donc, en réalité avec une boite auto tu consommes moins car tu n'es pas formé (et tu n'as pas forcément l'envie) pour rouler en optimisant la consommation, la boite auto, elle, est formée.
Pour résumer : de nos jours, un pro sachant manier la boite manuelle consommera moins qu'une personne normale avec boite auto qui consommera moins qu'une personne normale avec boite manuelle. Et ce sans compter que si on généralisait les boites autos sur des voitures dont l'objectif est de consommer peu (ce n'est pas le cas des voitures US), on pourrait encore faire bien plus de progrès et l'écart serait encore plus grand.
[^] # Re: Bis repetita
Posté par claudex . Évalué à 2.
C'est pour cela que je dis, que la différence est négligeable actuellement. Mais ce n'est que récent, les habitudes ne changent pas du jour au lendemain, les voitures non plus. Les boîtes automatiques plus anciennes n'étaient pas formées à consommer moins mais à avoir de la reprise et à ne pas caler.
« 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: Bis repetita
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6. Dernière modification le 26 mars 2011 à 19:01.
C'est un mot de passe avec un algo symétrique que tu décris là. La cryptographie asymétrique, tu as une clé qui peut uniquement fermé la porte (clé publique), un clé qui peut fermé, ouvrir, générer une clé de fermeture unique et changer la serrure (clé privée).
SSL et PGP sont les deux des systèmes asymétriques. Le CA a une clé publique et un clé privée, un certificat a une clé publique et privée et en fait le CA un certificat c'est la même chose (certificat X.509), sauf que le CA a la champs CA=true, un certificat serveur CA=false. Après tu as des subtilités (ce certificat peut chiffré, mais pas authentifier, ou l'inverse).
Je vois pas comment on peut faire plus simple qu'enigmail. Mais il faut avoir une base minimum :
Ta clé privée est généralement chiffrée avec un algo symétrique afin de te donner le temps de révoquer ta clé en cas de vol (le temps que le voleur trouve ton mot de passe, si c'est "abcd", t'es mort en moins d'une heure, si c'est "&AEUHATHKgecug9r84(&UOECAHOECUGJK7889a??+#$(@#$TKOE((@#)($LOEAUta", normalement pas avant quelques siècles).
C'est pas évident, mais entre comprendre ça et les EULA ... Je trouve ça plus simple.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Oui, c'est sa faute, sa responsabilité du moins. Pour ce genre de cas il faut qu'il ait ailleurs un certificat de révocation tout prêt, sinon ce sera vraiment sa faute, pour le coup.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Désolé pour le commentaire en double, la faute aux erreurs 500.
[^] # Re: Bis repetita
Posté par pasScott pasForstall . Évalué à -2.
C'est clair que determiner a qui qui que c'est la faute, ca va vachement faire avancer le probleme!!
"Me suis fait usurper!"
"Ouais, mais c'est ta faute, pas la mienne!" "... Merci, t'es cool comme mec toi."
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bis repetita
Posté par moules . Évalué à 2.
Je tiens à corriger ta signature. En effet, la norme veut qu'il y ait un espace entre « -- » et « \n ». Il faut donc écrire « -- \n » pour être correct.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Je tiens à corriger ta correction. En effet, la langue française veut que le mot « espace » soit féminin lorsqu'il est utilisé dans le champ sémantique de la typographie. Il faut donc écrire « une espace » pour être correct.
[^] # Re: Bis repetita
Posté par Strash . Évalué à 2.
J'ai lu ça un peu partout ces derniers temps et j'étais surprit à chaque fois.
Je suis allé vérifié et il semble que ce que tu affirmes est faux : l'espace typographique est masculin à part si l'on désigne la pièce métallique qui servait à créer cet espace en imprimerie. Seuls les typographes utilisent le féminin, mettre le mot au masculin n'est pas une faute.
sources (entre autre) :
http://fr.wikipedia.org/wiki/Espace_typographique
http://www.pincetonfrancais.be/v1/article.php3?id_article=5
Merci d'éviter de répandre ces fausses rumeurs orthographique qui écorchent les yeux.
[^] # Re: Bis repetita
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Donc si j'ai bien compris, lorsqu'on désigne une zone blanche dans un texte, on utilise le masculin, et lorsqu'on désigne la pièce de plomb ou la séquence de bits qui sert à implémenter cette zone, on utilise se féminin ?
Parfait, donc ça tombe bien, pour les signatures, la convention est d'utiliser deux signes moins (Unicode MOINS/HYPHEN-MINUS) suivis d'une espace (Unicode ESPACE/SPACE) puis d'un retour à la ligne (LF ou CR-LF selon la convention du contexte).
[^] # Re: Bis repetita
Posté par nicolas . Évalué à 3.
Très cher,
Vos propres liens vous contredisent.
— « Notez que la distinction n’est pas toujours aussi claire : par métonymie, on peut aussi désigner par une espace le blanc entre deux mots… Bref, retenez surtout qu’une espace appartient au vocabulaire des typographes plutôt qu’à celui de monsieur tout-le-monde. »
— « Le mot espace est féminin pour désigner le caractère, c'est-à-dire l'élément physique, caractère en plomb ou électronique (suite de bits)[1],[2] et masculin dans les autres cas, […]. »
Reconnaissons que l’utilisation du féminin tient plus de la pédanterie que de la grammaire, raison supplémentaire d’en user et abuser. Mais veuillez veiller à lire consciencieusement vos sources pour ne pas risquer le flagrant délit de troll de bas étage.
[^] # Re: Bis repetita
Posté par Antoine . Évalué à 8.
vérifier.
orthographiques.
Certes.
[^] # Re: Bis repetita
Posté par Ymage . Évalué à 3.
Ironie
J'ai mis le lien en SSL au cas où ... ⸮
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: Bis repetita
Posté par khivapia . Évalué à 9.
Pourtant, comme disait Maître Eolas, on ne met pas des rideaux à sa salle à manger pour assassiner sa femme en toute impunité...
Et si les appartements sans vis-à-vis se vendent plus chers que les autres, il y a sans doute une raison.
[^] # Re: Bis repetita
Posté par Antoine . Évalué à 3.
Il vaut mieux mettre un store ?
[^] # Re: Bis repetita
Posté par pasScott pasForstall . Évalué à -2.
Nan, tu fais ca a la cave. Ca t'eviteras d'avoir a traienr le corps pour l'enterrer, et je ne mentionne meme pas le temps que tu vas gagner a nettoyer tout le bordel qu'elle aura laisse en essayant de s'enfuir.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bis repetita
Posté par nicolas . Évalué à 3.
Je crois que preuve est faite que les geeks ne sont pas bons dans ce domaine…
[^] # Re: Bis repetita
Posté par Grunt . Évalué à 7.
Heu.. les geeks qui ont fait disparaître leur conjoint sans laisser de traces n'ont évidemment pas fait parler d'eux.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Bis repetita
Posté par windu.2b . Évalué à 3.
Et Hans Reiser, hein ?
# Plusieurs autorités ?
Posté par anakin . Évalué à 2.
Ne serait-il pas possible d'avoir des certificats de plusieurs autorités de confiance (indépendantes entre elles naturellement) ? Ainsi la vérification se ferait sur plusieurs autorité ce qui réduit le risque de compromission.
Ou alors, c'est comme lorsqu'on on chiffre un message avec les clés publiques des destinataires, il suffit que la clé d'un seul destinataire soit compromise pour pouvoir lire le message. Je ne sais pas d'ailleurs si cela existe, le fait de pouvoir chiffrer un message avec des clés publiques et ne pouvoir les déchiffrer que simultanément avec les clés privés de tous les destinataires (mais encore faudrait-il pouvoir réunir les clés privés à un instant donné pour le déchiffrage) ; un peu comme si c'était un coffre avec plusieurs clés répartis chez plusieurs personnes, ainsi l'information ne pourrait s'obtenir qu'avec la compromission de TOUS les possesseurs de clés alors que maintenant, il suffit d'UN seul possesseur de clé pour déchiffrer.
[^] # Re: Plusieurs autorités ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
C'est utilisé. La clé d'archive de Debian nécessite 9 personnes pour signer et 7 personnes pour être révoquée. Et personne ne fait parti des deux groupes : http://ftp-master.debian.org/keys.html
Malheureusement pour les entreprises de certification SSL, ça serait trop contraignant d'avoir une vraie politique de sécurité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Plusieurs autorités ?
Posté par jcs (site web personnel) . Évalué à 2.
Je ne peux pas laisse dire ça. Les autorités de certification ont de vraies politiques : Politiques de Certification (CP, ici par exemple) et Pratiques des Politiques de Certifications (DPC), ce sont des documents nécessaires à l'obtention de certifications et/ou qualifications (par exemple type référentiel général de sécurité). Ce sont les étapes obligées pour avoir sa CA dans les autorités racines des browsers.
La vraie question c'est n'y a-t-il pas trop d'autorités racines dans les browsers web ?
Cela dit, je ne nie pas qu'il semble bien y avoir quelques problème chez Comodo ; même si finalement les certificats frauduleusement obtenus ont été révoqués rapidement.
[^] # Re: Plusieurs autorités ?
Posté par khivapia . Évalué à 4.
Oui, on connaît ça : pour Gamelin en 39, l'armée française était prête parce que tous les papiers étaient en ordre...
Ici ça fait un peu le même effet, on rédige une politique de sécurité (puisque de toutes façons il faut bien), mais après on ne l'applique pas (preuve en est faite par Comodo)...
Enfin bref, ce n'est pas parce qu'on est ISO 9001, EAL trucmuche ou qu'on a des papiers en règle qu'on fait tout bien : à la limite l'intérêt d'avoir défini une politique de sécurité à un instant donné est que l'émetteur de certificats a été, à un moment, sensibilisé à la sécurité, mais ça ne dit rien sur son application.
[^] # Re: Plusieurs autorités ?
Posté par jcs (site web personnel) . Évalué à 1.
Pas tout à fait, même s'il est vrai que certains audits ne se font que sur base documentaire.
Cependant la plupart du temps les auditeurs viennent sur site s'assurer que les procédures mises en place sont bien appliquées : interview des personnes impliquées, vérification d'éléments de preuves (monsieur Machin est responsable de la salle X, montrez moi le document où il s'y engage... Montrez moi le coffre où sont stockés les clés de séquestre, montrez-moi que vous seul y avez accès...)
Ensuite les certifications obtenues ont une validité limitée dans le temps. Régulièrement (tous les ans par exemple) l'auditeur revient. Il vérifie également que les points de non-conformités qu'il a pu relever lors du précédent audit on été corrigés.
Bien sûr, entre deux audits tu peux faire n'importe quoi ; Mais si tu as fait les efforts pour mettre en place une politique de sécurité, c'est souvent beaucoup plus simple de la respecter (et d'expérience j'en sais quelque chose). D'autant plus que l'auditeur n'est pas con, il flaire souvent les procédures qui ne peuvent être appliquées en pratique.
C'est d'ailleurs probablement une des plus grosses difficultés de cet exercice : écrire des procédures qui permettent d'atteindre le niveau de sécurité désiré sans les rendre ni trop contraignantes (ce qui inciterait les acteurs de la politique à les contourner, ce qui serait contre-productif), ni trop compliquées (car il ne faut pas oublier de former les gens, sinon ça ne sert à rien de mettre en place quoi que ce soit)
[^] # Re: Plusieurs autorités ?
Posté par Mareo . Évalué à 1.
Une petit piste pour ta réflexion, même si ça ne me semble pas utilisable en l'état pour du SSL :
Secret_réparti
[^] # Re: Plusieurs autorités ?
Posté par Larry Cow . Évalué à 2.
Et du code pour Shamir : http://point-at-infinity.org/ssss/
[^] # Re: Plusieurs autorités ?
Posté par anakin . Évalué à 2.
Pas mal ce Shamir Code, en plus d'après ce que j'ai lu, l'idée derrière est vraiment élégante et simple (interpolateur de Lagrange).
Donc en gros, ca servirait plutôt à découper la phrase de passe de la clé privée (car la clé privée en elle même ce serait trop gros).
[^] # Re: Plusieurs autorités ?
Posté par Dorian . Évalué à 2.
Facile : le message est chiffrée par les clés publiques des personnes qui doivent être réunies :
"Message TOP SECRET" : chiffrement avec la 1er clé ---> puis la 2éme ---> ... etc -> Niéme clé "189379HI3ghid1772ghdheg277è" : déchiffrement avec la Néme clé --> N-1iéme clé ---> .... etc --> jusqu'à arriver au message d'origine.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Plusieurs autorités ?
Posté par anakin . Évalué à 2.
Sauf que si une clé est perdue dans la chaîne tout est mort....
Alors qu'avec le code de Shamir, on peut tolérer la "mort" de certaines clés.
[^] # Re: Plusieurs autorités ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Inacceptable, c'est comme des disques en RAID 0 : un disque ou une personne disparaît dans la nature, ton secret est perdu à jamais.
C'est tout l’intérêt du Shamir Code utilisé par Debian (pas mal ce truc, j'en apprend toujours ici...) qui fait comme du RAID-5 ou 6 pour les disques ;-).
# HTTP PKI décentralisée
Posté par foudfou . Évalué à 1.
C'est l'occasion de demander à nouveau:
je crois avoir entendu parler d'une alternative à la PKI centralisée pour HTTP... une sorte de HTTP-over-GPG. Ça dit quelque chose à quelqu'un ?
[^] # Re: HTTP PKI décentralisée
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Oui : http://tools.ietf.org/html/draft-mavrogiannopoulos-rfc5081bis-09 .
Voir aussi le mod_gnutls pour Apache HTTP Server.
[^] # Re: HTTP PKI décentralisée
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Voir aussi le projet Monkeysphere, qui est un hack pour lier le SSL actuel à des clefs PGP.
[^] # Re: HTTP PKI décentralisée
Posté par Krunch (site web personnel) . Évalué à 2.
Et puis il y a les gens qui veulent intégrer la crypto au niveau transport en remplaçant TCP :
http://events.ccc.de/congress/2010/Fahrplan/events/4295.en.html http://mirror.fem-net.de/CCC/27C3/ogg-audio-only/27c3-4295-en-high_speed_high_security_cryptography.ogg
Rien à voir mais je comprend toujours pas comment faire un retour à la ligne. Et les erreurs 500 c'est pénible.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: HTTP PKI décentralisée
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Dans ton cas précis, c'est une liste que tu veux faire (avec une ligne blanche avant !) :
Ce qui donne :
# Internet
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Certes, mais lorsqu'on parle de sécurité sur Internet d'une façon générale aussi. SSL sert aussi à sécuriser le transfert et la récupération de courrier, la messagerie instantanée, etc.
# Une analyse
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Il y a une analyse intéressante du modèle SSL/TLS. En résumé, les caractéristiques techniques TLS — à savoir, n'avoir qu'une seule signature possible sur un certificat et ne pouvoir proposer qu'un seul certificat pour une connexion — impose un modèle social qui comporte de graves défauts : il encourage la concentration sur un oligopole, voire un monopole d'autorités de certification, et encourage ces autorités à faire leur travail — vérifier l'identité des gens — le plus mal possible.
[^] # Re: Une analyse
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Il y'a aussi une analyse de l'EFF sur cette affaire https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Une analyse
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
Voir aussi le billet de Stéphane Bortzmeyer sur Seenthis :
http://seenthis.net/messages/14461
# Il permet quoi ?
Posté par defmonkey . Évalué à 9.
[...] Ce protocole permet de sécurisé les communications [...]
Il permet peut être de sécuriser, mais pas de sécurisé. Ça pique les yeux, désolé ...
# Surprise
Posté par j_kerviel . Évalué à 10.
Eh ben ça alors. Apprendre que Verisign c'est une entreprise de branleurs, ça fait un choc.
On ne s'en doutait pas avant.
Enfin ça va mieux en le disant.
# In other news
Posté par j_kerviel . Évalué à 7.
Et pendant que tous ces blaireaux s'astiquent la nouille avec leurs solutions corporate, des solutions communautaires (donc pas fiables) comme cacert ne sont toujours pas intégrées dans les navigateurs majeurs :
http://wiki.cacert.org/InclusionStatus
En particulier dans le navigateur libre le plus utilisé : Firefox. Le ticket est ouvert chez mozilla depuis… 2003 : https://bugzilla.mozilla.org/show_bug.cgi?id=215243
[^] # Re: In other news
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Oui, je n'ai pas parlé de CAcert.org, mais pour avoir fait les démarches auprès de d'un vrai CA et auprès de CAcert.org, c'est sans appel : mon vrai certificat a été fait à l'aide de photocopies (assez facile à falsifier) envoyée par mail et CAcert.org, j'ai rencontré deux personnes en présentant deux papiers officiels attestant mon identité.
Mon vrai certificat a une validité de 3 ans avec tous les champs X.509 remplis et CAcert.org, seulement 6 mois avec juste le CN; je dois encore prouvé mon identité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: In other news
Posté par Littleboy . Évalué à 6.
Lire le commentaire 158, un representant de CAcert explique la situation et demande a Mozilla d'attendre la fin de l'audit.
Audit commence en 2005 et toujours pas termine...
Depuis, personne de CAcert n'est venu demander l'inclusion dans Mozilla (et comme l'audit n'est toujours pas termine, on ne voit pas bien pourquoi ca changerait).
Verisign est surement a chier, tout le monde est d'accord la dessus. Mais si Mozilla a des regles precices pour l'ajout d'autorites (adoptees justement en reponse a ce bug), c'est pas pour rien.
Ajouter une autorite juste parce qu'ils sont proches ideologiquement et que ca fait plaisir a plein de gens, c'est une belle connerie. L'audit a souleve assez de problemes (transparence, securite, etc.) pour qu'on attende la fin et la resolution de tous les problemes avant de prendre une decision.
[^] # Re: In other news
Posté par zebra3 . Évalué à 1.
Pourtant, c'est le même Mozilla qui a refusé d'inclure H.264 dans Firefox au profit de Theora juste pour des raisons idélogiques, alors même que le second est largement à la ramasse et que tout le monde utilise déjà le premier.
Comme quoi, l'idéologie, on lui fait dire ce qu'on veut.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: In other news
Posté par Littleboy . Évalué à 2.
Un clic sur mon pseudo et une recherche dans la liste de mes commentaires devrait te permettre rapidement de te faire une idee sur ce que je pense de cette decision de Mozilla et des arguments pourris deployes par les mecs du marketing...
[^] # Re: In other news
Posté par zebra3 . Évalué à 2.
Ben alors on est d'accord ;-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: In other news
Posté par Zenitram (site web personnel) . Évalué à 1.
Libre ou pas, les être humains restent des être humains : énorme différence entre les paroles et les actes! Ce n'est pas nouveau ;-).
[^] # Re: In other news
Posté par zebra3 . Évalué à 4.
C'est vrai mais c'est problématique pour la crédibilité de certains, comme ceux qui se posent en défenseur de la liberté du web…
Au moins, Stallman est cohérent dans ces paroles et dans ses actes, qu'on aime ou non le personnage.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: In other news
Posté par j_kerviel . Évalué à 5.
Ce n'est pas pour rien. Mais si ces règles se révèlent inutiles, ou stupides, alors il faut peut être s'interroger sur la pertinence de ces règles.
En l’occurrence j'ai toujours été persuadé que ça serait une bonne chose du point de vue idéologique.
Aujourd'hui, on se rend compte même de manière pragmatique, il n'y a aucune raison de préférer Verisign à cacert.
Donc ce qui est « est une belle connerie » idéologique, à mon sens, c'est plus de se reposer sur des maillons faibles qu'on considère fiable parce que ce sont de grosses sociétés avec plein de moyens, plutôt que d'admettre qu'un collectif de gens sans but lucratif fait mieux.
[^] # Re: In other news
Posté par Zenitram (site web personnel) . Évalué à -1.
Comment tu sais qu'ils font mieux? Justement, il semble que l'audit montre qu'il y a de grave lacune, et que comme CACert n'est pas sur les navigateurs principaux, la seule sécurité c'est le fait d'être sur 1% même pas des machines. Un peu comme Linux sur le desktop en fait...
La sécurité par manque d’intérêt pour un méchant n'est pas très utile pour un déploiement à grande échelle
[^] # Re: In other news
Posté par j_kerviel . Évalué à 4.
Et la sécurité par la rigueur des procédures, tu pense que ça peut être utile pour un déploiement à grande échelle ?
cf le commentaire d'Etienne Bagnoud plus haut
[^] # Re: In other news
Posté par Zenitram (site web personnel) . Évalué à 1.
Le commentaire d'Etienne est pertinent mais se concentre sur la vérification de l'identité, pas sur l'ensemble de la chaîne. Et donc certes CACert contrôle mieux l'identité, mais n'assure pas assez la sécurité de son infrastructure (si j'ai bien compris), donc au final, je craint que la sécurité globale soit plus mauvaise et donc à ne pas conseiller.
[^] # Re: In other news
Posté par j_kerviel . Évalué à 6.
Une chaine n'est pas plus fiable que le plus faible de ses maillons.
Si n'importe qui peut obtenir un certificat bidon, alors ça ne sert à rien que le reste de la chaine soit ultra sécurisée.
Donc ça me semble un peu optimiste de dire que cette sécurité faillible puisse être meilleure qu'une autre sécurité.
[^] # Re: In other news
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
De ce que je sais, CACert.org a stoppé son inclusion dans Firefox en 2007 parce que certaines faiblesses ont été rencontrées surtout au niveau de la gestion. Ces faiblesses ont été découvertes durant l'audit fait par Mozilla pour l'inclusion.
En 2009, le responsable de l'audit, Ian Grigg, arrête son travail, laissant un rapport final derrière lui.
Il y'a maintenant un liste de choses à faire et il faut suivre le conseil de Ian en 2007 :
Donc au lieu de discuter sur pourquoi Mozilla devrait ou ne devrait pas inclure CACert.org, il faut aller donner un coups de main à CACert.org pour qu'ils arrivent au bout du travail nécessaire. Mais de tout ce que j'ai pu lire sur l'audit de CACert.org, jamais je n'ai vu la méthode de vérification d'identité être remise en cause.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: In other news
Posté par Thomas Douillard . Évalué à 2.
Peut être que la morale de l'histoire c'est qu'il vaut mieux plusieurs structures avec des petits moyens mais rigoureuse qu'une grosse structure avec de gros moyen mais qui n'arrive quand même pas à tout gérer.
[^] # Re: In other news
Posté par Littleboy . Évalué à 1.
Quand je dis que les problemes de secu doivent rendre prudent, c'est pas pour rien: un exemple
Donc, utilisation de PHP avec register_globals on, ajout d'adresse email sans verification pour certains domaines, faille permettant la creation de certificats clients sans verification, vulnerabilit liee a GPG, le tout dans un intervalle de quelques mois.
Et il faut lire la reponse de certaines personnes dans les commentaires, en particulier le type de Debian qui dit exactement la meme chose que toi (on s'en fout des problemes de secu du moment que c'est proche ideologiquement) et minimise tous les problemes.
Meme l'auteur de l'article est oblige de dire a la fin que ca n'est pas representatif de l'avis de CAcert ou Debian tellement les commentaires sont minables.
Donc voila, ca permet de se faire une idee de la securite (circa 2008) et du comportement des mecs de CAcert et ca ne donne clairement pas envie tant que l'audit n'est pas termine et que le comportement de ces gens n'a pas change.
[^] # Re: In other news
Posté par Zenitram (site web personnel) . Évalué à 1.
Ca craint quand même d'avoir une vision de la sécurité à la tête du client (car "idéologiquement", ce n'est que du préférentisme, souvent critiqué par les libristes quand on parle de proprio, donc bon une bonne grosse démonstration d'un faites ce que je dis, pas ce que je fais...).
Bon, je viens de vérifier, la distro que j'utilise (CentOS) a viré le certificat dans la v5 (ils l'avaient mis dans les v3 et v4, ajouté par rapport à RHEL?), ouf un peu plus de sécurité. Debian l'inclut toujours, ça avec le problème des clé SSH, ça rassure pas trop sur l'importance de la sécurité qu'a Debian (préférer le communautaire à la sécurité? Hum...). D'ailleurs, Canonical le retire (volontairement donc, puisqu'ils se basent sur Debian). On a donc bien d'un côté les idéologistes qui incluent à la tête du client, et de l'autre des mecs plus attentifs à la sécurité qui rejettent ce CA.
Donc bon, pour aller donner des leçons à Verisign et Comodo, faudrait commencer par balayer devant chez soit, j'ai quand même la grosse impression que certes CAcert a une politique de voir les gens avant de signer (bien), mais la sécurité du CA est trop faible pour que le bon point fasse qu'au global ce soit mieux. L'idée est bonne, la mise en pratique ne marche pas.
# CRL
Posté par Zenitram (site web personnel) . Évalué à 2.
Si je comprend bien, les navigateurs intègrent en dur une liste de certificats révoqués, mais seulement pour les gros : un faux certificat Google est émis, on le bloque, mais si je perds moi petit site mon certificat, je le dis à Comodo, il est dans ses CRL, mais celles-ci ne sont pas lues, super!
J'ai l'impression du coup que ça fait une nette séparation entre les gros et les petits, les gros peuvent avoir des certificats révoqués, pas les petits. Pourquoi les navigateurs ne téléchargent pas automatiquement les CRL (toutes les x minutes) des CA qu'ils ont plutôt que de faire des mise à jour du logiciel, en dur? Les CRL, ça marche si mal que ça? C'est pas sensé justement répondre au problème des certificats "volés"?
[^] # Re: CRL
Posté par Littleboy . Évalué à 4.
Ca existe, ca s'appelle OCSP, la plupart des navigateurs le supporte et font la verification, mais n'alertent pas l'utilisateur lorsque la verification echoue. Oue, FAIL!
[^] # Re: CRL
Posté par octane . Évalué à 3.
Télécharger les CRLs, mais en voilà une idée qu'elle est bonne![1]
Nous avons une centaine de CA dans nos navigateurs. CA à plusieurs étages. Si je prends un petit exemple, le certif de google pour le webmail.
On a trois niveaux: CA, sous CA, certificat. La CRL du certificat:
http://crl.thawte.com/ThawteSGCCA.crl : 34ko
Ca reste jouable. Pour la sous-CA:
http://crl.verisign.com/pca3.crl : 7Mo
Et là, c'est le drame. Le jour ou tu as un modem 56k tu pleures! Et le jour ou tous les navigateurs du monde iront chercher toutes les x minutes les CRL, là c'est verisign qui va pleurer. C'est pour ça que des zingénieurs ont inventés OCSP, mais que pas grand monde semble utiliser et c'est bien dommage :(
[1]J'ironise, mais la norme dit seulement qu'il faut vérifier la CRL avant de faire une opération sur les certificats. Mais comment gérer la CRL, ou aller la chercher, qu'en faire, etc.. pas un mot!
[^] # Re: CRL
Posté par jcs (site web personnel) . Évalué à 3.
Ça commence à changer, on rencontre de plus en plus de déclaration de répondeurs OCSP dans les certificats (même les certificats SSL qui ne sont pas chers). Mais je me rends compte que Firefox par exemple considère valide par défaut un certificat dont le statut de révocation est inconnu (ou quand il n'arrive pas à se connecter au répondeur OCSP). Et ça c'est un comportement très discutable.
Les CRLs sont valides pendant un certain temps (entre 1 jour et 1 semaine d'habitude), donc on ne les télécharge pas toutes les x minutes, mais plutôt tous les jours/semaines et elles sont mises en cache. Les proxies ça peut aussi aider. Après c'est sûr que 7 Mo tous les jours à travers un modem 56K, c'est rude :)
[^] # Re: CRL
Posté par jcs (site web personnel) . Évalué à 3.
Où chercher la CRL : Commencer par l'extension CRLDistributionPoints dans le certificat X.509, elle est presque toujours présente ; on y trouve des URL où la CRL peut être téléchargée. La CRL c'est une des parties les plus critiques d'une PKI, et c'est le service à remettre en route le plus rapidement possible en cas de sinistre de l'infrastructure. Il est clairement dans l'intérêt de la CA d'indiquer où la trouver :)
Comment utiliser la CRL : l'algorithme de validation X.509 est décrit en détail dans la RFC 5280 (section 6). Le traitement des CRL y est également précisé. Par contre on ne peut pas nier que c'est un algorithme complexe et il faut bien comprendre X509 qui l'implémenter correctement. En outre cette implémentation doit être assez souple pour s’accommoder de l'existant (certificats/CRL/réponses OCSP émis par des PKI qui respectent mal les normes et standards, on plus souvent qui ont foiré leur configuration).
# La motivation du hacker
Posté par Thrillseeker . Évalué à 1.
Il est intéressant de lire son message pour voir comment il se considère (il a une très grande estime de lui-même) et quels sont ses objectifs:
Les sujets qu'il aborde:
Rien de nouveau mais le fait qu'il en parle permet de ne pas oublier.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.