Pas tant que ca. Pour continuer dans ton analogie: les constructeurs de voitures n'ont pas le droit de faire la promo d'une voiture sur sa vitesse de pointe, c'est une incitation a dépasser les 130km/h.
En même temps ça fait un mois que je vois une publicité de Citroën dont le slogan est : "Ne respectez pas les règles, fixez-les !", à priori c'est permis de faire de la publicité en incitant à violer les règles de circulation.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Non mais en fait l'init c'est un truc qui, dans le cas idéal, devrait se produire une fois dans la vie d'un serveur.
Les gens qui parlent autant de l'importance d'init c'est ceux qui n'ont jamais vu démarrer un serveur qui met 10 minutes à arriver au chargeur de démarrage. Et l'exécution des scripts c'est infime car généralement ces scripts lancent des gros logiciels plein de données, donc l'optmisation est parfaitement inutile.
Ensuite, quand tu as un problème au démarrage, des scripts shell c'est bien plus facile à corriger.
Et dans certains cas les services tu les vire du démarrage parce que tu as une interaction pour lancer (tout ce qui nécessite un certificat SSL, tu ne laisses pas la clé privée non-chiffrée sur un serveur, donc entrer le mot de passe).
Lennart travaille en direction d'un linux pour le bureau, mais s'éloigne d'un linux pour le serveur.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Il n'est pas impossible de diffuser les certificats SSH corrompus, le cas Debian le démontre bien. Tu me diras qu'il faut une mise à jour et non pas l'utilisation des CRL, mais justement les derniers cas pour SSL montre bien que les CRL ou OCSP ne sont d'aucune aide, les certificats corrompus sont passé par des mise à jour. C'est un cas où il y'a encore du travail, peu importe le protocole.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client.
If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.
Le nom est effectivement connu de la personne et sa résolution vers une adresse est faite par le DNS (principalement). Dans le cas, précité par Zenitram, où la clé privé du serveur a été volée et que l'attaquant utilise un DNS menteur pour faire atterrir example.com sur son serveur au lieu du bon, tu es cuit la même chose. Mais dans ce cas, il faut 2 attaques : une pour obtenir la clé privée (SSL ou SSH) et une autre pour faire mentir le DNS, donc on arrive sur le serveur de l'attaquant ayant volé la clé.
Et si tu as pris la discussion en cours (donc pas lu le sujet de départ), non SSL n'a rien à faire, fondamentalement, avec le DNS.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Non tu racontes n'importe quoi et à chaque question que j'ai posé tu as changé de sujet et surtout, tu ne prends pas la peine de lire les documents que j'ai proposé.
Enfin je te laisses avec ton SSL super-sécurisé et, même si je comprend rien, je retourne à mon travail.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Oui il contrôle que le nom taper dans la bar du navigateur soit identique à celui du certificat. Un DNS menteur pourrait être utiliser exactement comme dans le cas cité par Zenitram.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
J'ai oublié un truc, SSL, c'est l'enregistrement DNS qui permet l'identification du serveur ? Je crois bien que oui ... je crois bien que tu en arrives à démonter toi même SSL :) Tu comprends, petit à petit ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Bon je fais vite : actuellement avec SSL tu ne sais jamais à qui tu te connectes puisque personne ne peut (dans le sens avoir la capacité) te certifier que le serveur en question est bien le bon que tu veux. En cas de pépin, comme on a vu avec des affaires à la DigiNotar ou Comodo, il peut se passer presque un mois avant que tout le monde soit au courant (dans le sens la diffusion des clés soit faite).
Avec un protocole comme SSH, tu as la 1er connexion qui pose problème (et ça il y'a des solutions proposées existantes genre avec l'enregistrement DNS ou en passant par des réseaux de confiance, mais bref, j'ai dis que je faisais vite). Une fois la première connexion effectuée, tu as une garantie que le serveur est toujours le même, en cas de problèmes la révocations des clés se fait à la connexion du client (donc pas de temps mort, tu te connectes, tu sais que la clé a changé) et il n'y a pas 1 et 1 seul point central à compromettre pour que la sécurité globale s'effondre (avec SSL, un seul CA compromis et la sécurité s'effondre).
Mais bien sûr... J'ai plutôt l'impression que tu n'as pas bien compris à quel besoin SSL répond, vu ce que tu proposes comme "mieux".
Je crois, non, je suis certain que tu n'as rien compris à X.509 et SSL. Et je sais quand utiliser X.509, sinon je ne l'utiliserais pas.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Non, dans les conditions actuelles la moins pire est celle utilisée par le protocole SSH, la seule et unique raison de la survie de SSL c'est qu'il s'agit d'une machine à fric énorme : tu paies des prix de fou pour rien vu que personne dans le circuit peut offrir la moindre garantie.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Donc c'est l'implémentation de SSL qui est mauvaise [...]
C'est le point de départ de cette discussion (les CA font n'importe quoi, les implémentations aussi, ...), mais avec la sécurité, on peut pas jouer, soit c'est sécurisé, soit ça l'est pas; un truc genre "ouais c'est presque bon, mais bon on a pas mieux" : c'est pas sécurisé. Donc SSL ne garantit rien. Ta page Wikipedia en HTTPS peut, actuellement, de tellement d'autres personnes que Wikipedia, autant faire un geste pour la planète et aller en HTTP (calcul en moins, énergie consommée en moins).
Mais il y'a d'autres problèmes avec SSL parce qu'il est dérivé de X.509 et toutes les parties X.500 ont été gardées mais ne sont pas utilisables dans un annuaire LDAP, de plus il y'a trop de truc laissé à l'interprétation de l'implémentation.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
C'est pour ça que j'utilise le pronom "un" au lieu de "le" ... j'ai maintenu que ça serait "un outil" ou "aux outils [...] Wikipedia en ferait partie".
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
C'est cool, tu as la solution parfaite au problème. Bizarrement, personne n'y croit.
Normal, ce n'est pas une solution. Je te donnais un cas où ta fameuse (et fumeuse) autorité de confiance (je tiens à dire que ce terme n'apparaît pas une seule fois dans la norme X.509 ni dans les RFC) fournissait un moyen automatique d'usurper "l'identité" de n'importe quel site Web. Et le fait que tu n'aies aucunement clarifier ta position sur mon piège m'amène à cette conclusion : tu n'as jamais lu la série de documents X.500 (je sais c'est chiant a lire, mais c'est un peu essentiel pour comprendre SSL).
Il s'agit de votre tiers de confiance commun. Tu refuses le tiers? Ok, donc charge à toi de te mettre d'accord avec Wikipedia pour votre transfert, car tu refuses le tiers proposé. Je te rassure : Wikipedia dira : tu fais chier, j'en propose un, si tu n'es pas content je vais pas m'emmerder avec un gus chieurs comme toi, mon tiers de confiance étant accepté par tout le monde même sous Linux.
Bon alors l'autorité de certification, d'après X.509, c'est "an authority trusted by one or more users to create and assign certificates" (une autorité ayant la confiance de un ou plusieurs utilisateurs pour créer et assigner des certificats) (c'est repris dans la RFC 1422). X.509 définit aussi le terme confiance et ce qui devient intéressant : "[...] the entity shall be certain that it can trust the autherity to create only valid and reliable certificates." ([...] l'entité doit être certaine qu'elle puisse faire confiance en l'autorité pour produire uniquement des certificats valides et fiables).
Section 6.1 de X.509 indique clairement qu'une signature d'un CA sur une clé publique certifie la relation entre le sujet du certificat et le certificat. Un problème : aucune garantie n'est donnée par les CA à l'heure actuelle.
Ensuite la RFC 5280 inique clairement :
If an attacker obtains the private key unnoticed, the attacker may issue bogus certificates and CRLs. Existence of bogus certificates and CRLs will undermine confidence in the system. If such a compromise is detected, all certificates issued to the compromised CA MUST be revoked, preventing services between its users and users of other CA [...]
Est-ce que ça a été appliqué dans les derniers cas, genre Comodo ? Non.
Et la liste de problème est encore longue, je te laisse aller voir la page wikipedia sur le sujet X.509 ;) moi j'en ai un peu marre là.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
C'est ce que je dis. On ne peut pas avoir confiance en Wikipedia uniquement, il faut vérifier l'information. Mais ce que j'ai remarqué : les gens font confiances à Wikipedia sans chercher plus loin, donc si je voudrais monter une société à la 1984, Wikipedia serait un outil très intéressant et intégrer dans la falsification de la vérité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Personne ne sait, c'est le début du problème. Rien empêche, ton tiers de confiance, de générer une paire de clé pour chaque clé publique signée et de distribuer cette pair de clés auprès de tous ses clients qui auraient souscrit à l'abonnement "surveillance automatique d'Internet". Comme on ne sait pas qui fait quoi et qui est qui, on sait pas ce qui est signé chez qui par le tiers de confiance.
Non parce que, d'expérience, c'est par SMTP/IMAP que j'ai obtenu des certificats de sécurités auprès d'un CA.
Vire ton fournisseur. Perso, c'est par accès SSL (dont j'ai confiance).
Et ? Parce qu'il y'a piège ici :)
Tu sais ce qu'est un tiers de confiance? Tu ne fais pas confiance à ton tiers --> Négocie avec Wikipedia, qui lui dit "je t'emmerde si t'es pas content, va voir ailleurs". Si lui pense aussi qu'il y a un problème, encore une fois, vous vous mettez d'accord sur le tiers.
Un tiers de confiance, c'est une entité en qui on a confiance de la véracité des informations fournies. Donc dans ce cas il s'agit du tiers de confiance de Wikipedia, pas du mien. Et Wikipedia n'est pas plus un tiers de confiance que le monsieur qui m'envoit des courriers électroniques me proposant de gagner plein d'argent si je l'aide ou que la fille qui passe une nuit dans mon lit et que je ne reverrais plus jamais (d'ailleurs j'ai certainement donné un faux nom).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Tu attaques gratuitement SSL parce que des tiers de confiance ne sont plus de confiance. Il n'y a pas de rapport.
Pour un protocole dont la sécurité est basée sur les tiers de confiance, je trouve qu'il y'a un rapport assez flagrant.
Dans le reste de ton message tu omets beaucoup de détails sur SSL. Comment je sais que le CA d'Equifax dans mon navigateur est le vrai d'Equifax vraiment ? Je vais regarder sur le site d'Equifax s'il donne l'empreinte SHA-1 du certificat, ok. Quel protocole sécurisé je vais utiliser pour m'assurer que l'empreinte SHA-1 n'a pas été modifié, ainsi que le CA que je télécharge depuis le site d'Equifax, durant le transport ? HTTPS, le problème : je n'ai aucun tier de confiance, j'ai quoi ?
Ok, continuons, par quelle méthode Wikipedia a obtenu son certificat ? Non parce que, d'expérience, c'est par SMTP/IMAP que j'ai obtenu des certificats de sécurités auprès d'un CA. Comment Equifax a vérifié l'identité de Wikipedia ? D'expérience, SMTP/IMAP de document facilement falsifiable (une carte d'identité scannée en n/b ça passe tranquille).
Et Equifax, c'est qui d'abord ? Quel gouvernement, société ou peut-être quel gamin de douze ans ? Leurs serveurs, ils ont quoi comme portes dérobées, les clés sont-elles en sécurités ? Leurs outils de gestion de certificat, quel code est utilisé ? Sont-ils sécurisés ? Qui les a écrit ? La mafia, un gouvernement, un gamin de douze ans ?
Bref, il y'a une quantité énorme de question que le protocole SSL ne solutionne pas, pratiquement tous les CA ont été compromis ou on fait des erreurs à la "vas-y que je te fasse un certificat EV 512 bits de localhost expirant dans 10 ans" ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Oui enfin sauf que dans 1984, ce qui permet de changer les versions historiques des faits en permanence, c'est la centralisation poussée à l'extrême (et le fait que les anciennes versions deviennent illégales).
C'est ce que je pointais et ce que le journal pointait :
Il semble bien que Wikipédia, malgré tous ses défauts régulièrement pointés pas les médias traditionnels, a réussi à faire le vide autour d'elle.
Le SSL garantit rien. Les Root CA sont pourris (les dernières attaquent sont là pour le montrer), ne respectent pas les règles (des "localhost" (ou pour des IP privée, ou autre) en certificat EV ou des clés de 512 bits ça existe https://www.eff.org/files/ccc2010.pdf), le protocole est mal fichu (comment tu gères les révoquations http://www.cypherpunks.to/~peter/T2_Key_Management.pdf (ou poses-toi la question "Comment je sais si un certificat est valide ou pas ?" et essaie d'y répondre)), les implémentations foireuses (de moins en moins, c'est vrai), ... Et combien de pays ont un Root CA ? De tête je peux te citer la Suisse, la France, l'Allemagne et les États-Unis. Il devrait en avoir certainement plus, regarde la liste de ton navigateur.
Voilà, voilà ... SSL c'est pour brûler du temps processeur et faire croire "qu'on" se soucie de la sécurité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Il y'a quelque temps, je songeais aux outils nécessaire pour créer une société digne de 1984. Wikipedia en ferait partie. Actuellement une telle majorité de personnes utilisent Wikipedia comme source de "vérité" qu'un "simple" proxy réécrivant les articles à la volée suffirait à créer une vérité intemporelle (X est en guerre avec Y et a toujours été en guerre).
Bien entendu le problème n'est pas Wikipedia mais le fait qu'on ne puisse identifier si un article est réellement l'original où s'il a été modifié durant le transport.
En tous cas, ça serait un projet marrant que de créer "wiki1984" où l'on retrouve le même contenu que Wikipedia, mais rendu intemporel. Et je suis certain qu'il soit possible de vendre ça à nos démocraties (et, naturellement, aux dictatures restantes).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
"Nous avons gagné et nous ne nous en sommes pas rendu compte" ... ce que disais Jeremy Allison début septembre 2011 : http://www.h-online.com/open/features/We-won-and-we-didn-t-notice-a-conversation-with-Jeremy-Allison-of-Samba-1334992.html et c'est assez vrai. Le logiciel Libre est actuellement incontournable, présent et nécessaire sur une quantité de système astronomique (de Microsoft partant de la pile tcp/ip BSD à Android en passant par LAMP pour les serveurs Web et bien d'autres projets Libres dont l'industrie ne peut se passer).
Combien de personnes gagnent leur vie grâce au logiciel Libre ? Combien d'entreprises préfèrent faire du Libre pour leurs projets ? ...
La FSF a 1 million de dollars de budget par an. Face aux géants du milieu, Apple, Oracle, Microsoft... Ce n'est même pas l'équivalent de leur budget café.
Le logiciel Libre a le support de grands noms comme IBM, RedHat, Google, ... et la FSF n'est qu'un autre des acteurs supportant le Libre, elle a ses objectifs et ses budgets. Son travail est nécessaire dans l'ensemble, mais elle n'est pas seule.
Difficulté de recrutement et démotivation des anciens
Ils sont trop occupés à coder, documenter, ... ?
Debian is dying, tué par ubuntu
"Debian is dying" autant que "Apple is dying" dans les années 90-00. Le projet Debian innove régulièrement, continu à produire des très bonne distribution et a un impacte important dans le monde des distributions. Ubuntu fait son chemin avec des objectifs différents, mais je ne crois pas qu'Ubuntu ait tué Debian, je dirais qu'elle a renforcé Debian : Ubuntu amène une grande quantité d'utilisateurs à se familiariser avec les outils Debian : aptitude, apt-get, ... Ces utilisateurs qui vont, peut-être un jour, devenir administrateur système (accidentellement ou pas) et choisir Debian GNU/Linux sur leur serveur et Debian GNU/kFreeBSD pour avoir à PF en firewall.
Les technologies récentes (cloud computing, e-books, téléphonie mobile, notamment Android, plateformes sociales...) n'ont pas pu être correctement traité par la FSF et les développements libres.
Mon eBook est basé sur Linux et le code source est accessible. Le fabricant de mon smartphone s'est engagé, actes à l'appui, à rendre ses smartphones plus "hackable" en fournissant les outils pour "rooter" le smartphone. Facebook fourni la majorité de ces outils en logiciel Libre et à même opensourcer son datacenter http://opencompute.org ...
Alors que la GPLv2 était un facteur de réunification des développements (tous sous une même bannière), la sortie de la v3 a découpé les fragiles communautés en 2 camps. C'est toujours facteur de stress.
Et BSD ? Et WTFPL ? Il y'a plus de choix dans les licences. C'est pas un drame.
Intégrisme dans les positions de la FSF
C'est justement son job : être l'aile droite conservatrice dur du Libre. Si elle commence à devenir laxiste, bonjour le n'importe quoi.
Richard Stallman, le gaffeur
C'est un homme. Personnellement j'ai pas trouvé son message sur S. Jobs déplacé et j'ai même trouvé ça très bien senti, mais c'est subtil, très subtil. Il ne dit pas "je suis content [blabla]", ça c'est le uniquement ce qui a été reporté par les médias. Il reprend une phrase d'un maire d'une cité (je me souviens plus de laquelle) parlant de son prédécesseur corrompu. Et c'est là qu'est tout le message : S. Jobs a corrompu le Libre, selon lui (enfin je vais pas faire une analyse de texte complète).
Bref, c'est un homme et il plaît ou pas et s'il venait à disparaître, se corrompre, ... le logiciel Libre survivra.
Je crois que le Libre est loin d'avoir des problèmes et que son importance et son influence n'est que grandissante.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Justement, c'est pas une fonctionnalité unique à systemd, mais bien une nouvelle fonctionnalité de Linux. Elle peut être utilisée avec init et, là où c'est intéressant, il est plus facile pour un administrateur de modifier un init classique pour avoir de nouvelles fonctionnalités de Linux. Par contre, pour systemd, il faut attendre qu'en upstream il intègre ça.
Je vois donc toujours un avantage pour init classique sur serveur.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Et ? Debian est une distro très utilisé dans le monde professionnel, en accord avec son motto de "système universel". Si systemd est une avancée pour les utilisateurs de Debian, on va pas priver 99.99% des utilisateurs pour les 0.01% qui utilisent Debian/KFreeBSD (dont la plupart ne l'utilisent pas comme système principal ou en production).
Mais systemd est-il une avancée réelle ? Sur les serveurs je crois que le système init ne nécessite pas vraiment de remplacement : il fonctionne, il est simple et il n'y a pas vraiment besoin de démarrage en parallèle. Sur les machines personnelles, on se dirige vers l'utilisation de l'hibernation, donc le système redémarre une fois par mois.
Et, pour info, systemd est dans la branche testing de Debian, même si le projet n'en fait pas son init par défaut, il sera disponible pour celui qui le souhaite.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
De plus, les agences de notations sont des agents de déstabilisation de la zone Euro par des forces étrangères [...]
La zone Euro s'est déstabilisée d'elle même, il y avait des règles (Maastricht) mais pratiquement aucun membre de la zone Euro ne respecte ces règles. Il n'y a pas de complot, juste un système corrompu par ses membres.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Bonne nouvelle?
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Le filtrage du net aux mains du privé ? . Évalué à 6.
En même temps ça fait un mois que je vois une publicité de Citroën dont le slogan est : "Ne respectez pas les règles, fixez-les !", à priori c'est permis de faire de la publicité en incitant à violer les règles de circulation.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Que faut-il penser de Lennart qui casse tout ?. Évalué à 10.
Non mais en fait l'init c'est un truc qui, dans le cas idéal, devrait se produire une fois dans la vie d'un serveur.
Les gens qui parlent autant de l'importance d'init c'est ceux qui n'ont jamais vu démarrer un serveur qui met 10 minutes à arriver au chargeur de démarrage. Et l'exécution des scripts c'est infime car généralement ces scripts lancent des gros logiciels plein de données, donc l'optmisation est parfaitement inutile.
Ensuite, quand tu as un problème au démarrage, des scripts shell c'est bien plus facile à corriger.
Et dans certains cas les services tu les vire du démarrage parce que tu as une interaction pour lancer (tout ce qui nécessite un certificat SSL, tu ne laisses pas la clé privée non-chiffrée sur un serveur, donc entrer le mot de passe).
Lennart travaille en direction d'un linux pour le bureau, mais s'éloigne d'un linux pour le serveur.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'aimerai bien savoir comment il vont taxer ça
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal [ HS Agriculture : ] la réutilisation des semences sera sanctionnée. Évalué à 3.
Il y'a aussi, dans le domaine des OGM, quelque chose de semblable à l'hybridation http://en.wikipedia.org/wiki/Terminator_Technology
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
Il n'est pas impossible de diffuser les certificats SSH corrompus, le cas Debian le démontre bien. Tu me diras qu'il faut une mise à jour et non pas l'utilisation des CRL, mais justement les derniers cas pour SSL montre bien que les CRL ou OCSP ne sont d'aucune aide, les certificats corrompus sont passé par des mise à jour. C'est un cas où il y'a encore du travail, peu importe le protocole.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à -2.
RFC 2818 dit :
Le nom est effectivement connu de la personne et sa résolution vers une adresse est faite par le DNS (principalement). Dans le cas, précité par Zenitram, où la clé privé du serveur a été volée et que l'attaquant utilise un DNS menteur pour faire atterrir example.com sur son serveur au lieu du bon, tu es cuit la même chose. Mais dans ce cas, il faut 2 attaques : une pour obtenir la clé privée (SSL ou SSH) et une autre pour faire mentir le DNS, donc on arrive sur le serveur de l'attaquant ayant volé la clé.
Et si tu as pris la discussion en cours (donc pas lu le sujet de départ), non SSL n'a rien à faire, fondamentalement, avec le DNS.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
Non tu racontes n'importe quoi et à chaque question que j'ai posé tu as changé de sujet et surtout, tu ne prends pas la peine de lire les documents que j'ai proposé.
Enfin je te laisses avec ton SSL super-sécurisé et, même si je comprend rien, je retourne à mon travail.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 0.
Oui il contrôle que le nom taper dans la bar du navigateur soit identique à celui du certificat. Un DNS menteur pourrait être utiliser exactement comme dans le cas cité par Zenitram.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
J'ai oublié un truc, SSL, c'est l'enregistrement DNS qui permet l'identification du serveur ? Je crois bien que oui ... je crois bien que tu en arrives à démonter toi même SSL :) Tu comprends, petit à petit ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 2.
Bon je fais vite : actuellement avec SSL tu ne sais jamais à qui tu te connectes puisque personne ne peut (dans le sens avoir la capacité) te certifier que le serveur en question est bien le bon que tu veux. En cas de pépin, comme on a vu avec des affaires à la DigiNotar ou Comodo, il peut se passer presque un mois avant que tout le monde soit au courant (dans le sens la diffusion des clés soit faite).
Avec un protocole comme SSH, tu as la 1er connexion qui pose problème (et ça il y'a des solutions proposées existantes genre avec l'enregistrement DNS ou en passant par des réseaux de confiance, mais bref, j'ai dis que je faisais vite). Une fois la première connexion effectuée, tu as une garantie que le serveur est toujours le même, en cas de problèmes la révocations des clés se fait à la connexion du client (donc pas de temps mort, tu te connectes, tu sais que la clé a changé) et il n'y a pas 1 et 1 seul point central à compromettre pour que la sécurité globale s'effondre (avec SSL, un seul CA compromis et la sécurité s'effondre).
Je crois, non, je suis certain que tu n'as rien compris à X.509 et SSL. Et je sais quand utiliser X.509, sinon je ne l'utiliserais pas.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
Non, dans les conditions actuelles la moins pire est celle utilisée par le protocole SSH, la seule et unique raison de la survie de SSL c'est qu'il s'agit d'une machine à fric énorme : tu paies des prix de fou pour rien vu que personne dans le circuit peut offrir la moindre garantie.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 2.
C'est le point de départ de cette discussion (les CA font n'importe quoi, les implémentations aussi, ...), mais avec la sécurité, on peut pas jouer, soit c'est sécurisé, soit ça l'est pas; un truc genre "ouais c'est presque bon, mais bon on a pas mieux" : c'est pas sécurisé. Donc SSL ne garantit rien. Ta page Wikipedia en HTTPS peut, actuellement, de tellement d'autres personnes que Wikipedia, autant faire un geste pour la planète et aller en HTTP (calcul en moins, énergie consommée en moins).
Mais il y'a d'autres problèmes avec SSL parce qu'il est dérivé de X.509 et toutes les parties X.500 ont été gardées mais ne sont pas utilisables dans un annuaire LDAP, de plus il y'a trop de truc laissé à l'interprétation de l'implémentation.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 2.
C'est pour ça que j'utilise le pronom "un" au lieu de "le" ... j'ai maintenu que ça serait "un outil" ou "aux outils [...] Wikipedia en ferait partie".
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
Normal, ce n'est pas une solution. Je te donnais un cas où ta fameuse (et fumeuse) autorité de confiance (je tiens à dire que ce terme n'apparaît pas une seule fois dans la norme X.509 ni dans les RFC) fournissait un moyen automatique d'usurper "l'identité" de n'importe quel site Web. Et le fait que tu n'aies aucunement clarifier ta position sur mon piège m'amène à cette conclusion : tu n'as jamais lu la série de documents X.500 (je sais c'est chiant a lire, mais c'est un peu essentiel pour comprendre SSL).
Bon alors l'autorité de certification, d'après X.509, c'est "an authority trusted by one or more users to create and assign certificates" (une autorité ayant la confiance de un ou plusieurs utilisateurs pour créer et assigner des certificats) (c'est repris dans la RFC 1422). X.509 définit aussi le terme confiance et ce qui devient intéressant : "[...] the entity shall be certain that it can trust the autherity to create only valid and reliable certificates." ([...] l'entité doit être certaine qu'elle puisse faire confiance en l'autorité pour produire uniquement des certificats valides et fiables).
Section 6.1 de X.509 indique clairement qu'une signature d'un CA sur une clé publique certifie la relation entre le sujet du certificat et le certificat. Un problème : aucune garantie n'est donnée par les CA à l'heure actuelle.
Ensuite la RFC 5280 inique clairement :
Est-ce que ça a été appliqué dans les derniers cas, genre Comodo ? Non.
Et la liste de problème est encore longue, je te laisse aller voir la page wikipedia sur le sujet X.509 ;) moi j'en ai un peu marre là.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
C'est ce que je dis. On ne peut pas avoir confiance en Wikipedia uniquement, il faut vérifier l'information. Mais ce que j'ai remarqué : les gens font confiances à Wikipedia sans chercher plus loin, donc si je voudrais monter une société à la 1984, Wikipedia serait un outil très intéressant et intégrer dans la falsification de la vérité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 2.
Personne ne sait, c'est le début du problème. Rien empêche, ton tiers de confiance, de générer une paire de clé pour chaque clé publique signée et de distribuer cette pair de clés auprès de tous ses clients qui auraient souscrit à l'abonnement "surveillance automatique d'Internet". Comme on ne sait pas qui fait quoi et qui est qui, on sait pas ce qui est signé chez qui par le tiers de confiance.
Et ? Parce qu'il y'a piège ici :)
Un tiers de confiance, c'est une entité en qui on a confiance de la véracité des informations fournies. Donc dans ce cas il s'agit du tiers de confiance de Wikipedia, pas du mien. Et Wikipedia n'est pas plus un tiers de confiance que le monsieur qui m'envoit des courriers électroniques me proposant de gagner plein d'argent si je l'aide ou que la fille qui passe une nuit dans mon lit et que je ne reverrais plus jamais (d'ailleurs j'ai certainement donné un faux nom).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
Pour un protocole dont la sécurité est basée sur les tiers de confiance, je trouve qu'il y'a un rapport assez flagrant.
Dans le reste de ton message tu omets beaucoup de détails sur SSL. Comment je sais que le CA d'Equifax dans mon navigateur est le vrai d'Equifax vraiment ? Je vais regarder sur le site d'Equifax s'il donne l'empreinte SHA-1 du certificat, ok. Quel protocole sécurisé je vais utiliser pour m'assurer que l'empreinte SHA-1 n'a pas été modifié, ainsi que le CA que je télécharge depuis le site d'Equifax, durant le transport ? HTTPS, le problème : je n'ai aucun tier de confiance, j'ai quoi ?
Ok, continuons, par quelle méthode Wikipedia a obtenu son certificat ? Non parce que, d'expérience, c'est par SMTP/IMAP que j'ai obtenu des certificats de sécurités auprès d'un CA. Comment Equifax a vérifié l'identité de Wikipedia ? D'expérience, SMTP/IMAP de document facilement falsifiable (une carte d'identité scannée en n/b ça passe tranquille).
Et Equifax, c'est qui d'abord ? Quel gouvernement, société ou peut-être quel gamin de douze ans ? Leurs serveurs, ils ont quoi comme portes dérobées, les clés sont-elles en sécurités ? Leurs outils de gestion de certificat, quel code est utilisé ? Sont-ils sécurisés ? Qui les a écrit ? La mafia, un gouvernement, un gamin de douze ans ?
Bref, il y'a une quantité énorme de question que le protocole SSL ne solutionne pas, pratiquement tous les CA ont été compromis ou on fait des erreurs à la "vas-y que je te fasse un certificat EV 512 bits de localhost expirant dans 10 ans" ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
Oui, il faut retirer tous les CA. Mais après tu ne sais plus si le certificat Wikipedia est le bon, donc n'importe lequel est correct.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 2.
C'est ce que je pointais et ce que le journal pointait :
Une centralisation de fait.
https://linuxfr.org/users/patrick_g/journaux/la-mort-de-knol-est-annonc%C3%A9e#comment-1293747
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 1.
Le SSL garantit rien. Les Root CA sont pourris (les dernières attaquent sont là pour le montrer), ne respectent pas les règles (des "localhost" (ou pour des IP privée, ou autre) en certificat EV ou des clés de 512 bits ça existe https://www.eff.org/files/ccc2010.pdf), le protocole est mal fichu (comment tu gères les révoquations http://www.cypherpunks.to/~peter/T2_Key_Management.pdf (ou poses-toi la question "Comment je sais si un certificat est valide ou pas ?" et essaie d'y répondre)), les implémentations foireuses (de moins en moins, c'est vrai), ... Et combien de pays ont un Root CA ? De tête je peux te citer la Suisse, la France, l'Allemagne et les États-Unis. Il devrait en avoir certainement plus, regarde la liste de ton navigateur.
Voilà, voilà ... SSL c'est pour brûler du temps processeur et faire croire "qu'on" se soucie de la sécurité.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# 1984 et Wikipedia
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal La mort de Knol est annoncée. Évalué à 3.
Il y'a quelque temps, je songeais aux outils nécessaire pour créer une société digne de 1984. Wikipedia en ferait partie. Actuellement une telle majorité de personnes utilisent Wikipedia comme source de "vérité" qu'un "simple" proxy réécrivant les articles à la volée suffirait à créer une vérité intemporelle (X est en guerre avec Y et a toujours été en guerre).
Bien entendu le problème n'est pas Wikipedia mais le fait qu'on ne puisse identifier si un article est réellement l'original où s'il a été modifié durant le transport.
En tous cas, ça serait un projet marrant que de créer "wiki1984" où l'on retrouve le même contenu que Wikipedia, mais rendu intemporel. Et je suis certain qu'il soit possible de vendre ça à nos démocraties (et, naturellement, aux dictatures restantes).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# "We won and we didn't notice it"
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chute des valeurs du logiciel libre et perte d'influence de la FSF. Évalué à 9.
"Nous avons gagné et nous ne nous en sommes pas rendu compte" ... ce que disais Jeremy Allison début septembre 2011 : http://www.h-online.com/open/features/We-won-and-we-didn-t-notice-a-conversation-with-Jeremy-Allison-of-Samba-1334992.html et c'est assez vrai. Le logiciel Libre est actuellement incontournable, présent et nécessaire sur une quantité de système astronomique (de Microsoft partant de la pile tcp/ip BSD à Android en passant par LAMP pour les serveurs Web et bien d'autres projets Libres dont l'industrie ne peut se passer).
Combien de personnes gagnent leur vie grâce au logiciel Libre ? Combien d'entreprises préfèrent faire du Libre pour leurs projets ? ...
Le logiciel Libre a le support de grands noms comme IBM, RedHat, Google, ... et la FSF n'est qu'un autre des acteurs supportant le Libre, elle a ses objectifs et ses budgets. Son travail est nécessaire dans l'ensemble, mais elle n'est pas seule.
Ils sont trop occupés à coder, documenter, ... ?
"Debian is dying" autant que "Apple is dying" dans les années 90-00. Le projet Debian innove régulièrement, continu à produire des très bonne distribution et a un impacte important dans le monde des distributions. Ubuntu fait son chemin avec des objectifs différents, mais je ne crois pas qu'Ubuntu ait tué Debian, je dirais qu'elle a renforcé Debian : Ubuntu amène une grande quantité d'utilisateurs à se familiariser avec les outils Debian : aptitude, apt-get, ... Ces utilisateurs qui vont, peut-être un jour, devenir administrateur système (accidentellement ou pas) et choisir Debian GNU/Linux sur leur serveur et Debian GNU/kFreeBSD pour avoir à PF en firewall.
Mon eBook est basé sur Linux et le code source est accessible. Le fabricant de mon smartphone s'est engagé, actes à l'appui, à rendre ses smartphones plus "hackable" en fournissant les outils pour "rooter" le smartphone. Facebook fourni la majorité de ces outils en logiciel Libre et à même opensourcer son datacenter http://opencompute.org ...
Et BSD ? Et WTFPL ? Il y'a plus de choix dans les licences. C'est pas un drame.
C'est justement son job : être l'aile droite conservatrice dur du Libre. Si elle commence à devenir laxiste, bonjour le n'importe quoi.
C'est un homme. Personnellement j'ai pas trouvé son message sur S. Jobs déplacé et j'ai même trouvé ça très bien senti, mais c'est subtil, très subtil. Il ne dit pas "je suis content [blabla]", ça c'est le uniquement ce qui a été reporté par les médias. Il reprend une phrase d'un maire d'une cité (je me souviens plus de laquelle) parlant de son prédécesseur corrompu. Et c'est là qu'est tout le message : S. Jobs a corrompu le Libre, selon lui (enfin je vais pas faire une analyse de texte complète).
Bref, c'est un homme et il plaît ou pas et s'il venait à disparaître, se corrompre, ... le logiciel Libre survivra.
Je crois que le Libre est loin d'avoir des problèmes et que son importance et son influence n'est que grandissante.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 5.
Justement, c'est pas une fonctionnalité unique à systemd, mais bien une nouvelle fonctionnalité de Linux. Elle peut être utilisée avec init et, là où c'est intéressant, il est plus facile pour un administrateur de modifier un init classique pour avoir de nouvelles fonctionnalités de Linux. Par contre, pour systemd, il faut attendre qu'en upstream il intègre ça.
Je vois donc toujours un avantage pour init classique sur serveur.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 8.
Mais systemd est-il une avancée réelle ? Sur les serveurs je crois que le système init ne nécessite pas vraiment de remplacement : il fonctionne, il est simple et il n'y a pas vraiment besoin de démarrage en parallèle. Sur les machines personnelles, on se dirige vers l'utilisation de l'hibernation, donc le système redémarre une fois par mois.
Et, pour info, systemd est dans la branche testing de Debian, même si le projet n'en fait pas son init par défaut, il sera disponible pour celui qui le souhaite.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: war inside my head
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal CCC au pape. Évalué à 4.
J'ai vu ça dans les toilettes d'un bar glauque à Berlin, ça a été l'illumination de ma nuit (avant de sombrer dans l'absinthe).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: war inside my head
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal CCC au pape. Évalué à 4.
La zone Euro s'est déstabilisée d'elle même, il y avait des règles (Maastricht) mais pratiquement aucun membre de la zone Euro ne respecte ces règles. Il n'y a pas de complot, juste un système corrompu par ses membres.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell