J’ai dis que c’était facile de mettre à jour un nav’ comparé à un serveur.
Et on te répond que non, car ça implique le bon fonctionnement de l'interface chaise-clavier, et tout le monde sauf Aeris sait que cette interface merde un max.
Donc cet supposition n'est pas valide, donc tout tombe à l'eau (et fait même pencher la conclusion ailleurs une fois ce point changé dans la démonstration)
Le GROS problème dans ton analyse est que tu fantasmes sur "facile de mettre à jour un nav’ comparé à un serveur". Ne pas comprendre ça, j'avoue que ça me dépasse (ce n'est pas technique, c'est juste l'humanité de l'interface qu'on veut mettre dans la chaine d'évolution)
On n’a aucune porte de sortie identifiée pour les serveurs,
Ben si, la même chose que tu demandes aux gens derrière un navigateur. La différence est que les admins ont un problème plus gros si ils ne se bougent pas.
Donc tes arguments militent toujours pour le contraire de ta conclusion, quand on prend en compte un facteur que tu oublie (l'humain qui veut et l'humain qui a le pognon)
Tu réfléchis comme un robot qui pensent que tous les gens sont des robots logiques prêt à rejeter le dilemme du prisonnier et faire le mieux pour la société, le monde n'est pas fait de robots.
C’est BEAUCOUP plus simple de maj un navigateur qu’un serveur
Non.
(Sérieusement, il faut vraiment expliquer pourquoi des IE/XP sont toujours dans la nature?)
mais ce n’est pas fait régulièrement parce que les gens ne connaissent pas l’hygiène de base de l’informatique (si tu en es encore à utiliser IE6 sous XP alors que tu pourrais utiliser Firefox sécurisé sous XP…).
Ha, excuse-moi, en fait tu descends ton propre argument tout seul. Pas besoin des autres!
Ca ne te fait pas bizarre de dire une chose et son contraire dans la même phrase?
Un admin qui prend soin de sa sécu pourra enfin faire les choses proprement sans se préoccuper d’activer ou non des suites faillibles pour faire plaisir à tel ou tel navigateur
Non (perte d'utilisateurs, et les utilisateurs ont le pognon).
Tu oublies une chose (le pognon). Cet oubli inverse complètement la conclusion.
C'est délirant : tu flingues toi-même tes idées.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
Pareil pour les navigateurs!
Mais… En fait, pourquoi on pourrait pas? Si les serveurs perdent de l'argent faute de visiteurs, ils vont vite migrer. Ca ne tient pas!
Et des suites restrictives côté client, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des serveurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un navigateur ne peut pas se limiter aux mêmes ciphers que toi non plus).
Et des suites restrictives côté serveur, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des navigateurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un serveur ne peut pas se limiter aux mêmes ciphers que toi non plus).
Et donc?
tu pourras répéter cet "argument" indéfiniment, ça ne convainc pas (loin de la, ça convainc en fait du contraire, car les gens derrière le navigateurs ont le pognon, et les gens derrière le serveur veulent le pognon)
Toi, tu dis à des gens voulant le pognon de virer le pognon, on s'en fout qu'ils aillent ailleurs. Tu oublies un détail… Le pognon, les mecs des serveurs le veulent.
Ca tourne en boucle (Aeris balance un truc "bizarre" pas très réaliste sur les responsabilités, c'est démonté, il le répète sans changer le contenu pour mieux convaincre donc ça doit pas bien aller, etc), je crois que le mieux est d'en rester la.
Raison de plus de laisser les serveurs comme ça (ceux qui acceptent RC4 et AES) et taper sur les navigateurs, plus faciles à mettre à jour (ton argument) en désactivant RC4.
tu argumentes à fond pour l'inverse des tes idées, bizarre…
Et du coup elle ne peut être que côté serveur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
Et du coup elle ne peut être que côté navigateur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
Ca marche aussi (juste en inversant tes arguments)!
Tu n'as pas démontré que c'est mieux côté serveur que navigateur (et honnêtement, quand on lis ton argumentaire, on en déduit plutôt même le contraire de ta conclusion : tes arguments, une conclusion inverse complètement).
Pour ne pas répéter ce que quelqu'un d'autre à déjà dit, lien (ok, il a laissé la réponse ouverte, mais… ;-) )
Mais du coup, contrairement à ce que tu pousses ("la faute aux serveurs"), il est maintenant de la responsabilité du navigateur si il accepte une connexion SSLv3 et DES.
Plains-donc toi des navigateurs (et fait un test sur les navigateurs, pour les noter)
Non mais là on part dans le délire complet, d'une personne qui est complètement dans son monde.
Je poste sur mon site, et? Comme la plupart des sites, mes visiteurs sont de passage! Tu oublies tous les nouveaux (et ils sont nombreux).
Tout le monde n'a pas un site avec des amis que l'admin connait personnellement.
La, c'est du grand n'importe quoi comme explications.
Encore une fois, OK pour la technique, mais alors pour la partie humaine, c'est bien faux.
Firefox ne peut décemment pas envisager de contacter les admins des serveurs, encore moins en récupérant manuellement les données de contact un peu partout.
Mais les admin de serveurs peuvent contacter leurs utilisateurs foireux… Va comprendre pour l'un est OK et pas l'autre.
Pire, ils ne peuvent même pas lister lesquels posent problème sauf à scanner l’ensemble de la plage IP et à tester les ciphers suites supportées en réalité (et pour le faire, je te garanti que ça prend du temps, beaucoup de temps…).
Comme tout le monde : top 100000 Alexa.
Bon, dès qu'on parle de "philosophie", je crois qu'il vaut mieux passer…
Et tu sais parfaitement faire du TLS côté client avec une clef RSA de 512 bits, tu auras juste l’impression que la clef du serveur est une clef de 512 bits…
Donc le client peut voir qu'il fait du 512-bit, et donc refuser (c'est une politique de sécurité).
N'est-ce donc pas de la faute du navigateur si il accepte 512 bits? et corriger sa faille?
J'avoue ne pas comprendre le problème.
existe aussi qui permet de downgrader sur du EXPORT même si le client ne le supporte pas.
Je ne comprend pas comment le navigateur va "parler" EXPORT si il ne le supporte pas. A la réponse "EXPORT", j'imagine plutôt qu'il va rien comprendre et arrêter, donc attaque par downgrade ééchouée
Comment forcer un client à "parler" une langue non supportée?
Parce que FF ne peut pas désactiver RC4 sans exploser au passage des terrachiés de domaine qui sont protégés par du F5, du BigIP, du Fortinet ou de la config datée des années 70.
Même argument que ceux qui veulent garder RC4 dans le serveur : ne pas exploser au passage des terrachiés de gens qui ont pas mieux.
Maintenant, reste à définir "terrachiés" de chaque côté, ça manque de nombres.
Alors qu’un admin peut parfaitement désactiver ça immédiatement dans sa conf sur une décision unilatérale et avec un peu de com’ et d’assistance à tes utilisateurs qui te sont connus et qui seront minoritaires à rencontrer des problèmes
gni???
Je ne connais pas mes utilisateurs (ils sont anonymes! Ca ne marche pas, ils partent et je ne les revoient jamais; et au pire, ils écrivent dans les forum que je suis pourri car ça ne marche pas chez eux et que je suis le seul à faire chier car je n'ai pas fait un choix collégial, bon la à la limite du coup je peux les contacter, un par un… Mais trop cher, donc non).
Par contre, il y a généralement de quoi contacter l'admin d'un serveur (page contact en HTTP), et il sont moins nombreux, donc plus efficace comme action, surtout que des admins sont payés donc on peut viser le chef pour se plaindre si marche pas, plus efficace non?.
Tu donnes des arguments inverses en fait.
Quand à la modif collégiale, suffit que Chrome (pour FF, c'était "avant", maintenant on s'en fout un peu, du moins c'est moins marquant) décide, et ça va vite aller…
bref, tes deux dernières lignes, ben je vois perso que c'est encore pareil (problème de collégialité etc… Tout pareil)
Désolé, mais ça me semble toujours très subjectif, parfois faux, et peu convainquant.
Des serveurs désactivent --> Des navigateurs ne peuvent plus se connecter.
Des navigateurs désactivent --> Des serveurs ne peuvent plus accepter de connexion.
Désolé, la je dois être bouché, mais je ne vois toujours pas la différence que tu fais.
J'ai l'impression que tu considères qu'un admin de serveur est plus intelligent qu'un utilisateur, mais c'est un préjugé que tu as qui ne tient pas dans la réalité.
Dans ton exemple "RC4 et les impôts", FF qui désactive complètement RC4 (ok, je me suis trompé, c'est que à la fin du mois.
Note que perso j'accède à static.impots.gouv.fr en TLS_DHE_RSA_WITH_AES_128_CBC_SHA, c'est moyen (DH 1024) mais pas en RC4 donc quand FF va désactiver RC4 la sécurité sera bonne (pas de downgrade possible en RC4 sinon FF va pas aimer), donc c'est la responsabilité de FF si ma sécurité est mauvaise (ils n'ont pas désactivé RC4 avant). Je ne comprend toujours pas pourquoi ce n'est pas la faute de FF qu'ils n'aient pas désactivé RC4 (avec le même impact de perdre du monde que si le serveur le désactive).
bref, toujours pas compris pourquoi les serveurs sont plus fautifs que les navigateurs.
Pas d’authentification du paquet client de possible donc !
question de béotien : qu'est-ce qui bloque dans l'idée que le serveur envoie le hash du premier paquet dans sa réponse une fois que le hadshake est fait, ce qui permet au client de vérifier que son premier paquet n'a pas été altéré?
Pas d'oeuf et de poule dans ce cas (les anciens clients ignorent juste l'extension).
J'avoue ne pas voir ce qui bloque, tout en n'étant pas expert (clairement!)
Au détriment de l’ensemble des autres utilisateurs de leur service, qui auraient peut-être aimé être en sécurité avec un navigateur à jour, eux…
Si le navigateur est à jour, point de problème : SSLv3 et RC4 sont désactivé (reste donc 3DES, pas connu pour être cassé, donc clients et serveurs à jour le gardent…)
Ce qui n’incite pas les nav’ a arrêter le support de RC4 et de 3DES…
Pourquoi?
Tiens, d'ailleurs, les nav' ont arrêté le support de RC4 (reste donc 3DES, bis…), donc…
Et il faut me dire en quoi un serveur accepte RC4 a la moindre non incitation sur les navigateurs, désolé mais je ne comprend pas le lien de cause à effet, qui peut le plus peut le moins, un serveur qui a RC4 (et autre chose, évidement) ou pas ne change rien du tout sur le support de RC4 par le navigateur (pas de lien! Ou démontre-le).
autant je te suis sur la partie technique, autant sur la partie philosophique j'ai beaucoup plus de mal (même je vois que ça ne le fait pas du tout), je ne suis pas convaincu par les argument sortant du ex-aequo pour les clients vs serveurs : le deux ont les mêmes possibilités de refuser une connexion non fiable.
Désolé, mais ne pas être d'accord avec toi sur une question philosophique ne veut pas dire qu'ils sont mauvais, tu as peut-être juste pas les mêmes priorités ni les mêmes réponse à une question sans réponse évidente.
Et perso, je comprend (comprendre != militer pour) l'argument qu'il vaut mieux un peu de sécurité contre les "petits cons" (pas capables de casser RC4, pas capable de faire du MITM, non tout le monde n'a pas les moyens de la NSA) que faire uniquement comme toi à leur interdire un peu de sécurité pour avoir (peut-être) plus de sécurité pour les autres.
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.
[^] # 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 on te répond que non, car ça implique le bon fonctionnement de l'interface chaise-clavier, et tout le monde sauf Aeris sait que cette interface merde un max.
Donc cet supposition n'est pas valide, donc tout tombe à l'eau (et fait même pencher la conclusion ailleurs une fois ce point changé dans la démonstration)
Le GROS problème dans ton analyse est que tu fantasmes sur "facile de mettre à jour un nav’ comparé à un serveur". Ne pas comprendre ça, j'avoue que ça me dépasse (ce n'est pas technique, c'est juste l'humanité de l'interface qu'on veut mettre dans la chaine d'évolution)
Ben si, la même chose que tu demandes aux gens derrière un navigateur. La différence est que les admins ont un problème plus gros si ils ne se bougent pas.
Donc tes arguments militent toujours pour le contraire de ta conclusion, quand on prend en compte un facteur que tu oublie (l'humain qui veut et l'humain qui a le pognon)
Tu réfléchis comme un robot qui pensent que tous les gens sont des robots logiques prêt à rejeter le dilemme du prisonnier et faire le mieux pour la société, le monde n'est pas fait de robots.
[^] # 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. Dernière modification le 06 janvier 2016 à 16:13.
Non.
(Sérieusement, il faut vraiment expliquer pourquoi des IE/XP sont toujours dans la nature?)
Ha, excuse-moi, en fait tu descends ton propre argument tout seul. Pas besoin des autres!
Ca ne te fait pas bizarre de dire une chose et son contraire dans la même phrase?
Non (perte d'utilisateurs, et les utilisateurs ont le pognon).
Tu oublies une chose (le pognon). Cet oubli inverse complètement la conclusion.
C'est délirant : tu flingues toi-même tes idées.
[^] # 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.
Pareil pour les navigateurs!
Mais… En fait, pourquoi on pourrait pas? Si les serveurs perdent de l'argent faute de visiteurs, ils vont vite migrer. Ca ne tient pas!
Et des suites restrictives côté serveur, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des navigateurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un serveur ne peut pas se limiter aux mêmes ciphers que toi non plus).
Et donc?
tu pourras répéter cet "argument" indéfiniment, ça ne convainc pas (loin de la, ça convainc en fait du contraire, car les gens derrière le navigateurs ont le pognon, et les gens derrière le serveur veulent le pognon)
Toi, tu dis à des gens voulant le pognon de virer le pognon, on s'en fout qu'ils aillent ailleurs. Tu oublies un détail… Le pognon, les mecs des serveurs le veulent.
Ca tourne en boucle (Aeris balance un truc "bizarre" pas très réaliste sur les responsabilités, c'est démonté, il le répète sans changer le contenu pour mieux convaincre donc ça doit pas bien aller, etc), je crois que le mieux est d'en rester la.
[^] # 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 06 janvier 2016 à 15:40.
Raison de plus de laisser les serveurs comme ça (ceux qui acceptent RC4 et AES) et taper sur les navigateurs, plus faciles à mettre à jour (ton argument) en désactivant RC4.
tu argumentes à fond pour l'inverse des tes idées, bizarre…
[^] # 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 06 janvier 2016 à 15:39.
Et du coup elle ne peut être que côté navigateur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
Ca marche aussi (juste en inversant tes arguments)!
Tu n'as pas démontré que c'est mieux côté serveur que navigateur (et honnêtement, quand on lis ton argumentaire, on en déduit plutôt même le contraire de ta conclusion : tes arguments, une conclusion inverse complètement).
Pour ne pas répéter ce que quelqu'un d'autre à déjà dit, lien (ok, il a laissé la réponse ouverte, mais… ;-) )
[^] # 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.
Mais du coup, contrairement à ce que tu pousses ("la faute aux serveurs"), il est maintenant de la responsabilité du navigateur si il accepte une connexion SSLv3 et DES.
Plains-donc toi des navigateurs (et fait un test sur les navigateurs, pour les noter)
[^] # 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.
Non mais là on part dans le délire complet, d'une personne qui est complètement dans son monde.
Je poste sur mon site, et? Comme la plupart des sites, mes visiteurs sont de passage! Tu oublies tous les nouveaux (et ils sont nombreux).
Tout le monde n'a pas un site avec des amis que l'admin connait personnellement.
La, c'est du grand n'importe quoi comme explications.
Encore une fois, OK pour la technique, mais alors pour la partie humaine, c'est bien faux.
Mais les admin de serveurs peuvent contacter leurs utilisateurs foireux… Va comprendre pour l'un est OK et pas l'autre.
Comme tout le monde : top 100000 Alexa.
Bon, dès qu'on parle de "philosophie", je crois qu'il vaut mieux passer…
[^] # 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.
Responsabilité du navigateur.
tu dis qu'il n'est pas responsable de la sécu, mais en fait… Si.
Tout ce que tu dis s'applique indifféremment au serveur ou navigateur, mais tu accuses l'un et pas l'autre.
[^] # 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.
Donc le client peut voir qu'il fait du 512-bit, et donc refuser (c'est une politique de sécurité).
N'est-ce donc pas de la faute du navigateur si il accepte 512 bits? et corriger sa faille?
J'avoue ne pas comprendre le problème.
[^] # 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 ne comprend pas comment le navigateur va "parler" EXPORT si il ne le supporte pas. A la réponse "EXPORT", j'imagine plutôt qu'il va rien comprendre et arrêter, donc attaque par downgrade ééchouée
Comment forcer un client à "parler" une langue non supportée?
[^] # 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.
Même argument que ceux qui veulent garder RC4 dans le serveur : ne pas exploser au passage des terrachiés de gens qui ont pas mieux.
Maintenant, reste à définir "terrachiés" de chaque côté, ça manque de nombres.
gni???
Je ne connais pas mes utilisateurs (ils sont anonymes! Ca ne marche pas, ils partent et je ne les revoient jamais; et au pire, ils écrivent dans les forum que je suis pourri car ça ne marche pas chez eux et que je suis le seul à faire chier car je n'ai pas fait un choix collégial, bon la à la limite du coup je peux les contacter, un par un… Mais trop cher, donc non).
Par contre, il y a généralement de quoi contacter l'admin d'un serveur (page contact en HTTP), et il sont moins nombreux, donc plus efficace comme action, surtout que des admins sont payés donc on peut viser le chef pour se plaindre si marche pas, plus efficace non?.
Tu donnes des arguments inverses en fait.
Quand à la modif collégiale, suffit que Chrome (pour FF, c'était "avant", maintenant on s'en fout un peu, du moins c'est moins marquant) décide, et ça va vite aller…
bref, tes deux dernières lignes, ben je vois perso que c'est encore pareil (problème de collégialité etc… Tout pareil)
Désolé, mais ça me semble toujours très subjectif, parfois faux, et peu convainquant.
[^] # 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.
Des serveurs désactivent --> Des navigateurs ne peuvent plus se connecter.
Des navigateurs désactivent --> Des serveurs ne peuvent plus accepter de connexion.
Désolé, la je dois être bouché, mais je ne vois toujours pas la différence que tu fais.
J'ai l'impression que tu considères qu'un admin de serveur est plus intelligent qu'un utilisateur, mais c'est un préjugé que tu as qui ne tient pas dans la réalité.
Dans ton exemple "RC4 et les impôts", FF qui désactive complètement RC4 (ok, je me suis trompé, c'est que à la fin du mois.
Note que perso j'accède à static.impots.gouv.fr en TLS_DHE_RSA_WITH_AES_128_CBC_SHA, c'est moyen (DH 1024) mais pas en RC4 donc quand FF va désactiver RC4 la sécurité sera bonne (pas de downgrade possible en RC4 sinon FF va pas aimer), donc c'est la responsabilité de FF si ma sécurité est mauvaise (ils n'ont pas désactivé RC4 avant). Je ne comprend toujours pas pourquoi ce n'est pas la faute de FF qu'ils n'aient pas désactivé RC4 (avec le même impact de perdre du monde que si le serveur le désactive).
bref, toujours pas compris pourquoi les serveurs sont plus fautifs que les navigateurs.
[^] # 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.
question de béotien : qu'est-ce qui bloque dans l'idée que le serveur envoie le hash du premier paquet dans sa réponse une fois que le hadshake est fait, ce qui permet au client de vérifier que son premier paquet n'a pas été altéré?
Pas d'oeuf et de poule dans ce cas (les anciens clients ignorent juste l'extension).
J'avoue ne pas voir ce qui bloque, tout en n'étant pas expert (clairement!)
[^] # 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.
Si le navigateur est à jour, point de problème : SSLv3 et RC4 sont désactivé (reste donc 3DES, pas connu pour être cassé, donc clients et serveurs à jour le gardent…)
Pourquoi?
Tiens, d'ailleurs, les nav' ont arrêté le support de RC4 (reste donc 3DES, bis…), donc…
Et il faut me dire en quoi un serveur accepte RC4 a la moindre non incitation sur les navigateurs, désolé mais je ne comprend pas le lien de cause à effet, qui peut le plus peut le moins, un serveur qui a RC4 (et autre chose, évidement) ou pas ne change rien du tout sur le support de RC4 par le navigateur (pas de lien! Ou démontre-le).
autant je te suis sur la partie technique, autant sur la partie philosophique j'ai beaucoup plus de mal (même je vois que ça ne le fait pas du tout), je ne suis pas convaincu par les argument sortant du ex-aequo pour les clients vs serveurs : le deux ont les mêmes possibilités de refuser une connexion non fiable.
Désolé, mais ne pas être d'accord avec toi sur une question philosophique ne veut pas dire qu'ils sont mauvais, tu as peut-être juste pas les mêmes priorités ni les mêmes réponse à une question sans réponse évidente.
Et perso, je comprend (comprendre != militer pour) l'argument qu'il vaut mieux un peu de sécurité contre les "petits cons" (pas capables de casser RC4, pas capable de faire du MITM, non tout le monde n'a pas les moyens de la NSA) que faire uniquement comme toi à leur interdire un peu de sécurité pour avoir (peut-être) plus de sécurité pour les autres.
[^] # 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.