Je retiens de la discussion que la seule solution viable à long terme est d'empécher un downgrade.
tout le reste, c'est gérer ce manque et ca ne terminera jamais (le jour oú SHA256 a un petit problème, rebelote punition pour ceux pouvant évoluer vers SHA3).
Le temps est surement venu d'arrêter d'utiliser RC4 (et 3DES). Je crois que les seuls utilisateurs que ça exclue sont ceux de IE 6, et ça commence à faire vraiment plus grand monde, même dans les pays « pauvres ».
Virer 3DES? Ca vire le dernier IE sur WinXP, donc des personnes "de pays riches" aussi (beaucoup aiment leur petit XP et gardent le navigateur par défaut).
IE6 est mort, oui, plus personne n'en parle (et avec POODLE, flingue sur la tempe de la chose car pas de support TLS), mais IE8/WinXP ne supporte pas plus que 3DES et lui reste toujours présent (et WinXP de manière générale encore plus, ils pourraient tous passer sur FF/WinXP mais non ils ne le font pas voila)
Par exemple sur mon site, je te garantie que tu obtiendras du TLSv1.2 + ECDHE + AES (donc fiable), même si ton navigateur est blindé de RC4 ou 3DES.
comprend pas.
Si la navigateur ne supporte que TLSv1.2 + ECDHE + AES (donc fiable), la connexion serait aussi fiable, même si le serveur est blindé de RC4 ou 3DES (un downgrade ferait échouer le navigateur qui devra refuser la connexion downgradée).
donc ex-aequo : les deux sont fautifs.
Cf la démo juste au-dessus, si les serveurs faisaient le taff, non seulement sur leurs connexions ils mettraient leurs clients à l’abri, mais en plus ça permettrait aux clients de désactiver les suites pourries non utilisées et donc de protéger au passage les connexions des autres serveurs même mal configuré
Si les navigateurs faisaient leur taf (supporter les nouveaux formats assez vite) et/ou se mettaient à jour, ça ferait longtemps que les serveurs pourraient virer le non PFS et RC4 et 3DES et même SHA1 des serveurs.
Ca me semble donc aussi ex-aequo.
Dit autrement :
- Les serveurs proposent 3DES car des vieux navigateurs sont dans la nature
- Les navigateurs proposent 3DES car des vieux serveurs sont dans la nature
symétrique.
Euh… Ca doit faire 10 ans que mon site est disponible en https, rien de neuf.
"récemment", j'ai juste fait mumuse avec SSL EV et réordonné les suites de chiffrement (je pensais bêtement que ça améliorerai la sécurité même contre le MITM, bon ça ne fait que, mais c'est déjà pas mal, améliorer la sécurité contre les scans)
La sécu m’intéresse et j'ai donc mis du SSL tôt tout comme tout est en SSL quand je peux (IMAPS, SMTPS, HTTPS Everywhere, ssleuth, Calomel…), mais de toutes évidence j'ai encore à apprendre :).
s'il ne supporte que du TLs non faillible alors il perd en disponibilité (comme tu le soulignes) : ce n'est pas envisageable pour lui.
En effet, il y a une différence entre faire mumuse en prod' et perdre des gens (bon, pas foule en HTTPS, mais sur le principe…)
le TLS non faillible sera pour la partie admin (la, je connais mais "utilisateurs" et leur botterai les fesses si ils n'ont pas un navigateur correct)
Ça met à l’abri toute personne qui supporte TLSv1.2+ECDHE-RSA-AES (ie beaucoup de monde quand même), mais ça empêche toutes les autres d’accéder au site (mais encore trop de monde…)…
C'est en pratique pas gérable (Android 4.3, IE10… Bon OK, ça vient, mais quand même…), juste parce qu'on n'a pas prévu de MITM pour les suites de chiffrement…
Merci pour l'éducation.
PS : par contre, pourquoi bloquer TLS1.0? vu que si j'ai bien compris, il y a la une parade contre le downgrade.
Au motif qu’on ne peut décemment pas mettre à la porte les utilisateurs de Windows XP ou IE 8…
On ne peut pas, non, trop de monde encore. Et c'est partie de l'histoire.
Je reste bloqué sur l'idée qu'on n'a pas prévenu dans une connexion sécurisé une altération de la première trame (je sais pas, je suis peut-être complètement à côté de la plaque, mais j'imagine une première réponse avec un hash de la première trame dans une extension "reserved" du protocole ancien, du coup les vieux trucs ne sont pas dérangés et les nouveaux testent le hash, du coup vieux et nouveau sont ensemble), ça m'en bouche un coin (et j'en apprend tous les jours, je vais hésiter sur 3DES… Bon pour le moment c'est toujours pas "cassé", donc gardons, mais pour combien de temps… Surtout que SHA1 semble bien compromis aussi vu comment certains régissent pour le virer si ils peuvent)
Est-ce que je résume bien en disant que PFS c'est cool mais tant que le serveur accepte du non ECDHE (pour par exemple supporter OpenSSL 0.9.8y qui date de… 2014; Ou Java 6, ou Android 2.3, pour ne pas parler d'IE8/WinXP), PFS ne sert à rien si le client ne vérifie pas qu'il est en PFS car le MITM peut forcer à virer le PFS (et SHA1) et les navigateurs ne préviennent pas?
Les suites de chiffrement supportées et celle choisie ne sont signées ni du client ni du serveur et peuvent donc être modifiées.
A relire la chose après manger, je suis presque convaincu de la faisabilité.
Mais je reste surpris qu'après plus de 20 ans (ou plus) de SSL, personne n'ai imaginé ce genre de scénario, qui fait que le plus petit dénominateur commun peut être utilisé.
Aucun mécanisme de sécurité qui par exemple dit en sécurisé quelle a été la demande (un "écho") ou autre (par le serveur ou le navigateur)? On dépend donc toujours du plus petit dénominateur du serveur gardé pour vieille compatibilité?
Je serai vraiment curieux d'avoir un tel proof of concept en vrai, tellement c'est gros.
(parce que tout le monde n'a pas ssleuth ou calomel pour voir quel suite de chiffrement a été pris et réagir en sachant le niveau de sécurité…)
Edit : la réponse est arrivée pendant que j'écrivais, merci. Me voila moins rassuré par rapport au niveau de la sécurité, c'est malin. Parce que du coup ça veut dire qu'on ne peut pas adapter la sécurité suivant l'âge des clients, le plus vieux supporté commande les autres, snif, on ne dirait pas qu'on a plus de 20 ans de sécurité en expérience.
La ligne TLS_FALLBACK_SCSV était de trop.
Ca ne change pas le reste de la demande (je n'ai pas eu de lecture sur un downgrade des suites de chiffrement, bon il y a ton lien mais j'aimerai plus : est-ce qu'il y a une proof of concept qui montre un downgrade de suite de chiffrement, je sais que je peux voir la suite choisie par le navigateur, donc je peux installer un MITM et voir quelle suite est alors choisie, donc si c'est possible si facilement que je comprend dans le lien j'imagine que ce genre de démo est disponible; bref je note le lien mais demande un peu plus de démo car je comprend l'explication comme la possibilité pour n'importe qui de passer en RSA sans PFS et SHA1 super facilement pour n'importe site vu qu'on veut encore garder ça pour les "vieux")
alors un attaquant peut forcer TOUS tes utilisateurs à utiliser 3DES au lieu de AES.
Reference needed (avec une démo de préférence).
Ce que j'ai compris est que les downgrades ne sont pas possible avec TLS (un avantage par rapport à SSLv3?), du coup j'ai énormément de mal à croire ce commentaire sur parole.
(autant pour 3DES que pour SHA1)
SSLLabs file un A+ pour des serveurs proposant 3DES malgré le fait que 3DES est 112 bits et que A+ est donné pour du 128 bits ou plus (si j'ai bien suivi).
Et SSLLabs dit "This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks."
(et à la portée de quiconque a un peu d’argent à dépenser sur Amazon EC2)
Donc la sécurité reste mieux que rien.
donc ça ne me choque pas. Comme tu dis, il faut peser. Et pas dire bourrinement "SHA1 ça craint donc c'est horrible que Facebook continue à l'accepter".
EXPORT est une autre histoire, je ne dis pas qu'il faut rien faire, mais peut-être qu'un avertissement (cadenas rouge) est suffisant plutôt que désactiver, si encore un peu d’utilisateurs (sinon désactivé, oui).
Juste que quand je lis que c'est "contre la sécu" de garder TLS1.0/SHA1, hum hum… Encore 5% de gens comme ça, ce n'est pas 0.0005%.
Il est à peu près certains que la plupart des administrateurs de sites web ne savaient même pas que leur logiciel serveur offrait par défaut des suites EXPORT (full disclosure : je ne le savais pas non plus).
Bouh pas bien.
Mais oui, pas bien que la config par défaut soit encore avec EXPORT, je n'ai pas dit le contraire, ça devrait être "si l'admin sait qu'il en a besoin" depuis un certain temps.
voire même une profonde remise en question de l'intérêt même des CA.
Est-ce vraiment la raison?
encore une fois, vaut mieux avoir des contre-arguments costaux, le coup de "ha ça fait chier les CA donc ils bloquent", ça va convaincre les conspirationnistes mais à part ça…
Toi même tu reconnais dans un autre journal, la connerie des CA :
Remplacer du "marche pas bien" par du "encore pire" n'est pas la conclusion du journal.
Ne devrions-nous pas lancer une pétition afin que Mozilla et Chrome le supporte ?
Est-ce que DANE protège de paypa1.com ? (bien regarder le nom)
Si non, problème de fishing, donc inutile.
J'ai cru comprendre que c'est pour ce genre de raison que DANE n'a été que peu valorisé par les navigateur (qu'en gros, on veut que quelqu'un vérifie contre le fishing, même si c'est qu'un peu, que de faire confiance aux sites seuls).
donc avant de faire une pétition, peut-être regarder pourquoi Mozilla et Google ont jugé la chose "pas intéressante" et préparer un contre-argumentaire. Tu es prêt à le faire?
Ça ouvre la porte à de possibles downgrade attacks, où un client et un serveur qui supporte tous deux une technologie moderne et résistante basculent sans raison sur une techno plus ancienne et potentiellement craquable.
risque contre support large.
Quand SSLv3 a été jugé trop troué, il a été désactivé à ce moment-la (et pas avant).
Quel risque réel de downgrade avec TLS 1.0?
C’est typiquement le cas de toutes les suites EXPORT par exemple.
ça c'est une autre histoire, mais pareil pourquoi désactiver alors que c'est peut-être le seul moyen et qu'il vaut mieux un peu de sécu que pas du tout? Note : je ne sais pas comment sont affichés ces sites (il en existe encore?), pas avec un cadenas barré?
Je pense que c’est surtout à ça que ton interlocuteur faisait référence.
Peut-être.
Mais dans le lien donné par un autre, il y a une accusation de "ils ne bougent pas, ils vont contre la sécurité" pour des sites qui sont en A+ chez SSLLabs. Alors désolé, mais la c'est un peu gros et presque mensonger de dire que ces sites ne s'occupent pas de la sécurité juste parce qu'on n'est pas d'accord avec leurs choix.
Je pensais donc à ce genre de critique. Il faudrait donc préciser quelle niveau de suppression est souhaité.
et oui, je continue d'avoir du 3DES
À raison. Il n’y a aucune attaque praticable connue contre 3DES.
Alors je vais dire que je continue d'avoir du SHA1 dans les suites de chiffrement, et SHA1 c'est troué :).
C'est déprimant que des navigateurs modernes conservent encore par défaut des techniques obsolètes voire dangereuses juste parce que certains serveurs ne se mettent pas à jour.
tu ne réponds toujours pas à la question.
Donc essayons de tourner la question autrement : en quoi conserver de vieilles techniques pour les vieux bousin impacte les gens à jour?
Tant que tu répondras pas à cette question, tu ne pourras pas convaincre que tes idées sont bonnes, car tu proposes des inconvénients (virer les gens pas à jour, comme ça) sans aucun avantage (pas plus de sécurité pour les gens à jour).
Voilà, c'est ma vision des choses.
Tu n'as pas répondu à la question, donc tu n'as pas donné ta vision.
On voit pas la faute du même côté.
Je ne vois pas la faute, surtout. Explique!
Si quelqu'un a une page qui récapitule les suites supportées par navigateur et version, ça m'intéresse de voir et éventuellement de revoir mon opinion.
SSLLabs de mon serveur
Tu verras ceux qui ne supportent pas ECDHE par exemple, ceux qui ont besoin de SHA1 etc.
(et oui, je continue d'avoir du 3DES, parce que je ne vois pas en quoi virer les utilisateurs WinXP qui ne veulent pas changer va changer quoi que ce soit à la sécurité de ceux étant à jour, à ma connaissance il n'est pas possible de forcer les "à jour" à basculer sur 3DES vu que SSLv3 est désactivé, cette désactivation étant elle nécessaire pour que le support des "vieux" n'impacte pas les "nouveaux").
Bref, tu ne donnes pas ta vision, tu ne réponds pas à la question, tu veux "bloquer les vieux" sans expliquer en quoi ça améliore globalement la sécurité.
L'ANSSI fait des recommandations dans des cas d'usage bien précis.
La recommandation est 3072.
Faut m'expliquer en quoi 2048 est une recommandation, c'est écrit "minimum 2048 et on recommande 3072".
Oui, la c'est un problème de français en fait : minimum contre recommandé, je comprend que tu dis que minimum = recommandé, mais tu ne dis pas comment tu traduis "recommandé" du coup.
Si tu as des données que tu veux préserver jusqu'en 2030 (plein de données sont périssables et pourraient être dévoilées dans 15 ans sans préjudice aucun), tu peux utiliser des clefs de 2 048 bits. Si tu es du genre "ceinture et bretelles" et que tu as de l'argent à mettre dans ton CPU (oui, le SSL a un coût), c'est encore mieux de mettre du 3 072 bits, bien évidemment.
Je traduis par "ma recommandation est 3072, mais dans certains cas et si tu es un radin, OK 2048 est tolérable".
On a vraiment un problème de français, car tu traduis "recommandé" par "ceinture et bretelles" et j'avoue ne pas te suivre du tout dans ce français.
J'attends plus de démonstration sur la partie "traduction du français", je ne suis pas convaincu : perso, je prend le mot "recommandation" comme une recommandation.
Essaie de faire les deux (2 048 et 4 096 bits), tu remarqueras une vraie différence sur le nombre de connexions qu'encaisse ton apache (j'avais fait le test il y a quelques années, c'était non négligeable même si je ne me souviens plus des chiffres).
Exemple.
6x plus lent si c'est dédié au handshake.
M'en fout, mon VPS tourne à 2-3% du CPU (pas le choix, les VPS "pas cher" ne filent pas de CPU moins puissant pour moins cher, les offres moins chère n'ont pas assez de RAM ou SSD), et c'est sur le handshake le x6, le matos fait aussi d'autres choses.
Mon serveur est en 4096 et je ne vois pas de différence en pratique.
Le jour où j'aurai 1000x plus de monde, je me poserai peut-être la question, mais je regarderai aussi toute la chaine (les gens ne font pas que le handshake, ils font mouliner du PHP, du MySQL… Et donc si ça me rajoute 1% de machines en plus, faudra se poser la question radinerie contre recommandation. Je ne note quand même que les "gros" on pour le moment choisi 2048, reste à savoir si c'est de la radinerie ou si ça a vraiment un impact sur l'ensemble de leurs machines)
un tel changement de norme se prépare des années à l’avance, et même malgré ça personne ne veut bouger.
Pas compris le lien que tu mets pour "personne ne veut bouger".
Twitter, Facebook, CloudFlare sont tous en SHA256 si ton navigateur le supporte. Avec TLS donc impossible de "forcer" à passer en SHA1 (ou corrigez-moi si je me trompe).
Ton lien arrive à la même conclusion que toi, mais en disant que ça n'enlève en fait pas de sécurité pour ceux en SHA256 tout en supportant ceux ne pouvant pas faire de SHA256 (sécurité moindre, mais mieux que pas de sécurité surtout que SHA1 n'est pas cassable en 3 secondes, faut que la personne ayant un un vieux WinXP par exemple soit intéressante pour y mettre quelques moyens)
Donc au final, ils se bougent, juste qu'ils ne sont pas d'accord pour dire "va ta faire foutre" juste parce qu'il y a une faiblesse (et pas un énorme trou béant disponible pour les script kiddies non plus) avec un algo alors que les "à jour" peuvent choisir SHA256.
Alors avant de dire "personne ne veut bouger", explique-moi en quoi supporter SHA1 pour les vieux bousins enlève de la sécurité à ceux utilisant SHA256.
Du coup, tu es d'accord pour dire que le problème, c'est principalement l'adoption de suites PFS plus que la taille de la clé.
Et comme tu le dis toi-même, la majorité des sites supporte déjà PFS.
Corrigez si je me trompes, la taille de la clé est indépendante de PFS.
Pour gérer les vieux bousins, on doit continuer avec des suites de chiffrement non PFS.
Donc on doit mettre du 4096 pour eux.
Et sauf si j'ai loupé un épisode, on ne peut pas dire "si PFS, tiens du 2048, sinon tiens du 4096", du coup c'est 4096 pour tous (ou 3072 si on veut rester dans les recommandations précises).
il ne pourra tout de même casser la crypto qu'au bout d'un temps proche de l'expiration.
Je ne comprend pas cette phrase : on se fout de la date d'expiration, car on peut dumper et donc garder le contenu pendant 1000 ans si on veut.
Et tout le monde de fait pas du 90 jours.
Finalement, à moins que je ne vous comprenne pas bien, vous dit que 2048 ça va tout en donnant des arguments sur le fait que ça ne va pas tant que ça…
Vivement qu'on puisse passer à ECDSA (le temps que tout le monde le supporte si on veut reste le plus large possible, il y en a encore pour un moment…), mais on se battera sans doute sur 128 vs 256 vs 521 :-D
une clef RSA de 2048 bits par défaut convient très bien.
Et pourtant, le lien que tu pointes dit le contraire…
J’ai déjà dit récemment qu’une clef RSA de 4096 bits était « disproportionnée » pour un certificat valide deux ans,
A moi que tu t'adressais.
Et je n'ai pas donné la suite, mais la réponse de l'admin a été cinglante : le lien que tu pointes.
admet en réalité que cette taille de clef est toujours satisfaisante jusqu’en 2030 (p. 17, RègleFact-1).
"La taille minimale du module est de 2048 bits, pour une utilisation ne devant pas dépasser l’année 2030"
Désolé, ça fait pas très rassurant, ce minimale, ça sous-entends que c'est parce que bon, tu insistes avec ta connerie, on va écrire ça même si on aurait aimé mettre plus. Et on met une date en plus, pas lointaine (dans 15 ans, on se dit qu'on pourra casser la chose, donc si c'est dumpé… La durée de la clé ne dit rien sur la durée de l’intérêt des données)
D'ailleurs ensuite :
"Il est recommandé d’employer des modules d’au moins 3072 bits, même pour une utilisation ne devant pas dépasser 2030."
Voila, bam dans la gueule, en fait 2048 c'est pas terrible, on dit 3072, c'est recommandé. Et pour ceux qui aiment les puissances de 2, ça fait 4096, simple.
C'est un peu comme les RFC, entre MUST et SHOULD, SHOULD n'est qu'une recommandation n’empêche on espère que c'est pris en compte (pas écrit pour rien), ben la pareil, tu omets la recommandation, pourquoi?
Surtout que bon… C'est un paramètre pour l'humain, ce n'est pas comme si c'était dur à faire.
donc tu te contredis toi-même : ton "convient très bien" n'est pas compatible avec les recommandations de l'ANSSI, qui dit que ton "convient très bien" est le minimum et non pas le recommandé (et chez moi, minimum != satisfaisant, c'est plutôt "si tu insistes, fait-toi plaisir je tolérerai")
Je suis conscient que mon site ne vaut pas qu'on s'amuse à casser la clé en 2030, mais bon, c'est facile à mettre 4096, alors la question est plutôt : pourquoi pas? et ça, tu n'y as pas répondu. une petite étude sur le gain en vitesse qu'apporte le 2048 sur un site "banal"? Car finalement, la question est plutôt du côté "pourquoi pas" qu'ailleurs, et personne n'a répondu à cette question.
(à noter que les gens refusant AES-256 dans les navigateurs Chrome et FF même si le serveur n'accepte que ça, au contraire de Safari et IE qui eux l'acceptent même si AES-128 est dispo, donc des choix bien différents, ont avancé un problème de perfs, mais les gens aillant testé les perfs ont conclu que c'était quand même assez marginal donc pas un argument bien convainquant pour eux; comme quoi les arguments de perfs, ça ne convainc pas forcément tout le monde suivant la "perte" calculée)
Si tu n'as pas de haters, c'est que ton outil n'est pas utilisé, c'est tout. Aucun outil utilisé n'a que des adorateurs.
Si tu n'as pas compris ça, ça démontre juste que tu es très loin d'avoir eu un projet (informatique ou autre) à toi qui a eu le moindre succès sorti de quelques amis, bref que tu n'as pas de succès.
Mais bon, je sais, toi tu es tellement parfais que tu as des millions d’utilisateurs de tes projets sans aucun hater. Tu es trop génial. Ou alors le contraire.
Appelle ça "malaise" si tu veux faire l'autruche, pile dans le sujet du journal et de mon commentaire, à croire qu'il y a une volonté de donner des exemples pratiques.
(argh, j'avais tenté d'arrêter de répondre dans le vide, bon je me reprend et vais tenter d'ignorer de nouveau ce genre de connerie)
Il y a déjà eu plein de tentatives d'uniformiser l'installation d'applications sur les distros Linux (et zut, c'est tellement mort que j'en ai oublié les noms), toutes "tuées" (critiqué à mort, rien fait pour faciliter le support de la chose par défaut dans la distro etc) par des gens ne voulant pas faciliter la vie de développeurs et des utilisateurs mais garder son "moi, ma technique est la meilleure, le reste ça pue".
Donc pas gagné que celle-la soit plus acceptée (note les réactions ici, c'est beaucoup de volonté de rester comme maintenant), on va voir si ce n'est pas une fonction "désactivée" par les distros)… On a bien eu systemd partout malgré les hurlements de certains pas contents que ce soit uniformisé ("c'est pas bien comme il faut", "je peux plus faire x même si on me dit qu'en fait si" etc), qui sait ça remarchera peut-être encore une fois, à force de tenter…
Les paquets dans une distribution cela touche tous les composants du système
Je vois revenir cet argumetn d'autorité souvent, mais ne le comprend pas : en quoi est-ce une limitation d'Apple et quelque chose que les distros ne peuvent pas faire?
On en revient au même : des principes "techniques" pour les distros Linux et des excuses pour ne pas faire, là où Apple pense utilisateur (l'utilisateur se fout complet de pouvoir changer les composants système, c'est les apps utilisateur qui l'interessent).
Note que toute distribution que je connais autorise les dépôts tiers et facilite même leur conception
Pas le repo par défaut, donc ne compte pas.
différence entre disponibilité théorique pour les geeks et disponibilité pratique pour le peuple.
Chez Apple tu ne peux pas le faire du tout s'ils refusent. Et eux la censure ils connaissent aussi, sans parler des applications moralement dérangeantes pour eux, on peut trouver sans soucis des tas d'exemples d'applications rejetées de l'Apple store sans raisons valables, ou pour des détails insignifiants…
Qui est peanuts par rapport à ce que le libre interdit.
On en revient encore une fois à l'utilisateur, penser à lui, et avoir des limitations "qui arrange le fournisseur" pas trop dérangeantes (au contraire ce que fait la "communauté du libre" vis à vis de ses utilisateurs)
(pas que toi, mais une bonne partie des réactions au journal sont dans ce sens) Merci de démontrer complètement le problème qui fait que Slack existe, que Facebook existe, qu'Apple existe, le tout avec bien plus d'utilisateurs que ce que propose "la communauté libre", qui a une drôle de façon dont on voit l'utilisateur (il est un ennemi ou une personne à éduquer, au choix, jamais une personne qui est ce qu'elle est : une personne qui veut utiliser avec ses priorités à lui et non les nôtres, tout simplement).
Le problème est bien que "la communauté libre" ne pense pas à l'utilisateur.
Le problème est bien "chez nous".
dans tes exemples j'ai l'impression que tu parles plus de standards que de libre.
Je parle de communication entre les gens.
Le libre n'est qu'un détail ici (en fait, il a même rien à voir avec la réaction de la personne : faire le renfermé n'a rien à voir avec le libre, j'ai déjà cité des entités capables de faire du libre non renfermé sur lui-même : Mozilla, VideoLAN…).
Théorie vs pratique : si tu veux des standards de droit, il ne faut pas que les standards de fait soient suffisant pour 99% de la population.
Si les 1% de personnes dans leur tour d'ivoire restent dans leur coin, il n'y aura aucun levier pour apporter les standards de droit et les "autres" utiliseront les standards de fait.
tu penses théorie ("faisons des standards de droit et on arrivera à obliger les gens à les utiliser"), là où la pratique montre que tout le monde s'en fout (ben oui, ça marche) et utilisera les standards de fait si il y a 1% seulement de gens qui se la pètent à ne pas vouloir faire comme les autres.
Note : ça n'a rien à voir avec par exemple les aveugles ou les handicapés moteur, car eux n'ont pas le choix, donc il est légitime de "forcer" par la loi les gens à les prendre en compte. La, on parle de gens se mettant volontairement dans une position d'incompatibilité, donc la réponse est alors "arrête de faire chier et prend IE" car ils peuvent (ils ne veulent juste pas), et tu ne trouveras jamais une légitimité à prendre en compte ces "1% de chieurs" car ils sont chieurs et qu'être chieur ne fait pas partie des trucs "légitimes compréhensibles".
Finalement, je me demande pourquoi tu veux parler de libre dans ta phrase : que vient faire le libre dans la volonté de rester entre "gens bien"? Le libre est bien plus ouvert que ça…
Dans l'ensemble le libre me va bien tel qu'il est actuellement.
On est donc d'accord que si tu ne peux pas (par exemple) déclarer tes impôts car tu es sous Linux/FF et pas Win/IE, tu ne vas pas te plaindre et faire une déclaration papier tout en payant l'amende, ou trouver IE chez un pote pour ça?
Pas de réclamation de formulaire en OpenDocument un .doc ira?
Pas grave sur ton site préféré devient cassé avec ton navigateur (il ont pas pris la peine de tester avec ton navigateur, pas de pot et pas rentable de penser à toi), tu fera avec?
Il faut être cohérent avec ses idées, si on affirme qu'on veut reste "entre soit"… Et ne pas demander à ce que les autres s'adaptent à soit quand on n'a pas envie de s'adapter soit-même.
C'est là tout le cœur du problème : des gens veulent le beurre et l'argent du beurre, du coup ils demandent des trucs incohérents (genre être peu nombreux mais être pris en compte avec des dépenses pour "si peu de monde")
Juste une correstion car il semble que tu ne connais pas le Mac App Store :
de ce fait tu es obligé de faire le gendarme pour éviter de casser tout le système via un paquet qui n'a pas été validé en amont.
Les paquets Mac App Store sont testés par Apple.
(et pas qu'un peu, il y a du pré-test automatique avant d'uploader, puis un test direct par Apple)
Le problème, c'est que les distributions Linux ne font pas de distinction entre l'os "basique" et l'userland
Tu ne fais que confirmé qu'Apple prend l'idée et la rend utilisable.
Le problème est donc bien "Linux" (= la "communauté"), on ne peut que s'en prendre qu'à soit-même… Le sujet du journal, "l'opensource qui ne réussit pas à se défaire de ses démons" avec le même résultat (le bénéfice de la chose est pour l'autre, de sa propre faute à ne pas s'être intéressé à l'utilisateur).
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Je retiens de la discussion que la seule solution viable à long terme est d'empécher un downgrade.
tout le reste, c'est gérer ce manque et ca ne terminera jamais (le jour oú SHA256 a un petit problème, rebelote punition pour ceux pouvant évoluer vers SHA3).
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Virer 3DES? Ca vire le dernier IE sur WinXP, donc des personnes "de pays riches" aussi (beaucoup aiment leur petit XP et gardent le navigateur par défaut).
IE6 est mort, oui, plus personne n'en parle (et avec POODLE, flingue sur la tempe de la chose car pas de support TLS), mais IE8/WinXP ne supporte pas plus que 3DES et lui reste toujours présent (et WinXP de manière générale encore plus, ils pourraient tous passer sur FF/WinXP mais non ils ne le font pas voila)
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 4.
comprend pas.
Si la navigateur ne supporte que TLSv1.2 + ECDHE + AES (donc fiable), la connexion serait aussi fiable, même si le serveur est blindé de RC4 ou 3DES (un downgrade ferait échouer le navigateur qui devra refuser la connexion downgradée).
donc ex-aequo : les deux sont fautifs.
Si les navigateurs faisaient leur taf (supporter les nouveaux formats assez vite) et/ou se mettaient à jour, ça ferait longtemps que les serveurs pourraient virer le non PFS et RC4 et 3DES et même SHA1 des serveurs.
Ca me semble donc aussi ex-aequo.
Dit autrement :
- Les serveurs proposent 3DES car des vieux navigateurs sont dans la nature
- Les navigateurs proposent 3DES car des vieux serveurs sont dans la nature
symétrique.
Qu'est-ce que j'ai manqué?
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1. Dernière modification le 05 janvier 2016 à 21:22.
Euh… Ca doit faire 10 ans que mon site est disponible en https, rien de neuf.
"récemment", j'ai juste fait mumuse avec SSL EV et réordonné les suites de chiffrement (je pensais bêtement que ça améliorerai la sécurité même contre le MITM, bon ça ne fait que, mais c'est déjà pas mal, améliorer la sécurité contre les scans)
La sécu m’intéresse et j'ai donc mis du SSL tôt tout comme tout est en SSL quand je peux (IMAPS, SMTPS, HTTPS Everywhere, ssleuth, Calomel…), mais de toutes évidence j'ai encore à apprendre :).
En effet, il y a une différence entre faire mumuse en prod' et perdre des gens (bon, pas foule en HTTPS, mais sur le principe…)
le TLS non faillible sera pour la partie admin (la, je connais mais "utilisateurs" et leur botterai les fesses si ils n'ont pas un navigateur correct)
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1. Dernière modification le 05 janvier 2016 à 14:59.
C'est en pratique pas gérable (Android 4.3, IE10… Bon OK, ça vient, mais quand même…), juste parce qu'on n'a pas prévu de MITM pour les suites de chiffrement…
Merci pour l'éducation.
PS : par contre, pourquoi bloquer TLS1.0? vu que si j'ai bien compris, il y a la une parade contre le downgrade.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
On ne peut pas, non, trop de monde encore. Et c'est partie de l'histoire.
Je reste bloqué sur l'idée qu'on n'a pas prévenu dans une connexion sécurisé une altération de la première trame (je sais pas, je suis peut-être complètement à côté de la plaque, mais j'imagine une première réponse avec un hash de la première trame dans une extension "reserved" du protocole ancien, du coup les vieux trucs ne sont pas dérangés et les nouveaux testent le hash, du coup vieux et nouveau sont ensemble), ça m'en bouche un coin (et j'en apprend tous les jours, je vais hésiter sur 3DES… Bon pour le moment c'est toujours pas "cassé", donc gardons, mais pour combien de temps… Surtout que SHA1 semble bien compromis aussi vu comment certains régissent pour le virer si ils peuvent)
Est-ce que je résume bien en disant que PFS c'est cool mais tant que le serveur accepte du non ECDHE (pour par exemple supporter OpenSSL 0.9.8y qui date de… 2014; Ou Java 6, ou Android 2.3, pour ne pas parler d'IE8/WinXP), PFS ne sert à rien si le client ne vérifie pas qu'il est en PFS car le MITM peut forcer à virer le PFS (et SHA1) et les navigateurs ne préviennent pas?
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0. Dernière modification le 05 janvier 2016 à 14:13.
A relire la chose après manger, je suis presque convaincu de la faisabilité.
Mais je reste surpris qu'après plus de 20 ans (ou plus) de SSL, personne n'ai imaginé ce genre de scénario, qui fait que le plus petit dénominateur commun peut être utilisé.
Aucun mécanisme de sécurité qui par exemple dit en sécurisé quelle a été la demande (un "écho") ou autre (par le serveur ou le navigateur)? On dépend donc toujours du plus petit dénominateur du serveur gardé pour vieille compatibilité?
Je serai vraiment curieux d'avoir un tel proof of concept en vrai, tellement c'est gros.
(parce que tout le monde n'a pas ssleuth ou calomel pour voir quel suite de chiffrement a été pris et réagir en sachant le niveau de sécurité…)
Edit : la réponse est arrivée pendant que j'écrivais, merci. Me voila moins rassuré par rapport au niveau de la sécurité, c'est malin. Parce que du coup ça veut dire qu'on ne peut pas adapter la sécurité suivant l'âge des clients, le plus vieux supporté commande les autres, snif, on ne dirait pas qu'on a plus de 20 ans de sécurité en expérience.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1. Dernière modification le 05 janvier 2016 à 12:04.
La ligne TLS_FALLBACK_SCSV était de trop.
Ca ne change pas le reste de la demande (je n'ai pas eu de lecture sur un downgrade des suites de chiffrement, bon il y a ton lien mais j'aimerai plus : est-ce qu'il y a une proof of concept qui montre un downgrade de suite de chiffrement, je sais que je peux voir la suite choisie par le navigateur, donc je peux installer un MITM et voir quelle suite est alors choisie, donc si c'est possible si facilement que je comprend dans le lien j'imagine que ce genre de démo est disponible; bref je note le lien mais demande un peu plus de démo car je comprend l'explication comme la possibilité pour n'importe qui de passer en RSA sans PFS et SHA1 super facilement pour n'importe site vu qu'on veut encore garder ça pour les "vieux")
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1. Dernière modification le 05 janvier 2016 à 11:48.
Reference needed (avec une démo de préférence).
Ce que j'ai compris est que les downgrades ne sont pas possible avec TLS (un avantage par rapport à SSLv3?), du coup j'ai énormément de mal à croire ce commentaire sur parole.
(autant pour 3DES que pour SHA1)
SSLLabs file un A+ pour des serveurs proposant 3DES malgré le fait que 3DES est 112 bits et que A+ est donné pour du 128 bits ou plus (si j'ai bien suivi).
Et SSLLabs dit "This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks."
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0.
Donc la sécurité reste mieux que rien.
donc ça ne me choque pas. Comme tu dis, il faut peser. Et pas dire bourrinement "SHA1 ça craint donc c'est horrible que Facebook continue à l'accepter".
EXPORT est une autre histoire, je ne dis pas qu'il faut rien faire, mais peut-être qu'un avertissement (cadenas rouge) est suffisant plutôt que désactiver, si encore un peu d’utilisateurs (sinon désactivé, oui).
Juste que quand je lis que c'est "contre la sécu" de garder TLS1.0/SHA1, hum hum… Encore 5% de gens comme ça, ce n'est pas 0.0005%.
Bouh pas bien.
Mais oui, pas bien que la config par défaut soit encore avec EXPORT, je n'ai pas dit le contraire, ça devrait être "si l'admin sait qu'il en a besoin" depuis un certain temps.
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
J'ai lu, je ne sais plus où.
Edit : ha si, lien dans le journal.
https://www.imperialviolet.org/2011/06/16/dnssecchrome.html
Faut lire les liens ;-).
Est-ce vraiment la raison?
encore une fois, vaut mieux avoir des contre-arguments costaux, le coup de "ha ça fait chier les CA donc ils bloquent", ça va convaincre les conspirationnistes mais à part ça…
Remplacer du "marche pas bien" par du "encore pire" n'est pas la conclusion du journal.
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à -3.
Est-ce que DANE protège de paypa1.com ? (bien regarder le nom)
Si non, problème de fishing, donc inutile.
J'ai cru comprendre que c'est pour ce genre de raison que DANE n'a été que peu valorisé par les navigateur (qu'en gros, on veut que quelqu'un vérifie contre le fishing, même si c'est qu'un peu, que de faire confiance aux sites seuls).
donc avant de faire une pétition, peut-être regarder pourquoi Mozilla et Google ont jugé la chose "pas intéressante" et préparer un contre-argumentaire. Tu es prêt à le faire?
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0.
Reference needed.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
risque contre support large.
Quand SSLv3 a été jugé trop troué, il a été désactivé à ce moment-la (et pas avant).
Quel risque réel de downgrade avec TLS 1.0?
ça c'est une autre histoire, mais pareil pourquoi désactiver alors que c'est peut-être le seul moyen et qu'il vaut mieux un peu de sécu que pas du tout? Note : je ne sais pas comment sont affichés ces sites (il en existe encore?), pas avec un cadenas barré?
Peut-être.
Mais dans le lien donné par un autre, il y a une accusation de "ils ne bougent pas, ils vont contre la sécurité" pour des sites qui sont en A+ chez SSLLabs. Alors désolé, mais la c'est un peu gros et presque mensonger de dire que ces sites ne s'occupent pas de la sécurité juste parce qu'on n'est pas d'accord avec leurs choix.
Je pensais donc à ce genre de critique. Il faudrait donc préciser quelle niveau de suppression est souhaité.
Alors je vais dire que je continue d'avoir du SHA1 dans les suites de chiffrement, et SHA1 c'est troué :).
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
tu ne réponds toujours pas à la question.
Donc essayons de tourner la question autrement : en quoi conserver de vieilles techniques pour les vieux bousin impacte les gens à jour?
Tant que tu répondras pas à cette question, tu ne pourras pas convaincre que tes idées sont bonnes, car tu proposes des inconvénients (virer les gens pas à jour, comme ça) sans aucun avantage (pas plus de sécurité pour les gens à jour).
Tu n'as pas répondu à la question, donc tu n'as pas donné ta vision.
Je ne vois pas la faute, surtout. Explique!
SSLLabs de mon serveur
Tu verras ceux qui ne supportent pas ECDHE par exemple, ceux qui ont besoin de SHA1 etc.
(et oui, je continue d'avoir du 3DES, parce que je ne vois pas en quoi virer les utilisateurs WinXP qui ne veulent pas changer va changer quoi que ce soit à la sécurité de ceux étant à jour, à ma connaissance il n'est pas possible de forcer les "à jour" à basculer sur 3DES vu que SSLv3 est désactivé, cette désactivation étant elle nécessaire pour que le support des "vieux" n'impacte pas les "nouveaux").
Bref, tu ne donnes pas ta vision, tu ne réponds pas à la question, tu veux "bloquer les vieux" sans expliquer en quoi ça améliore globalement la sécurité.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à -1.
La recommandation est 3072.
Faut m'expliquer en quoi 2048 est une recommandation, c'est écrit "minimum 2048 et on recommande 3072".
Oui, la c'est un problème de français en fait : minimum contre recommandé, je comprend que tu dis que minimum = recommandé, mais tu ne dis pas comment tu traduis "recommandé" du coup.
Je traduis par "ma recommandation est 3072, mais dans certains cas et si tu es un radin, OK 2048 est tolérable".
On a vraiment un problème de français, car tu traduis "recommandé" par "ceinture et bretelles" et j'avoue ne pas te suivre du tout dans ce français.
J'attends plus de démonstration sur la partie "traduction du français", je ne suis pas convaincu : perso, je prend le mot "recommandation" comme une recommandation.
Exemple.
6x plus lent si c'est dédié au handshake.
M'en fout, mon VPS tourne à 2-3% du CPU (pas le choix, les VPS "pas cher" ne filent pas de CPU moins puissant pour moins cher, les offres moins chère n'ont pas assez de RAM ou SSD), et c'est sur le handshake le x6, le matos fait aussi d'autres choses.
Mon serveur est en 4096 et je ne vois pas de différence en pratique.
Le jour où j'aurai 1000x plus de monde, je me poserai peut-être la question, mais je regarderai aussi toute la chaine (les gens ne font pas que le handshake, ils font mouliner du PHP, du MySQL… Et donc si ça me rajoute 1% de machines en plus, faudra se poser la question radinerie contre recommandation. Je ne note quand même que les "gros" on pour le moment choisi 2048, reste à savoir si c'est de la radinerie ou si ça a vraiment un impact sur l'ensemble de leurs machines)
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Pas compris le lien que tu mets pour "personne ne veut bouger".
Twitter, Facebook, CloudFlare sont tous en SHA256 si ton navigateur le supporte. Avec TLS donc impossible de "forcer" à passer en SHA1 (ou corrigez-moi si je me trompe).
Ton lien arrive à la même conclusion que toi, mais en disant que ça n'enlève en fait pas de sécurité pour ceux en SHA256 tout en supportant ceux ne pouvant pas faire de SHA256 (sécurité moindre, mais mieux que pas de sécurité surtout que SHA1 n'est pas cassable en 3 secondes, faut que la personne ayant un un vieux WinXP par exemple soit intéressante pour y mettre quelques moyens)
Donc au final, ils se bougent, juste qu'ils ne sont pas d'accord pour dire "va ta faire foutre" juste parce qu'il y a une faiblesse (et pas un énorme trou béant disponible pour les script kiddies non plus) avec un algo alors que les "à jour" peuvent choisir SHA256.
Alors avant de dire "personne ne veut bouger", explique-moi en quoi supporter SHA1 pour les vieux bousins enlève de la sécurité à ceux utilisant SHA256.
Note : de la même façon, Microsoft dit "pour les OS supportant SHA256, on refusera les signatures que SHA1" et en même temps "Signez SHA1 et SHA256 comme ça les vieux bousins continueront à fonctionner tout en donnant plus de sécu aux nouveaux OS" et je ne vois pas en quoi "interdire" SHA1 apporterai plus de sécurité aux nouveaux OS (et pour les anciens, ben c'est ancien, et ils vivent avec moins de sécurité, voila tout, de toutes façon ces personnes avec de vieux bousins ne sont pas les plus intéressantes, vous imaginez vraiment Snowden avec un WinXP…)
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3. Dernière modification le 05 janvier 2016 à 08:20.
Corrigez si je me trompes, la taille de la clé est indépendante de PFS.
Pour gérer les vieux bousins, on doit continuer avec des suites de chiffrement non PFS.
Donc on doit mettre du 4096 pour eux.
Et sauf si j'ai loupé un épisode, on ne peut pas dire "si PFS, tiens du 2048, sinon tiens du 4096", du coup c'est 4096 pour tous (ou 3072 si on veut rester dans les recommandations précises).
Je ne comprend pas cette phrase : on se fout de la date d'expiration, car on peut dumper et donc garder le contenu pendant 1000 ans si on veut.
Et tout le monde de fait pas du 90 jours.
Finalement, à moins que je ne vous comprenne pas bien, vous dit que 2048 ça va tout en donnant des arguments sur le fait que ça ne va pas tant que ça…
Vivement qu'on puisse passer à ECDSA (le temps que tout le monde le supporte si on veut reste le plus large possible, il y en a encore pour un moment…), mais on se battera sans doute sur 128 vs 256 vs 521 :-D
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Et pourtant, le lien que tu pointes dit le contraire…
A moi que tu t'adressais.
Et je n'ai pas donné la suite, mais la réponse de l'admin a été cinglante : le lien que tu pointes.
"La taille minimale du module est de 2048 bits, pour une utilisation ne devant pas dépasser l’année 2030"
Désolé, ça fait pas très rassurant, ce minimale, ça sous-entends que c'est parce que bon, tu insistes avec ta connerie, on va écrire ça même si on aurait aimé mettre plus. Et on met une date en plus, pas lointaine (dans 15 ans, on se dit qu'on pourra casser la chose, donc si c'est dumpé… La durée de la clé ne dit rien sur la durée de l’intérêt des données)
D'ailleurs ensuite :
"Il est recommandé d’employer des modules d’au moins 3072 bits, même pour une utilisation ne devant pas dépasser 2030."
Voila, bam dans la gueule, en fait 2048 c'est pas terrible, on dit 3072, c'est recommandé. Et pour ceux qui aiment les puissances de 2, ça fait 4096, simple.
C'est un peu comme les RFC, entre MUST et SHOULD, SHOULD n'est qu'une recommandation n’empêche on espère que c'est pris en compte (pas écrit pour rien), ben la pareil, tu omets la recommandation, pourquoi?
Surtout que bon… C'est un paramètre pour l'humain, ce n'est pas comme si c'était dur à faire.
donc tu te contredis toi-même : ton "convient très bien" n'est pas compatible avec les recommandations de l'ANSSI, qui dit que ton "convient très bien" est le minimum et non pas le recommandé (et chez moi, minimum != satisfaisant, c'est plutôt "si tu insistes, fait-toi plaisir je tolérerai")
Je suis conscient que mon site ne vaut pas qu'on s'amuse à casser la clé en 2030, mais bon, c'est facile à mettre 4096, alors la question est plutôt : pourquoi pas? et ça, tu n'y as pas répondu. une petite étude sur le gain en vitesse qu'apporte le 2048 sur un site "banal"? Car finalement, la question est plutôt du côté "pourquoi pas" qu'ailleurs, et personne n'a répondu à cette question.
(à noter que les gens refusant AES-256 dans les navigateurs Chrome et FF même si le serveur n'accepte que ça, au contraire de Safari et IE qui eux l'acceptent même si AES-128 est dispo, donc des choix bien différents, ont avancé un problème de perfs, mais les gens aillant testé les perfs ont conclu que c'était quand même assez marginal donc pas un argument bien convainquant pour eux; comme quoi les arguments de perfs, ça ne convainc pas forcément tout le monde suivant la "perte" calculée)
[^] # Re: Pas besoin d'être une startup
Posté par Zenitram (site web personnel) . En réponse au journal Slack remplace l'IRC, ou comment l'opensource qui ne réussit pas à se défaire de ses démons. Évalué à -7.
Si tu n'as pas de haters, c'est que ton outil n'est pas utilisé, c'est tout. Aucun outil utilisé n'a que des adorateurs.
Si tu n'as pas compris ça, ça démontre juste que tu es très loin d'avoir eu un projet (informatique ou autre) à toi qui a eu le moindre succès sorti de quelques amis, bref que tu n'as pas de succès.
Mais bon, je sais, toi tu es tellement parfais que tu as des millions d’utilisateurs de tes projets sans aucun hater. Tu es trop génial. Ou alors le contraire.
Appelle ça "malaise" si tu veux faire l'autruche, pile dans le sujet du journal et de mon commentaire, à croire qu'il y a une volonté de donner des exemples pratiques.
(argh, j'avais tenté d'arrêter de répondre dans le vide, bon je me reprend et vais tenter d'ignorer de nouveau ce genre de connerie)
[^] # Re: XDG-App
Posté par Zenitram (site web personnel) . En réponse au journal Slack remplace l'IRC, ou comment l'opensource qui ne réussit pas à se défaire de ses démons. Évalué à -2.
Il y a déjà eu plein de tentatives d'uniformiser l'installation d'applications sur les distros Linux (et zut, c'est tellement mort que j'en ai oublié les noms), toutes "tuées" (critiqué à mort, rien fait pour faciliter le support de la chose par défaut dans la distro etc) par des gens ne voulant pas faciliter la vie de développeurs et des utilisateurs mais garder son "moi, ma technique est la meilleure, le reste ça pue".
Donc pas gagné que celle-la soit plus acceptée (note les réactions ici, c'est beaucoup de volonté de rester comme maintenant), on va voir si ce n'est pas une fonction "désactivée" par les distros)… On a bien eu systemd partout malgré les hurlements de certains pas contents que ce soit uniformisé ("c'est pas bien comme il faut", "je peux plus faire x même si on me dit qu'en fait si" etc), qui sait ça remarchera peut-être encore une fois, à force de tenter…
[^] # Re: Pas besoin d'être une startup
Posté par Zenitram (site web personnel) . En réponse au journal Slack remplace l'IRC, ou comment l'opensource qui ne réussit pas à se défaire de ses démons. Évalué à -8.
Je vois revenir cet argumetn d'autorité souvent, mais ne le comprend pas : en quoi est-ce une limitation d'Apple et quelque chose que les distros ne peuvent pas faire?
On en revient au même : des principes "techniques" pour les distros Linux et des excuses pour ne pas faire, là où Apple pense utilisateur (l'utilisateur se fout complet de pouvoir changer les composants système, c'est les apps utilisateur qui l'interessent).
Pas le repo par défaut, donc ne compte pas.
différence entre disponibilité théorique pour les geeks et disponibilité pratique pour le peuple.
Qui est peanuts par rapport à ce que le libre interdit.
On en revient encore une fois à l'utilisateur, penser à lui, et avoir des limitations "qui arrange le fournisseur" pas trop dérangeantes (au contraire ce que fait la "communauté du libre" vis à vis de ses utilisateurs)
(pas que toi, mais une bonne partie des réactions au journal sont dans ce sens) Merci de démontrer complètement le problème qui fait que Slack existe, que Facebook existe, qu'Apple existe, le tout avec bien plus d'utilisateurs que ce que propose "la communauté libre", qui a une drôle de façon dont on voit l'utilisateur (il est un ennemi ou une personne à éduquer, au choix, jamais une personne qui est ce qu'elle est : une personne qui veut utiliser avec ses priorités à lui et non les nôtres, tout simplement).
Le problème est bien que "la communauté libre" ne pense pas à l'utilisateur.
Le problème est bien "chez nous".
[^] # Re: La fameuse cible du libre
Posté par Zenitram (site web personnel) . En réponse au journal Slack remplace l'IRC, ou comment l'opensource qui ne réussit pas à se défaire de ses démons. Évalué à -2.
Je parle de communication entre les gens.
Le libre n'est qu'un détail ici (en fait, il a même rien à voir avec la réaction de la personne : faire le renfermé n'a rien à voir avec le libre, j'ai déjà cité des entités capables de faire du libre non renfermé sur lui-même : Mozilla, VideoLAN…).
Théorie vs pratique : si tu veux des standards de droit, il ne faut pas que les standards de fait soient suffisant pour 99% de la population.
Si les 1% de personnes dans leur tour d'ivoire restent dans leur coin, il n'y aura aucun levier pour apporter les standards de droit et les "autres" utiliseront les standards de fait.
tu penses théorie ("faisons des standards de droit et on arrivera à obliger les gens à les utiliser"), là où la pratique montre que tout le monde s'en fout (ben oui, ça marche) et utilisera les standards de fait si il y a 1% seulement de gens qui se la pètent à ne pas vouloir faire comme les autres.
Note : ça n'a rien à voir avec par exemple les aveugles ou les handicapés moteur, car eux n'ont pas le choix, donc il est légitime de "forcer" par la loi les gens à les prendre en compte. La, on parle de gens se mettant volontairement dans une position d'incompatibilité, donc la réponse est alors "arrête de faire chier et prend IE" car ils peuvent (ils ne veulent juste pas), et tu ne trouveras jamais une légitimité à prendre en compte ces "1% de chieurs" car ils sont chieurs et qu'être chieur ne fait pas partie des trucs "légitimes compréhensibles".
Finalement, je me demande pourquoi tu veux parler de libre dans ta phrase : que vient faire le libre dans la volonté de rester entre "gens bien"? Le libre est bien plus ouvert que ça…
[^] # Re: La fameuse cible du libre
Posté par Zenitram (site web personnel) . En réponse au journal Slack remplace l'IRC, ou comment l'opensource qui ne réussit pas à se défaire de ses démons. Évalué à -6. Dernière modification le 30 décembre 2015 à 16:17.
On est donc d'accord que si tu ne peux pas (par exemple) déclarer tes impôts car tu es sous Linux/FF et pas Win/IE, tu ne vas pas te plaindre et faire une déclaration papier tout en payant l'amende, ou trouver IE chez un pote pour ça?
Pas de réclamation de formulaire en OpenDocument un .doc ira?
Pas grave sur ton site préféré devient cassé avec ton navigateur (il ont pas pris la peine de tester avec ton navigateur, pas de pot et pas rentable de penser à toi), tu fera avec?
Il faut être cohérent avec ses idées, si on affirme qu'on veut reste "entre soit"… Et ne pas demander à ce que les autres s'adaptent à soit quand on n'a pas envie de s'adapter soit-même.
C'est là tout le cœur du problème : des gens veulent le beurre et l'argent du beurre, du coup ils demandent des trucs incohérents (genre être peu nombreux mais être pris en compte avec des dépenses pour "si peu de monde")
[^] # Re: Pas besoin d'être une startup
Posté par Zenitram (site web personnel) . En réponse au journal Slack remplace l'IRC, ou comment l'opensource qui ne réussit pas à se défaire de ses démons. Évalué à -1. Dernière modification le 30 décembre 2015 à 16:09.
Juste une correstion car il semble que tu ne connais pas le Mac App Store :
Les paquets Mac App Store sont testés par Apple.
(et pas qu'un peu, il y a du pré-test automatique avant d'uploader, puis un test direct par Apple)
Tu ne fais que confirmé qu'Apple prend l'idée et la rend utilisable.
Le problème est donc bien "Linux" (= la "communauté"), on ne peut que s'en prendre qu'à soit-même… Le sujet du journal, "l'opensource qui ne réussit pas à se défaire de ses démons" avec le même résultat (le bénéfice de la chose est pour l'autre, de sa propre faute à ne pas s'être intéressé à l'utilisateur).