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).
Avoir des "haters" est le signe du succès, ça veut dire que tu tapes précisément où il fallait le faire, et que ça a du succès :
- les utilisateurs de Mac détestent? Ce n'est pas obligatoire (ou pas gênant : les updates système, ou alors on doit détester aussi "yum update"), donc c'est surtout une posture. A moins que les développeurs utilisent que ce canal mais du coup c'est sans doute pour une bonne raison que les développeurs le font?
- les développeurs de Mac détestent? Ce n'est pas obligatoire ils peuvent s'en passer et vendre en direct. A moins que les utilisateurs utilisent que ce canal mais du coup c'est sans doute pour une bonne raison que les utilisateurs le font, et que les 30% prélevés dont certes râler mais les 70% restant c'est quand même bon?
Bref, si certains détestent, c'est que beaucoup plus adorent.
Et c'est le prix à payer pour un truc qui marche.
(on peut parler des gens qui détestent Google, Amazon, Facebook… toujours parce qu'en fait, ça marche à cause de l'expérience utilisateur)
Résumons : tu ne fais que confirmer que l'AppStore est une chose réussie là où les autres ont échoué.
quelqu'un peut m'expliquer en quelques lignes ce qu'est Slack et pourquoi c'est à la mode ?
Une ligne suffit : Slack, c'est IRC utilisable par tout le monde (voir aussi les fonctionnalités décrites par Wikipedia), car l'entreprise derrière pense en priorité à l'expérience utilisateur.
Et si pour devenir lancer une startup, il suffisait de prendre une bonne idée de la "communauté" et la packager proprement (parce que les libristes sont incapables de penser "user experience") ?
Pas besoin d'être une startup, je pense par exemple au système de repository Linux : à la base c'est super, en pratique c'est un repoussoir à développeur.
Apple a pris l'idée, a viré les limitations des "développeurs qui pensent à leurs délires sans réfléchir plus loin" (par exemple : permettre à quiconque de proposer un logiciel du moment où il respecte les règles sans se faire jeter parce qu'on n'aurait pas trouvé un mentor ni devoir passer 1 an entre la demande et l’acceptation, ne pas rejeter par principe le non libre "caca ça pue on n'en veut pas"…) et en a fait un super business (30% du prix de vente quand même…).
C'est que maintenant que par exemple Ubuntu pense à faire un Store plus tolérant, mais en attendant ce n'est plus l'écosystème Linux qui a le plus d'application facilement accessibles, c'est Mac. La grosse honte (pas comme si Apple s'était jeté dessus tout de suite, les libristes ont eu des années pour offrir une chose utilisable).
La "communauté" a inventé un super truc technique, d'autres ont fait que ça marche pour "le peuple" (les gens pas dans leur tour d'ivoire) et en on tiré le bénéfices.
On peut prendre encore l'exemple de XMPP : techniquement cool, mais inutilisable pour "le peuple", du coup Facebook a bien intégré mais a gardé pour lui, Google a fait GTalk qu'il ferme… Pourquoi? Parce que les mecs inventant le protocole ont été incapables d'aller plus loin et proposer quelque chose d'utilisable en vrai de manière inter-opérable (donc les entreprises qui se sont inspirées en ont profité pour fermer, de toutes façons il n'y a aucun concurrent ouvert qui propose le moindre truc utilisable sortis des gus dans leur tour d'ivoire non bankables)
Rien de nouveau, la "communauté" n'est pas tout, il faut derrière des gens qui pensent "utilisateur" pour que ça marche. Soit c'est un libriste qui y pense (Mozilla, VideoLAN…), soit un non libriste (Google, Amazon, Facebook, Apple…), l'important n'est pas l'idée technique, mais l'idée vis à vis de l'utilisateur, c'est celui qui pense utilisateur qui gagne (et qui fait de la partie technique ce qu'il veut ensuite, libre… Ou pas libre).
Note : je ne pense pas que le problème soit "centralisé vs décentralisé", je pense que c'est orthogonal, il suffirait que 2 personnes pensent utilisateurs pour le même truc pour "obliger" à faire décentraliser, c'est juste qu'en pratique il y a peu de gens pensant utilisateurs donc pas au même moment, et le premier qui y pensent peut se permettre de faire centralisé pour récupérer toute la thune, donc il ne se gène pas. Les coupables de cet état de fait ne sont pas les gens qui font centralisé car eux ne font qu'utiliser une possibilité, mais les gens qui disent vouloir faire décentralisé mais ne se bougent pas à réfléchir 5 minutes à l'utilisateur (en pratique, ça revient à n'avoir pas envie tant que ça à proposer du décentralisé, c'est juste de la communication envers soi-même pour ce donner bonne conscience).
Il ne reste donc plus qu'aux libristes de réellement vouloir proposer du libre, c'est à dire penser utilisateur (et quand on lit la prose des "libristes dans l'âme" et leur façon d'estimer l'utilisateur "qui devrait apprendre, pas à nous de nous abaisser à eux, on veut les éduquer contre leur gré même si ils veulent juste utiliser pour le moment et n'ont pas le temps de passer des jours sur toutes les technos qu'ils utilisent", on se dit que ce n'est pas gagné et que le proprio centralisé a encore de beaux jours devant lui).
IRC et XMPP (par exemple) avaient un potentiel énorme, mais n'ont pas su évoluer avec l'utilisateur "le peuple et non pas le geek" en tête. Dommage, une occasion (encore!) manquée et maintenant on a Slack.
Ce n'est pas la première idée de "la communauté" à être adaptée, et ce ne sera pas la dernière faute de remise en cause des gens qui ont l'idée technique (et les idées ne se brevetant pas, ben c'est normal que quelqu'un "prenne" l'idée et en fasse un truc "pensé utilisateur" qui supplante le truc prévu pour "ceux qui méritent", la nature a horreur du vide).
Autant j'ai compris avec vos liens et explications qu'un navigateur veuille prioriser AES128 pour les perfs quand il a le choix, autant je ne comprend pourquoi c'est désactivé.
Si demain on trouve une faille dans AES128 et pas dans AES256, on ne peux pas configurer le serveur en enlevant AES128 pour que les navigateurs prennent AES256, on a aucun moyen de dire "coucou ça craint maintenant, on monte", et des navigateurs ça reste plus que la durée de certificats SSL (WinXP est toujours la, heureusement que Microsoft lui a fait un patch pour supporter SHA2 maintenant qu'on se rend compte que SHA1 craint et qu'on migre les certificats vers SHA2).
Bon, restera les navigateurs "à jour" qui activeront AES256, certes, et il ne restera que les "vieux" trucs…
"Firefox sait faire du AES-256, mais seulement en mode CBC, pas en mode GCM", ca casse quand même. C'est quand même bizarre vu qu'il sait le gérer en AES-128 et que des concurrents savent faire en AES-256 aussi?
je suis d'accord avec le commentaire "It is a shame that Firefox cannot access servers which are limited to only allow the strongest cipher suites available."
128-GCM is far, far more desirable than 256-CBC, OK, but 256-GCM is far, far more desirable than 128-GCM.
Rappel de ce que j'ai dit : IE/Edge et Safari choisissent 256 (je sous entendais GCM en priorité), voila le résultat SSLLabs
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1
Android 5.0.0 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1
Chrome 47 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Firefox 42 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Edge 13 / Win 10 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Safari 9 / OS X 10.11 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
pour les mêmes priorités, pour les mêmes générations.
(et noter la "régression" sur Android, la je ne pige pas la suppression, peut-être un pb de perf/conso)
Mozilla était en avance sur Microsoft sur la sécu, le voila en retard, ca ne fait pas bizarre?
(bon, du coup pareil pour Chrome aussi, et pareil pour Apple aussi, j'aurai vraimeent inversé tout le monde là…)
Note: je suis conscient que AES-128 n'est pas cassé aujourd'hui, mais on ne sait pas dequoi est fait demain, ca met toujours du temps quand une vulnérabilité est découverte pour migrer. Et c'est aussi une question d'image, c'est important l'image technique pour les geeks.
(Au passage, une clef RSA de 4096-bits pour un certificat valable deux ans, je trouve ça complètement disproportionné.)
Plus ou moins d'accord, après c'était une préference pas de moi et je n'ai pas pris le temps de démontrer que ca flingue beaucoup le temps de handshake, donc faute d'arguments c'est resté (et ca n'a pas l'air de faire trop de mal, faudra que je teste le délai réel un jour que je ne saurais pas quoi faire)
Voila, suite des ciphers réorganisée pour que SHA soit en dernier, mais la réaction de FF et Chrome me surprend toujours (je priorise AES256 sur AES128, pour chaque combinaison, mais FF et Chrome s'entêtent à choisir du AES128), IE/Edge et Safari (et un Android 4.4 alors que 5.0 passe en 128) prennent du AES256. OK AES128 n'est pas encore troué, mais quand même bizarre de ne pas prendre du AES256 alors qu'on sait faire.
Sélectionner AES256 avec SHA1 mais SHA128 avec SHA2, il y a des choix bizarres.
Quand au fingerprint, pas encore troué l'argument qui convainc mon adminsys (je me fais violence, je délègue, et il ne faut ensuite pas imposer quoi que ce soit a l'adminsys, c'est le patron de ce domaine ensuite :) )
L'objet de mon désir n'est qu'un élément secondaire et n'a aucun intérêt, donc pas un oubli.
Sinon oui c'est joli ils ont même accepté les majuscules la où il faut :-D.
Par contre je me demande pourquoi le fond de l'url est rouge chez toi.
(Si c'est à cause du sha1 préféré pour la suite de chiffrement, ça sera bientôt modifié pour prendre en compte les priorités bizarres des navigateurs, c'est ce qui me manque pour être totalement content)
Lire ce genre de mots, ça ne me donne pas envie de croire qu'il y a une réflexion derrière, et d'imaginer que ce soit intéressant (et je parie que tu es tout aussi "neutre" qu'eux quand tu parles informatique, juste dans l'autre sens… Et que ça ferait "envie de vomir" tout autant la partie "adverse")
Ca fait très Hôpital qui se fout de la Charité.
Sérieux, vous voudriez décrédibiliser le libre en faisant croire qu'il y a rien d’intéressant qui sort des écrits des libristes que vous feriez exactement cette caricature.
En théorie je suis d'accord. En pratique, faire un audit sur un site web complet à 9K€ pour valider qu'on respecte les règles du W3C je trouve ça ridicule.
Tu n'as pas compris : c'est ce que tu dis en théorie que je critique; tu dis que si on demande un audit extérieur c'est qu'on n'a pas confiance, et je dis que si tu refuses c'est la qu'il n'y a pas de confiance possible.
Après, qu'en pratique tu dises "ben c'est x k€ en plus", c'est une autre histoire.
La seule chose que je dis, c'est que "non" ne m'inspirerai pas confiance, ce qui ne dit pas que ce doit être gratuit ("pas de problème pou un audit, je rajoute sur le devis" m'inspire plus confiance que "non non non allez fait-moi confiance").
Dans le cas d'un site web, on n'a quasiment jamais un CDC très clair,
"doit passer le checker W3C sans une seule erreur non expliquée" est déjà un début, non?
Ho oui la 8K… C'est du sport!
Ils ont élagué pas mal de détails, mais ça reste impressionnant ce qu'on peut faire en si peu de place (peso je n'arrive même pas à imaginer que ça puisse faire en si peu de commandes… Déjà que l'original tenait en 400k de tête…)
La scène n'est pas morte :-)
Ho, non, d'ailleurs ça m'a fait bizarre de retrouver le "style demo scene années 90" au concert de Mylène Farmer en intro de plusieurs minutes (vous pouvez vous foutre de moi et mes "goûts de chiottes" mais je payerai très très cher pour pouvoir revivre ce concert… Intro comprise)
ça coûte entre 5 et 20 heures de recherches/discussions/tests/etc. (…) Je me fais peut-être des idées.
Oui.
(pistes: personne n'est d'accord avec personne sur ce qui est mieux, la technologie change tous les jours, et ça dépend de la source / du type de film / les "moments" à prioriser / de la compatibilité que tu veux vs la qualité. Et… DVD? Tu es à la préhistoire, de nos jours c'est mini 720p pour du "bas débit" ou du 1080p sinon, dans toute bonne crémerie.)
[^] # 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).
[^] # 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é à -9.
Avoir des "haters" est le signe du succès, ça veut dire que tu tapes précisément où il fallait le faire, et que ça a du succès :
- les utilisateurs de Mac détestent? Ce n'est pas obligatoire (ou pas gênant : les updates système, ou alors on doit détester aussi "yum update"), donc c'est surtout une posture. A moins que les développeurs utilisent que ce canal mais du coup c'est sans doute pour une bonne raison que les développeurs le font?
- les développeurs de Mac détestent? Ce n'est pas obligatoire ils peuvent s'en passer et vendre en direct. A moins que les utilisateurs utilisent que ce canal mais du coup c'est sans doute pour une bonne raison que les utilisateurs le font, et que les 30% prélevés dont certes râler mais les 70% restant c'est quand même bon?
Bref, si certains détestent, c'est que beaucoup plus adorent.
Et c'est le prix à payer pour un truc qui marche.
(on peut parler des gens qui détestent Google, Amazon, Facebook… toujours parce qu'en fait, ça marche à cause de l'expérience utilisateur)
Résumons : tu ne fais que confirmer que l'AppStore est une chose réussie là où les autres ont échoué.
[^] # Re: Slack c'est quoi ?
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.
Une ligne suffit : Slack, c'est IRC utilisable par tout le monde (voir aussi les fonctionnalités décrites par Wikipedia), car l'entreprise derrière pense en priorité à l'expérience utilisateur.
# 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é à 4.
Pas besoin d'être une startup, je pense par exemple au système de repository Linux : à la base c'est super, en pratique c'est un repoussoir à développeur.
Apple a pris l'idée, a viré les limitations des "développeurs qui pensent à leurs délires sans réfléchir plus loin" (par exemple : permettre à quiconque de proposer un logiciel du moment où il respecte les règles sans se faire jeter parce qu'on n'aurait pas trouvé un mentor ni devoir passer 1 an entre la demande et l’acceptation, ne pas rejeter par principe le non libre "caca ça pue on n'en veut pas"…) et en a fait un super business (30% du prix de vente quand même…).
C'est que maintenant que par exemple Ubuntu pense à faire un Store plus tolérant, mais en attendant ce n'est plus l'écosystème Linux qui a le plus d'application facilement accessibles, c'est Mac. La grosse honte (pas comme si Apple s'était jeté dessus tout de suite, les libristes ont eu des années pour offrir une chose utilisable).
La "communauté" a inventé un super truc technique, d'autres ont fait que ça marche pour "le peuple" (les gens pas dans leur tour d'ivoire) et en on tiré le bénéfices.
On peut prendre encore l'exemple de XMPP : techniquement cool, mais inutilisable pour "le peuple", du coup Facebook a bien intégré mais a gardé pour lui, Google a fait GTalk qu'il ferme… Pourquoi? Parce que les mecs inventant le protocole ont été incapables d'aller plus loin et proposer quelque chose d'utilisable en vrai de manière inter-opérable (donc les entreprises qui se sont inspirées en ont profité pour fermer, de toutes façons il n'y a aucun concurrent ouvert qui propose le moindre truc utilisable sortis des gus dans leur tour d'ivoire non bankables)
Rien de nouveau, la "communauté" n'est pas tout, il faut derrière des gens qui pensent "utilisateur" pour que ça marche. Soit c'est un libriste qui y pense (Mozilla, VideoLAN…), soit un non libriste (Google, Amazon, Facebook, Apple…), l'important n'est pas l'idée technique, mais l'idée vis à vis de l'utilisateur, c'est celui qui pense utilisateur qui gagne (et qui fait de la partie technique ce qu'il veut ensuite, libre… Ou pas libre).
Note : je ne pense pas que le problème soit "centralisé vs décentralisé", je pense que c'est orthogonal, il suffirait que 2 personnes pensent utilisateurs pour le même truc pour "obliger" à faire décentraliser, c'est juste qu'en pratique il y a peu de gens pensant utilisateurs donc pas au même moment, et le premier qui y pensent peut se permettre de faire centralisé pour récupérer toute la thune, donc il ne se gène pas. Les coupables de cet état de fait ne sont pas les gens qui font centralisé car eux ne font qu'utiliser une possibilité, mais les gens qui disent vouloir faire décentralisé mais ne se bougent pas à réfléchir 5 minutes à l'utilisateur (en pratique, ça revient à n'avoir pas envie tant que ça à proposer du décentralisé, c'est juste de la communication envers soi-même pour ce donner bonne conscience).
Il ne reste donc plus qu'aux libristes de réellement vouloir proposer du libre, c'est à dire penser utilisateur (et quand on lit la prose des "libristes dans l'âme" et leur façon d'estimer l'utilisateur "qui devrait apprendre, pas à nous de nous abaisser à eux, on veut les éduquer contre leur gré même si ils veulent juste utiliser pour le moment et n'ont pas le temps de passer des jours sur toutes les technos qu'ils utilisent", on se dit que ce n'est pas gagné et que le proprio centralisé a encore de beaux jours devant lui).
IRC et XMPP (par exemple) avaient un potentiel énorme, mais n'ont pas su évoluer avec l'utilisateur "le peuple et non pas le geek" en tête. Dommage, une occasion (encore!) manquée et maintenant on a Slack.
Ce n'est pas la première idée de "la communauté" à être adaptée, et ce ne sera pas la dernière faute de remise en cause des gens qui ont l'idée technique (et les idées ne se brevetant pas, ben c'est normal que quelqu'un "prenne" l'idée et en fasse un truc "pensé utilisateur" qui supplante le truc prévu pour "ceux qui méritent", la nature a horreur du vide).
[^] # Re: Et c'est joli au moins?
Posté par Zenitram (site web personnel) . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 0.
Autant j'ai compris avec vos liens et explications qu'un navigateur veuille prioriser AES128 pour les perfs quand il a le choix, autant je ne comprend pourquoi c'est désactivé.
Si demain on trouve une faille dans AES128 et pas dans AES256, on ne peux pas configurer le serveur en enlevant AES128 pour que les navigateurs prennent AES256, on a aucun moyen de dire "coucou ça craint maintenant, on monte", et des navigateurs ça reste plus que la durée de certificats SSL (WinXP est toujours la, heureusement que Microsoft lui a fait un patch pour supporter SHA2 maintenant qu'on se rend compte que SHA1 craint et qu'on migre les certificats vers SHA2).
Bon, restera les navigateurs "à jour" qui activeront AES256, certes, et il ne restera que les "vieux" trucs…
[^] # Re: Et c'est joli au moins?
Posté par Zenitram (site web personnel) . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 2. Dernière modification le 28 décembre 2015 à 20:45.
"Firefox sait faire du AES-256, mais seulement en mode CBC, pas en mode GCM", ca casse quand même. C'est quand même bizarre vu qu'il sait le gérer en AES-128 et que des concurrents savent faire en AES-256 aussi?
je suis d'accord avec le commentaire "It is a shame that Firefox cannot access servers which are limited to only allow the strongest cipher suites available."
128-GCM is far, far more desirable than 256-CBC, OK, but 256-GCM is far, far more desirable than 128-GCM.
Rappel de ce que j'ai dit : IE/Edge et Safari choisissent 256 (je sous entendais GCM en priorité), voila le résultat SSLLabs
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1
Android 5.0.0 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1
Chrome 47 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Firefox 42 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Edge 13 / Win 10 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Safari 9 / OS X 10.11 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
pour les mêmes priorités, pour les mêmes générations.
(et noter la "régression" sur Android, la je ne pige pas la suppression, peut-être un pb de perf/conso)
Mozilla était en avance sur Microsoft sur la sécu, le voila en retard, ca ne fait pas bizarre?
(bon, du coup pareil pour Chrome aussi, et pareil pour Apple aussi, j'aurai vraimeent inversé tout le monde là…)
Note: je suis conscient que AES-128 n'est pas cassé aujourd'hui, mais on ne sait pas dequoi est fait demain, ca met toujours du temps quand une vulnérabilité est découverte pour migrer. Et c'est aussi une question d'image, c'est important l'image technique pour les geeks.
Plus ou moins d'accord, après c'était une préference pas de moi et je n'ai pas pris le temps de démontrer que ca flingue beaucoup le temps de handshake, donc faute d'arguments c'est resté (et ca n'a pas l'air de faire trop de mal, faudra que je teste le délai réel un jour que je ne saurais pas quoi faire)
[^] # Re: Et c'est joli au moins?
Posté par Zenitram (site web personnel) . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 2.
Voila, suite des ciphers réorganisée pour que SHA soit en dernier, mais la réaction de FF et Chrome me surprend toujours (je priorise AES256 sur AES128, pour chaque combinaison, mais FF et Chrome s'entêtent à choisir du AES128), IE/Edge et Safari (et un Android 4.4 alors que 5.0 passe en 128) prennent du AES256. OK AES128 n'est pas encore troué, mais quand même bizarre de ne pas prendre du AES256 alors qu'on sait faire.
Sélectionner AES256 avec SHA1 mais SHA128 avec SHA2, il y a des choix bizarres.
Quand au fingerprint, pas encore troué l'argument qui convainc mon adminsys (je me fais violence, je délègue, et il ne faut ensuite pas imposer quoi que ce soit a l'adminsys, c'est le patron de ce domaine ensuite :) )
[^] # Re: Et c'est joli au moins?
Posté par Zenitram (site web personnel) . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 3.
L'objet de mon désir n'est qu'un élément secondaire et n'a aucun intérêt, donc pas un oubli.
Sinon oui c'est joli ils ont même accepté les majuscules la où il faut :-D.
Par contre je me demande pourquoi le fond de l'url est rouge chez toi.
(Si c'est à cause du sha1 préféré pour la suite de chiffrement, ça sera bientôt modifié pour prendre en compte les priorités bizarres des navigateurs, c'est ce qui me manque pour être totalement content)
# Caricature
Posté par Zenitram (site web personnel) . En réponse au journal partenariat ecoeurant. Évalué à -10. Dernière modification le 01 décembre 2015 à 00:04.
Lire ce genre de mots, ça ne me donne pas envie de croire qu'il y a une réflexion derrière, et d'imaginer que ce soit intéressant (et je parie que tu es tout aussi "neutre" qu'eux quand tu parles informatique, juste dans l'autre sens… Et que ça ferait "envie de vomir" tout autant la partie "adverse")
Ca fait très Hôpital qui se fout de la Charité.
Sérieux, vous voudriez décrédibiliser le libre en faisant croire qu'il y a rien d’intéressant qui sort des écrits des libristes que vous feriez exactement cette caricature.
[^] # Re: pas facile
Posté par Zenitram (site web personnel) . En réponse au message Les recours possibles contre une agence web. Évalué à 1.
Tu n'as pas compris : c'est ce que tu dis en théorie que je critique; tu dis que si on demande un audit extérieur c'est qu'on n'a pas confiance, et je dis que si tu refuses c'est la qu'il n'y a pas de confiance possible.
Après, qu'en pratique tu dises "ben c'est x k€ en plus", c'est une autre histoire.
La seule chose que je dis, c'est que "non" ne m'inspirerai pas confiance, ce qui ne dit pas que ce doit être gratuit ("pas de problème pou un audit, je rajoute sur le devis" m'inspire plus confiance que "non non non allez fait-moi confiance").
"doit passer le checker W3C sans une seule erreur non expliquée" est déjà un début, non?
[^] # Re: The scene
Posté par Zenitram (site web personnel) . En réponse au journal La scène et le P2P. Évalué à 6.
Ho oui la 8K… C'est du sport!
Ils ont élagué pas mal de détails, mais ça reste impressionnant ce qu'on peut faire en si peu de place (peso je n'arrive même pas à imaginer que ça puisse faire en si peu de commandes… Déjà que l'original tenait en 400k de tête…)
Ho, non, d'ailleurs ça m'a fait bizarre de retrouver le "style demo scene années 90" au concert de Mylène Farmer en intro de plusieurs minutes (vous pouvez vous foutre de moi et mes "goûts de chiottes" mais je payerai très très cher pour pouvoir revivre ce concert… Intro comprise)
[^] # Re: Un avis d'un vieux et toujours actif mais de plus loin.
Posté par Zenitram (site web personnel) . En réponse au journal La scène et le P2P. Évalué à 1.
Oui.
(pistes: personne n'est d'accord avec personne sur ce qui est mieux, la technologie change tous les jours, et ça dépend de la source / du type de film / les "moments" à prioriser / de la compatibilité que tu veux vs la qualité. Et… DVD? Tu es à la préhistoire, de nos jours c'est mini 720p pour du "bas débit" ou du 1080p sinon, dans toute bonne crémerie.)