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.
Parce que les gens s’en foutent. C’est BEAUCOUP plus simple de maj un navigateur qu’un serveur et il existe au moins des recettes miracles pour y arriver (au Firefox portable), 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…).
Donc on arrête d’attendre des maj de nav, on les laisse avec tout d’activer par défaut et on ne s’emmerde plus. 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 et pourra corriger rapidement son serveur en cas de faille de sécu sans avoir à attendre la maj divine du navigateur qui va traîner des pieds. Un admin qui ne prend pas soin de sa sécu continuera à dégeuler la vie privée de ses utilisateurs.
il est maintenant de la responsabilité du navigateur si il accepte une connexion SSLv3 et DES.
Non, puisque SSLv3 et 3DES est désactivé sur mon serveur.
C’est l’intérêt du serveur-first : tu maîtrises ce qui se passe chez toi, quelque soit ce qui se présente en face.
Et comme indiqué plus haut, je ne trouverais pas du tout anormal qu’un client se mette à supporter tout et n’importe quoi. On aurait BEAUCOUP MOINS d’emmerde pour migrer nos serveurs et plus de question à se poser si ça sera compatible ou non avec nos config. On pourra patcher nos failles de sécu sans attendre que Duchmol-browser ou Tartampion-user-agent ait activé les mêmes suites que nous…
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).
Si, cf la démo quelque part dans ce topic.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
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).
La seule config qui mettrait fin au bordel ambiant et permettrait à tous de faire les maj de sécu sans se prendre la tête de savoir qui on va dégager ou pas du parc, c’est « ALL » sur les clients et « une unique suite secure de ton choix » sur les serveurs. En cas de pépin, les admins peuvent migrer quand ils voudront, sans avoir besoin de synchroniser quoi que ce soit et en étant assuré que leurs clients continueront à voir leur site en version pourrie ou en version sécurisée par la suite. Et de ton point de vue, tu peux assurer la sécurité de tes clients dès publication de la faille de sécurité si tu en as envie.
Si tu fais l’inverse, ie des clients restrictifs, à chaque pépin de sécu, tu retombes dans le bordel de la compat. Il faut déjà prendre une décision collégial pour se mettre d’accord sur les nouvelles suites à implémenter dans tous les navigateurs. Puis attendre que suffisamment de clients se soient mis à jour pour faire la bascule côté serveur et virer l’ancienne suite (et exclure de facto tous visiteurs pas à jour).
Ou alors tu actives toutes les suites côté serveur, et une suite unique côté client. Mais alors tu ne maîtrises ni ne peut assurer la sécurité de tes propres utilisateurs, qui s’ils ne sont pas à jour, utiliseront potentiellement des suites pourries avec ton service.
Bref, dans le 1er cas, c’est toi qui est maître de la sécurité de tes visiteurs, dans le 2nd cas non.
Rhaa. Mais tu lis un peu avant de balancer des affirmations péremptoires ?
Oui. Les chiffres que tu avances viennent de Firefox et de Chromium, pas des banques elles-mêmes.
Elles, elles refusent de virer RC4 et 3DES au titre qu’encore trop de leurs clients (chiffres avancés entre 1 et 4%) qui sont sur des trucs pas compatibles autre chose (vieux Android, IE6 sous Windows XP et IE8 sous Windows Vista), et aussi une grosse partie de leur infra bancaire pas compatible (typiquement les DAB sous Windows XP donc ne supportant guère plus que SSLv3 parfois).
Elles ont aussi du matos de terminaison TLS qui ne supportent pas mieux (toujours pas de PFS sur les F5 10.x par exemple ou de TLS > 1.0 sur les F5 9.X), faute de pouvoir être upgrader (problème du chiffrement hardware) ou d’avoir les moyens (il faut racheter des licences) et le temps de le faire.
Responsabilité du navigateur
Tout ce que tu dis s'applique indifféremment au serveur ou navigateur, mais tu accuses l'un et pas l'autre.
Cf ma démonstration ailleurs dans le topic, mais il faut justement que la responsabilité ne soit que d’un seul côté si on veut éviter la spirale infernale sécurité = incompatibilité et incompatibilité = pas de sécurité.
Et du coup elle ne peut être que côté serveur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
Après, tu pourras toujours dire que sur ton outil cryptcheck, elles obtiennent un F. Sauf qu'on se tue à t'expliquer que ta manière de noter n'a pas vraiment de sens…
Ma manière de noter tient justement compte des downgrade attacks et note la pire suite dispo et non la meilleure comme dans le cas de Qualys.
Qualys peut te donner un A ou B mais le site en question peut potentiellement te downgrader en F (RC4), alors que si je donne un B, tu aurais forcément B au moins même dans le pire cas de downgrade.
Donc c'est pas impossible, loin de la. Dans 3 mois, Firefox, Chrome et Edge ne supporteront plus RC4. Moins d'un an après la publication d'une attaque pratique sur l'algo. Pas si mal, non ?
1- J’attend de voir la réaction des opérateurs de serveurs, et la levée de bouclier qui va en découler (les admin sys PCI-DSS compliant, je vous salue, étant donné que PCI-DSS a déprécié 3DES, vous êtes dorénavant à poil en suite de chiffrement si vous ne supportez pas AES :P). Comme SHA-1, on risque d’avoir des marches arrière sur ce sujet.
2- La fragilité de RC4 date de 2013 avec la publication du programme BULLRUN de la NSA, qui attestait du déchiffrement temps réel de cette suite. On aura donc mis 3 ans pour agir, et on a toujours cette suite de chiffrement dans la nature, même à peut-être 3 mois d’une rupture techno côté client (ça veut dire qu’il n’y a eu aucun test de compatibilité de fait et que comme on dit, ça va être « when the shit hits the fan »)
Bon, on est d'accord sur les faits techniques, mais pas sur les stratégies à adopter.
On va reformuler alors :P
Dans le monde idéal des bisounours, clients et serveurs n’auraient que des suites fiables et corrigeraient immédiatement, l’ordre client ou serveur en premier n’aurait que peu d’importance.
Dans le monde idéal en pratique, il faudrait faire un choix de qui migre en premier.
Si ce sont les serveurs, on pète la compat’ avec les clients le temps pour les client de migrer.
Si ce sont les clients, on pète la compat’ avec les serveurs le temps pour les serveurs de migrer.
Mais la situation ne serait que temporaire dans les 2 cas, et la migration conduirait rapidement à avoir tout le monde à l’abri.
Ici encore, l’ordre n’aurait que peu d’importance.
Dans le monde réel, les serveurs sont migrables très difficilement, voire pas migrables du tout (serveurs old-old-old-school dépendant de vieux OS ou d’applis métiers), alors qu’à l’inverse les clients ne dépendent de rien et n’impactent pas grand chose (appli généralement isolée et indépendante de l’OS).
Alors qu’on peut envisager un monde (certainement utopiste) avec des navigateurs à jour partout (il suffit au pire de mettre une version portable de Firefox partout y compris sur Android 2.3 ou Windows XP), on n’a pas de plan d’action (ou en tout cas bien plus utopiste) permettant un monde avec des serveurs à jour partout.
On pose donc le 1er invariant : il y aura toujours des serveurs moisis dans la nature. (À noter que je ne fais aucun postulat sur l’état des navigateurs.)
De là, on en déduit que pour des raisons de compatibilité, les clients nécessiteront de supporter des suites faillibles. On a actuellement toujours plus ou moins réussi à sauver les meubles en désactivant au fur et à mesure les suites foireuses dans les clients, mais on voit bien que c’est de plus en plus difficile sans casser massivement la compat’ ou en demandant des breaking changes côté serveur.
On a donc notre 1ère règle qui s’en déduit : les clients doivent (MUST) supporter en même temps des suites faillibles et des suites sécurisées. À l’extrême limite, ils doivent (MUST) même obligatoirement supporter ALL:COMPLEMENTOFALL.
Qui dit suite faillible et suite sécurisée mixées dit downgrade attack possible vers la suite faillible.
On en déduit donc notre 2nd règle : les serveurs ne doivent (SHOULD) supporter que des suites sécurisés pour éviter tout fallback, les clients en face allant possiblement supporter des choses non sécurisées pour compat’ avec d’autres serveurs que nous.
Et on en déduit alors l’état du monde :
des serveurs moisis qui seront accessibles par tous, non sécurisés pour tous (mais difficile de faire mieux :P), mais qui peuvent devenir sécurisés pour tous un peu plus tard sans aucun problème de compatibilité à envisager
des serveurs sécurisés qui seront accessibles par tous et sécurisés pour tous
des navigateurs qui seront compatibles avec tout serveur existant
Si tu me trouves une situation plus optimale, je suis preneur.
On est entré dans une spirale infernale parce qu’on a voulu faire de la sécu par les 2 bouts (client et serveur), à la fois serveur et client, et qu’on se prend du coup le problème de compatibilité de plein fouet.
Il faut forcément couper un des 2 bouts (client ou serveur) pour mettre fin à la boucle et permettre une mise-à-jour de sécu sans se préoccuper de la compatibilité.
Étant donné qu’on veut de la sécurité, il faut donc couper le problème de la compatibilité, qui ne peut se régler qu’à gros coup de ALL:COMPLEMENTOFALL sur les clients.
Et à la limite revoir la notion de ALL:COMPLEMENTOFALL de temps en temps pour virer définitivement tout ce qui n’est plus utilisé du tout ou de manière très marginale.
La seule différence entre EXPORT et pas export au niveau protocole, c’est la taille de clef.
Donc si tu modifies la liste des ciphers du client pour dire « Eh, je cause EXPORT », le serveur, s’il supporte aussi EXPORT, te causera avec une clef de 512 bits générée exprès pour au lieu d’une de 2048 bits, tu n’as plus qu’à modifier la réponse du serveur de EXPORT à non EXPORT, et le client n’y verra que du feu (il a envoyé non EXPORT, il reçoit non EXPORT).
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…
Regarde la doc page 40 et 41, c’est assez compréhensible que ça va marcher tout à fait correctement.
Dans ce cas, le client n’annonce que DHE, le serveur supporte DHE & DHE-EXPORT, un downgrade est possible vers DHE-EXPORT…
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).
Tu peux poster sur ton site que attention, à partir du XX/XX/XXXX, il faudra un navigateur à jour pour accéder à ton site. En mettant un joli lien vers Firefox. Ça règlera 99.999% des problèmes et ça améliorera la sécu de tous tes visiteurs, y compris ailleurs que chez toi.
Il ne restera que quelques rares cas particuliers (les vieux Android, et encore, pas avec ceux avec un FF à jour) qui représentera moins de 1% du trafic.
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?.
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.
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…).
Et même avec une telle liste, tu imagines la charge de travail juste pour faire un tel contact ? C’est du délire total ne serait-ce que de l’avoir envisager…
Et alors que tu avais des solutions à apporter à 99.99% de tes visiteur (installer Firefox ou Chromium à jour, dispo partout et sur toutes les plate-formes), Firefox ne peut pas en faire de même pour les serveurs.
Certains sont protégés par des terminaisons TLS hardware (BigIP ou F5), ou par des load balancers. Et ne pourront migrer que dans des lustres, et encore si leurs vendeurs fournis des correctifs (le support de AES dans BigIP date de quelques mois seulement par exemple).
D’autres dépendent de stack logiciel non maintenues (Java, COBOL, IIS sous Windows ME…) et ne peuvent juste pas se mettre à jour.
Bref, même en supposant une prise de contact, la plupart des serveurs ne sont pas patchables sans des travaux très lourds, en tout cas d’un niveau de difficulté bien supérieure à juste mettre à jour son Firefox ou son Chromium !
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?.
Va dire ça aux banques, et revient me voir quand tu en auras une seule qui sera passé en A suite à ta remarque… Je me bat depuis 3 ans contre elles, y’en a pas une qui a bougé, malgré une notification formelle de la part du Ministère des Finances et de l’ANSSI suite à mes travaux.
Actuellement ce downgrade attaque n’a de sens que vers les suites EXPORT ou RC4, parce qu’on ne sait pas déchiffrer rapidement autre chose.
Mais on peut imaginer un downgrade attack massif de la part de la NSA (il suffit de faire juste un gros sed sur le réseau) pour forcer le passage à des suites non PFS si supporté, et ainsi espérer déchiffrer l’intégralité du trafic échangé dans XX années (cassage de la clef RSA a posteriori), ce qui n’aurait pas été possible avec les suites PFS.
Une attaque théorique (pas exploitée en pratique ou en tout cas pas de manière connue) existe aussi qui permet de downgrader sur du EXPORT même si le client ne le supporte pas.
Bref, à partir du moment où tu supportes une sécu X et une sécu Y plus faible que X, un attaquant peut toujours te forcer à downgrader vers Y avec TLS actuel.
Ça peut lui servir à rien (par exemple downgrader de ECDHE-AES à DHE-AES), mais c’est toujours possible. Le cas de ECDHE-EXPORT montre aussi que c’est parfois indépendant du support réel annoncé par le client (même si le client ne supporte pas, le downgrade est possible).
Il faut attendre TLSv1.3 pour espérer contrer ce fait.
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é.
C’est le cas en pratique : combien de personnes sont réellement au courant des problèmes de TLS, hors admin systèmes. Même pire, en réalité même les admins sont à la limite de l’incompétence sur TLS & X.509 (tu l’a avoué toi-même dans ce topic, malgré 20 ans d’XP, tu ne savais pas comment fonctionnait exactement HTTPS)
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
Raté, ils viennent de réactiver SSLv3 et DES (non non, pas 3DES, DES…).
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).
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.
C’est exactement comme SHA-1, ça casse bien trop de truc et donc tout le monde est méga frileux à l’idée de toucher à ça directement dans les clients, alors que les serveurs et les CA soucieux de la sécurité sont déjà passé à SHA-2 (et ECDSA) depuis longtemps.
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, alors que Firefox ne peut pas le faire, encore moins sans s’être mis d’accord avec les autres navigateurs pour prendre une décision collégiale, sans pouvoir communiquer avec les admins des sites mal configurés qui leur sont totalement étrangers et en devant attendre que la très grosse majorité des serveurs aient fait leur travail.
Les suites supportées ne peuvent pas être dans le certificat.
C’est de la conf côté serveur, et on ne pourrait pas renouveler le certificat en cas de changement à effectuer…
Ce sont 2 choses bien distinctes (chiffrement et identification) qui ne peuvent pas être mélangées
En soi rien.
Mais comme tout problème posant des questionnements théoriques (MAC then Encrypt ? Encrypt then MAC ? MAC and Encrypt ?) pas franchement tranchable dans ce cas précis (dans tous les cas on aura ici un bout de traitement sur des données non authentifiées), les débats à l’IETF peuvent être (très) long pour arriver à un pseudo-consensus :P
C'est justement pour ça que les serveurs sont forcés de supporter les anciennes suites de chiffrement, alors qu'un client à jour peut se permettre de désactiver ces anciennes suites.
Il ne peut pas plus. Par exemple si tu veux payer tes impôts, il te faut obligatoirement RC4 ou 3DES, et rien d’autre…
Et donc tu dois avoir RC4 d’activé sur ton client. Et donc tu te boufferas du downgrade attack potentiellement sur tous les autres serveurs qui supportent AES & RC4.
Alors que si ces derniers n’avaient supportés que AES, tu aurais pu payer tes impôts et être à l’abri ailleurs.
C’est l’intérêt d’avoir une sécu qui vient des serveurs et des clients qui supportent le max de truc : tu es en sécu partout ou les admins ont fait l’effort de te mettre en sécu, sans pour autant t’exclure des services où les admins n’ont rien fait.
En allant par là, ça ne me génerait à la limite même pas que les clients activent par défaut l’intégralité des suites de chiffrement possibles et imaginables, mais que les serveurs se limitent à uniquement quelques suites sécurisés :
client = compatibilité = tout
serveur = sécurité = 1 seul
Ça permettrait en plus une sécurité glissante : à la détection d’une faille de sécu, les serveurs pourraient migrer sur une autre suite de chiffrement en désactivant immédiatement l’ancienne sans avoir besoin d’attendre la mise-à-jour des clients, et la sécurité s’améliorerait progressivement au fur et à mesure de la migration des serveurs, chaque serveur qui aurait fait l’effort de migration étant lui immédiatement et totalement à l’abri.
L’inverse n’a aucun sens (client avec 1 seule suite), puisque si les serveurs devraient activer temporairement l’ancienne suite et la nouvelle suite (et donc avec une suite faillible active), le temps pour les clients de migrer progressivement de l’ancienne suite à la nouvelle suite pour ensuite se faire une seconde modification pour retirer définitivement l’ancienne suite faillible.
Bilan : la sécu vient des serveurs, point.
C’est la situation actuelle qui est bloquée, parce que personne ne veut faire d’effort et/ou perdre de la compat’. Mais en régime nominal, ça viendrait des serveurs. Vraiment.
Et il faut me dire en quoi un serveur accepte RC4 a la moindre non incitation sur les navigateurs
un serveur qui a RC4 (et autre chose, évidement)
Le blem est là : beaucoup de solutions utilisées ne supportent pas mieux que RC4 ou 3DES.
Le site des impôts par exemple ?
les deux ont les mêmes possibilités de refuser une connexion non fiable
Non, les clients doivent être compatibles avec le maximum de serveur, donc accepter plusieurs choses (a minima AES, RSA, DHE, ECHDE, SHA-1, SHA-2, TLSv1.0, TLSv1.1, TLSv1.2, actuellement aussi 3DES et RC4) et s’exposer alors toujours à un downgrade attack, alors que le serveur peut élaguer plus fortement ses suites et n’en supporter qu’une ou 2 (par exemple TLSv1.2 + ECHDE + AES only) sans perdre tant que ça d’utilisateurs (aller, à la louche moins de 1%), mettant à l’abri ses propres utilisateurs.
Dis autrement, il est aujourd’hui impossible d’avoir un navigateur TLSv1.2 + ECHDE + AES only sans se mettre à dos les ¾ de la planète et sans solution d’upgrade possible sur pas mal de serveurs (TLS hardware), alors qu’il est possible d’avoir un serveur TLSv1.2 + ECHDE + AES only sans trop galérer et en proposant une piste de mise-à-jur aux clients rejetés.
L’évolution doit/peut donc venir uniquement des serveurs, non des clients.
Les clients suivront après, une fois que la majorité des serveurs supportera autre chose que du faillible.
Il y a une grosse marge entre « les chercheurs en cryptographie disent que c’est cassé » et « la NSA le casse en temps réel », ce n’est pas simplement « dire la même chose d’une autre façon ».
Et effectivement, ce n’est pas dire la même chose du tout dans le cas de RC4.
Les chercheurs en crypto utilisent de la bruteforce ou des astuces mathématiques pour tenter d’accélérer la vitesse de cassage de RC4.
La NSA, elle, a une backdoor (implémentée ou trouvée) directement dans RC4 et le déchiffre donc en temps réel, via leur programme BULLRUN :
However, the agency's unspecified "groundbreaking cryptanalytic capabilities" could include a practical attack on RC4.
Je me demande si ce serait utilisable en pratique de signer la liste des suites et des protocoles supportés (de la même manière qu'on signe la clé publique du serveur).
En pratique, ça pose un problème de l’œuf ou de la poule au niveau authentification.
Le serveur et le client pourraient signer leur 1er paquet (contenant les suites supportées) avec leur clef privée, mais vu qu’on est dans le handshake… cette clef n’est pas encore authentifiée !!!!
Pire, dans la très grosse majorité des cas (hors authentification par certificat en fait), la clef du client ne sera jamais authentifiée et sera générée à la volée par ton navigateur…
Pas d’authentification du paquet client de possible donc !
Après le jamais me semble excessif: Firefox 42 ne supporte ni SSLv3 (depuis un moment), ni RC4 Qualys, c'est quand même la preuve qu'on arrive à virer les truc vraiment craignos. En pratique ça marche pas si mal.
Imagine que tu es Wikimedia Foundation, et que tu veux permettre à un dissident mal équipé (vieux smartphone, vieux PC) de venir documenter les exactions d'une dictature quelconque sur Wikipedia. Tu fais quoi ? Tu forces TLS 1.2 et PFS ? Tu le laisses quand même venir en TLS 1.0 et 3DES ?
Alors très certainement la réponse est : surtout tu ne joues pas avec ta vie, on t’envoie un OpSec via RSF sur place pour te mettre à l’abri (pas de TLS du tout + Tor + SecureDrop)
Ou même simplement si tu veux laisser la population d'un pays consulter des articles Wikipedia sur des sujets prohibés dans leurs pays (je pense à la Birmanie par exemple).
Idem, tu ne fais pas le con et tu restes bien à l’abri chez toi en attendant de savoir ce qui se passe (MitM TLS par la Birmanie qui pourrait te coûter une balle dans la tête par exemple)
Ou si tu es Google et que tu veux laisser les habitants du Gabon ou du Congo se connecter sur Gmail sans faire transiter leur mot de passe en clair sur le Wifi partagé (même si c'est pas ultra sécurisé, personne va aller dépenser 50000 cores/hours pour casser leur mot de passe).
Là OK, ce modèle de menace est recevable pour utiliser du 3DES ou du SSLv3.
Ce qui n’incite pas les nav’ a arrêter le support de RC4 et de 3DES…
Et toi, quand tu visites Facebook ou Google, tu es peut-être en train de te prendre un downgrade attack vers RC4 sans le voir, et donc tu es en train de tout balancer à la NSA, en clair, malgré ton GNU/Linux totalement à jour et ton navigateur dernier cri…
Note que l'attaque pratique sur RC4 est assez récente (2015). Y'avait une attaque réalisable en labo depuis quelques années, mais ça nécessitait des millions de handshakes. Du coup, on est pas en retard sur ce coup.
Si on applique RFC 7525 à la lettre, on trouve une config équivalente à la mienne (TLSv1.2 + ECHDE + AES only)
Non, elle ne dit pas ça.
J’ai bien dit « équivalente » en terme de sécu. Quand tu as viré RC4 et 3DES (112 bits théorique mais certainement plus faible en réalité à cause de sa taille de bloc de 64 bits seulement), y’a plus vraiment de downgrade attack supplémentaire dispo entre ma config et 7525 :P
Sinon la diff PFS/non PFS, mais on sort du cadre des downgrades attacks (clefs incassables suffisamment vite à l’heure actuelle).
Mais rien que pour DANE/TLSA, ça permet de fixer en partie le gros problème de la confiance en les CA, et rien que ça ça a le mérite d’exister et d’être promu !
La vraie bonne chose à faire ce serait que tous les serveurs du monde intégrent rapidement les protocoles (suites) récents. Ensuite les navigateurs désactivent les suites pourries dans leurs nouvelles versions. Ainsi, les sites n'ont pas besoin de se priver d'utilisateurs. Les clients n'ont pas besoin de se priver de sites non plus.
Les suites faillibles ayant encore de beau jour devant elles (parce que ce sont les seuls qui passent actuellement dans du matos hard ou sur des loads balancers, etc), les navigateurs ne sont pas prêts de les retirer.
Et donc si tu veux mettre à l’abris tous tes utilisateurs, tu passes à du secure only (sinon downgrade attack) côté serveur, et tu milites fortement pour aider les quelques qui resteront à la porte à passer à quelque chose de plus à jour et sécurisé, améliorant ainsi globalement la sécu de tous tes utilisateurs sur tous les autres serveurs sécurisés qu’ils visiteront.
Ça peut être fait là maintenant tout de suite dans l’instant.
Plutôt que d’espérer voir un jour les supports pourris virés des navs (hint : quelque chose entre longtemps et jamais) et donc l’ensemble de tes visiteurs à poil en permanence sauf sur les trop rares serveurs sécurisés en attendant.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Parce que les gens s’en foutent. C’est BEAUCOUP plus simple de maj un navigateur qu’un serveur et il existe au moins des recettes miracles pour y arriver (au Firefox portable), 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…).
Donc on arrête d’attendre des maj de nav, on les laisse avec tout d’activer par défaut et on ne s’emmerde plus. 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 et pourra corriger rapidement son serveur en cas de faille de sécu sans avoir à attendre la maj divine du navigateur qui va traîner des pieds. Un admin qui ne prend pas soin de sa sécu continuera à dégeuler la vie privée de ses utilisateurs.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Non, puisque SSLv3 et 3DES est désactivé sur mon serveur.
C’est l’intérêt du serveur-first : tu maîtrises ce qui se passe chez toi, quelque soit ce qui se présente en face.
Et comme indiqué plus haut, je ne trouverais pas du tout anormal qu’un client se mette à supporter tout et n’importe quoi. On aurait BEAUCOUP MOINS d’emmerde pour migrer nos serveurs et plus de question à se poser si ça sera compatible ou non avec nos config. On pourra patcher nos failles de sécu sans attendre que Duchmol-browser ou Tartampion-user-agent ait activé les mêmes suites que nous…
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Si, cf la démo quelque part dans ce topic.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
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).
La seule config qui mettrait fin au bordel ambiant et permettrait à tous de faire les maj de sécu sans se prendre la tête de savoir qui on va dégager ou pas du parc, c’est « ALL » sur les clients et « une unique suite secure de ton choix » sur les serveurs. En cas de pépin, les admins peuvent migrer quand ils voudront, sans avoir besoin de synchroniser quoi que ce soit et en étant assuré que leurs clients continueront à voir leur site en version pourrie ou en version sécurisée par la suite. Et de ton point de vue, tu peux assurer la sécurité de tes clients dès publication de la faille de sécurité si tu en as envie.
Si tu fais l’inverse, ie des clients restrictifs, à chaque pépin de sécu, tu retombes dans le bordel de la compat. Il faut déjà prendre une décision collégial pour se mettre d’accord sur les nouvelles suites à implémenter dans tous les navigateurs. Puis attendre que suffisamment de clients se soient mis à jour pour faire la bascule côté serveur et virer l’ancienne suite (et exclure de facto tous visiteurs pas à jour).
Ou alors tu actives toutes les suites côté serveur, et une suite unique côté client. Mais alors tu ne maîtrises ni ne peut assurer la sécurité de tes propres utilisateurs, qui s’ils ne sont pas à jour, utiliseront potentiellement des suites pourries avec ton service.
Bref, dans le 1er cas, c’est toi qui est maître de la sécurité de tes visiteurs, dans le 2nd cas non.
[^] # Re: Let’s Encrypt
Posté par Aeris (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:39.
Oui. Les chiffres que tu avances viennent de Firefox et de Chromium, pas des banques elles-mêmes.
Elles, elles refusent de virer RC4 et 3DES au titre qu’encore trop de leurs clients (chiffres avancés entre 1 et 4%) qui sont sur des trucs pas compatibles autre chose (vieux Android, IE6 sous Windows XP et IE8 sous Windows Vista), et aussi une grosse partie de leur infra bancaire pas compatible (typiquement les DAB sous Windows XP donc ne supportant guère plus que SSLv3 parfois).
Elles ont aussi du matos de terminaison TLS qui ne supportent pas mieux (toujours pas de PFS sur les F5 10.x par exemple ou de TLS > 1.0 sur les F5 9.X), faute de pouvoir être upgrader (problème du chiffrement hardware) ou d’avoir les moyens (il faut racheter des licences) et le temps de le faire.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Cf ma démonstration ailleurs dans le topic, mais il faut justement que la responsabilité ne soit que d’un seul côté si on veut éviter la spirale infernale sécurité = incompatibilité et incompatibilité = pas de sécurité.
Et du coup elle ne peut être que côté serveur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Oui, et SSLv3 et DES (pas 3DES !) au passage… ><
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Ma manière de noter tient justement compte des downgrade attacks et note la pire suite dispo et non la meilleure comme dans le cas de Qualys.
Qualys peut te donner un A ou B mais le site en question peut potentiellement te downgrader en F (RC4), alors que si je donne un B, tu aurais forcément B au moins même dans le pire cas de downgrade.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Un client pourrait effectivement refuser la clef du serveur s’il la juge trop faible.
Mais ça ne serait alors pas trop conforme à la norme X.509.
Et on retomberait alors dans le choix cornélien : 512 bits, c’est faible ou c’est pas faible ? Et 1024 bits alors ?
[^] # Re: Let’s Encrypt
Posté par Aeris (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 06 janvier 2016 à 14:01.
1- J’attend de voir la réaction des opérateurs de serveurs, et la levée de bouclier qui va en découler (les admin sys PCI-DSS compliant, je vous salue, étant donné que PCI-DSS a déprécié 3DES, vous êtes dorénavant à poil en suite de chiffrement si vous ne supportez pas AES :P). Comme SHA-1, on risque d’avoir des marches arrière sur ce sujet.
2- La fragilité de RC4 date de 2013 avec la publication du programme BULLRUN de la NSA, qui attestait du déchiffrement temps réel de cette suite. On aura donc mis 3 ans pour agir, et on a toujours cette suite de chiffrement dans la nature, même à peut-être 3 mois d’une rupture techno côté client (ça veut dire qu’il n’y a eu aucun test de compatibilité de fait et que comme on dit, ça va être « when the shit hits the fan »)
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 13:54.
On va reformuler alors :P
Dans le monde idéal des bisounours, clients et serveurs n’auraient que des suites fiables et corrigeraient immédiatement, l’ordre client ou serveur en premier n’aurait que peu d’importance.
Dans le monde idéal en pratique, il faudrait faire un choix de qui migre en premier.
Si ce sont les serveurs, on pète la compat’ avec les clients le temps pour les client de migrer.
Si ce sont les clients, on pète la compat’ avec les serveurs le temps pour les serveurs de migrer.
Mais la situation ne serait que temporaire dans les 2 cas, et la migration conduirait rapidement à avoir tout le monde à l’abri.
Ici encore, l’ordre n’aurait que peu d’importance.
Dans le monde réel, les serveurs sont migrables très difficilement, voire pas migrables du tout (serveurs old-old-old-school dépendant de vieux OS ou d’applis métiers), alors qu’à l’inverse les clients ne dépendent de rien et n’impactent pas grand chose (appli généralement isolée et indépendante de l’OS).
Alors qu’on peut envisager un monde (certainement utopiste) avec des navigateurs à jour partout (il suffit au pire de mettre une version portable de Firefox partout y compris sur Android 2.3 ou Windows XP), on n’a pas de plan d’action (ou en tout cas bien plus utopiste) permettant un monde avec des serveurs à jour partout.
On pose donc le 1er invariant : il y aura toujours des serveurs moisis dans la nature. (À noter que je ne fais aucun postulat sur l’état des navigateurs.)
De là, on en déduit que pour des raisons de compatibilité, les clients nécessiteront de supporter des suites faillibles. On a actuellement toujours plus ou moins réussi à sauver les meubles en désactivant au fur et à mesure les suites foireuses dans les clients, mais on voit bien que c’est de plus en plus difficile sans casser massivement la compat’ ou en demandant des breaking changes côté serveur.
On a donc notre 1ère règle qui s’en déduit : les clients doivent (MUST) supporter en même temps des suites faillibles et des suites sécurisées. À l’extrême limite, ils doivent (MUST) même obligatoirement supporter ALL:COMPLEMENTOFALL.
Qui dit suite faillible et suite sécurisée mixées dit downgrade attack possible vers la suite faillible.
On en déduit donc notre 2nd règle : les serveurs ne doivent (SHOULD) supporter que des suites sécurisés pour éviter tout fallback, les clients en face allant possiblement supporter des choses non sécurisées pour compat’ avec d’autres serveurs que nous.
Et on en déduit alors l’état du monde :
Si tu me trouves une situation plus optimale, je suis preneur.
On est entré dans une spirale infernale parce qu’on a voulu faire de la sécu par les 2 bouts (client et serveur), à la fois serveur et client, et qu’on se prend du coup le problème de compatibilité de plein fouet.
Il faut forcément couper un des 2 bouts (client ou serveur) pour mettre fin à la boucle et permettre une mise-à-jour de sécu sans se préoccuper de la compatibilité.
Étant donné qu’on veut de la sécurité, il faut donc couper le problème de la compatibilité, qui ne peut se régler qu’à gros coup de ALL:COMPLEMENTOFALL sur les clients.
Et à la limite revoir la notion de ALL:COMPLEMENTOFALL de temps en temps pour virer définitivement tout ce qui n’est plus utilisé du tout ou de manière très marginale.
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 13:13.
La seule différence entre EXPORT et pas export au niveau protocole, c’est la taille de clef.
Donc si tu modifies la liste des ciphers du client pour dire « Eh, je cause EXPORT », le serveur, s’il supporte aussi EXPORT, te causera avec une clef de 512 bits générée exprès pour au lieu d’une de 2048 bits, tu n’as plus qu’à modifier la réponse du serveur de EXPORT à non EXPORT, et le client n’y verra que du feu (il a envoyé non EXPORT, il reçoit non EXPORT).
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…
Regarde la doc page 40 et 41, c’est assez compréhensible que ça va marcher tout à fait correctement.
Dans ce cas, le client n’annonce que DHE, le serveur supporte DHE & DHE-EXPORT, un downgrade est possible vers DHE-EXPORT…
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 13:02.
Tu peux poster sur ton site que attention, à partir du XX/XX/XXXX, il faudra un navigateur à jour pour accéder à ton site. En mettant un joli lien vers Firefox. Ça règlera 99.999% des problèmes et ça améliorera la sécu de tous tes visiteurs, y compris ailleurs que chez toi.
Il ne restera que quelques rares cas particuliers (les vieux Android, et encore, pas avec ceux avec un FF à jour) qui représentera moins de 1% du trafic.
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.
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…).
Et même avec une telle liste, tu imagines la charge de travail juste pour faire un tel contact ? C’est du délire total ne serait-ce que de l’avoir envisager…
Et alors que tu avais des solutions à apporter à 99.99% de tes visiteur (installer Firefox ou Chromium à jour, dispo partout et sur toutes les plate-formes), Firefox ne peut pas en faire de même pour les serveurs.
Certains sont protégés par des terminaisons TLS hardware (BigIP ou F5), ou par des load balancers. Et ne pourront migrer que dans des lustres, et encore si leurs vendeurs fournis des correctifs (le support de AES dans BigIP date de quelques mois seulement par exemple).
D’autres dépendent de stack logiciel non maintenues (Java, COBOL, IIS sous Windows ME…) et ne peuvent juste pas se mettre à jour.
Bref, même en supposant une prise de contact, la plupart des serveurs ne sont pas patchables sans des travaux très lourds, en tout cas d’un niveau de difficulté bien supérieure à juste mettre à jour son Firefox ou son Chromium !
Va dire ça aux banques, et revient me voir quand tu en auras une seule qui sera passé en A suite à ta remarque… Je me bat depuis 3 ans contre elles, y’en a pas une qui a bougé, malgré une notification formelle de la part du Ministère des Finances et de l’ANSSI suite à mes travaux.
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 12:50.
Ben c’est exactement ce que fait la faille FREAK, downgrader les ciphers suites pour retomber dans quelque chose de cassable.
Actuellement ce downgrade attaque n’a de sens que vers les suites EXPORT ou RC4, parce qu’on ne sait pas déchiffrer rapidement autre chose.
Mais on peut imaginer un downgrade attack massif de la part de la NSA (il suffit de faire juste un gros sed sur le réseau) pour forcer le passage à des suites non PFS si supporté, et ainsi espérer déchiffrer l’intégralité du trafic échangé dans XX années (cassage de la clef RSA a posteriori), ce qui n’aurait pas été possible avec les suites PFS.
Une attaque théorique (pas exploitée en pratique ou en tout cas pas de manière connue) existe aussi qui permet de downgrader sur du EXPORT même si le client ne le supporte pas.
Bref, à partir du moment où tu supportes une sécu X et une sécu Y plus faible que X, un attaquant peut toujours te forcer à downgrader vers Y avec TLS actuel.
Ça peut lui servir à rien (par exemple downgrader de ECDHE-AES à DHE-AES), mais c’est toujours possible. Le cas de ECDHE-EXPORT montre aussi que c’est parfois indépendant du support réel annoncé par le client (même si le client ne supporte pas, le downgrade est possible).
Il faut attendre TLSv1.3 pour espérer contrer ce fait.
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 12:41.
C’est le cas en pratique : combien de personnes sont réellement au courant des problèmes de TLS, hors admin systèmes. Même pire, en réalité même les admins sont à la limite de l’incompétence sur TLS & X.509 (tu l’a avoué toi-même dans ce topic, malgré 20 ans d’XP, tu ne savais pas comment fonctionnait exactement HTTPS)
Raté, ils viennent de réactiver SSLv3 et DES (non non, pas 3DES, DES…).
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.
C’est exactement comme SHA-1, ça casse bien trop de truc et donc tout le monde est méga frileux à l’idée de toucher à ça directement dans les clients, alors que les serveurs et les CA soucieux de la sécurité sont déjà passé à SHA-2 (et ECDSA) depuis longtemps.
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, alors que Firefox ne peut pas le faire, encore moins sans s’être mis d’accord avec les autres navigateurs pour prendre une décision collégiale, sans pouvoir communiquer avec les admins des sites mal configurés qui leur sont totalement étrangers et en devant attendre que la très grosse majorité des serveurs aient fait leur travail.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Les suites supportées ne peuvent pas être dans le certificat.
C’est de la conf côté serveur, et on ne pourrait pas renouveler le certificat en cas de changement à effectuer…
Ce sont 2 choses bien distinctes (chiffrement et identification) qui ne peuvent pas être mélangées
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
En soi rien.
Mais comme tout problème posant des questionnements théoriques (MAC then Encrypt ? Encrypt then MAC ? MAC and Encrypt ?) pas franchement tranchable dans ce cas précis (dans tous les cas on aura ici un bout de traitement sur des données non authentifiées), les débats à l’IETF peuvent être (très) long pour arriver à un pseudo-consensus :P
[^] # Re: Let’s Encrypt
Posté par Aeris (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 06 janvier 2016 à 11:14.
Il ne peut pas plus. Par exemple si tu veux payer tes impôts, il te faut obligatoirement RC4 ou 3DES, et rien d’autre…
Et donc tu dois avoir RC4 d’activé sur ton client. Et donc tu te boufferas du downgrade attack potentiellement sur tous les autres serveurs qui supportent AES & RC4.
Alors que si ces derniers n’avaient supportés que AES, tu aurais pu payer tes impôts et être à l’abri ailleurs.
C’est l’intérêt d’avoir une sécu qui vient des serveurs et des clients qui supportent le max de truc : tu es en sécu partout ou les admins ont fait l’effort de te mettre en sécu, sans pour autant t’exclure des services où les admins n’ont rien fait.
En allant par là, ça ne me génerait à la limite même pas que les clients activent par défaut l’intégralité des suites de chiffrement possibles et imaginables, mais que les serveurs se limitent à uniquement quelques suites sécurisés :
Ça permettrait en plus une sécurité glissante : à la détection d’une faille de sécu, les serveurs pourraient migrer sur une autre suite de chiffrement en désactivant immédiatement l’ancienne sans avoir besoin d’attendre la mise-à-jour des clients, et la sécurité s’améliorerait progressivement au fur et à mesure de la migration des serveurs, chaque serveur qui aurait fait l’effort de migration étant lui immédiatement et totalement à l’abri.
L’inverse n’a aucun sens (client avec 1 seule suite), puisque si les serveurs devraient activer temporairement l’ancienne suite et la nouvelle suite (et donc avec une suite faillible active), le temps pour les clients de migrer progressivement de l’ancienne suite à la nouvelle suite pour ensuite se faire une seconde modification pour retirer définitivement l’ancienne suite faillible.
Bilan : la sécu vient des serveurs, point.
C’est la situation actuelle qui est bloquée, parce que personne ne veut faire d’effort et/ou perdre de la compat’. Mais en régime nominal, ça viendrait des serveurs. Vraiment.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Le blem est là : beaucoup de solutions utilisées ne supportent pas mieux que RC4 ou 3DES.
Le site des impôts par exemple ?
Non, les clients doivent être compatibles avec le maximum de serveur, donc accepter plusieurs choses (a minima AES, RSA, DHE, ECHDE, SHA-1, SHA-2, TLSv1.0, TLSv1.1, TLSv1.2, actuellement aussi 3DES et RC4) et s’exposer alors toujours à un downgrade attack, alors que le serveur peut élaguer plus fortement ses suites et n’en supporter qu’une ou 2 (par exemple TLSv1.2 + ECHDE + AES only) sans perdre tant que ça d’utilisateurs (aller, à la louche moins de 1%), mettant à l’abri ses propres utilisateurs.
Dis autrement, il est aujourd’hui impossible d’avoir un navigateur TLSv1.2 + ECHDE + AES only sans se mettre à dos les ¾ de la planète et sans solution d’upgrade possible sur pas mal de serveurs (TLS hardware), alors qu’il est possible d’avoir un serveur TLSv1.2 + ECHDE + AES only sans trop galérer et en proposant une piste de mise-à-jur aux clients rejetés.
L’évolution doit/peut donc venir uniquement des serveurs, non des clients.
Les clients suivront après, une fois que la majorité des serveurs supportera autre chose que du faillible.
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Et effectivement, ce n’est pas dire la même chose du tout dans le cas de RC4.
Les chercheurs en crypto utilisent de la bruteforce ou des astuces mathématiques pour tenter d’accélérer la vitesse de cassage de RC4.
La NSA, elle, a une backdoor (implémentée ou trouvée) directement dans RC4 et le déchiffre donc en temps réel, via leur programme BULLRUN :
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 10:01.
En pratique, ça pose un problème de l’œuf ou de la poule au niveau authentification.
Le serveur et le client pourraient signer leur 1er paquet (contenant les suites supportées) avec leur clef privée, mais vu qu’on est dans le handshake… cette clef n’est pas encore authentifiée !!!!
Pire, dans la très grosse majorité des cas (hors authentification par certificat en fait), la clef du client ne sera jamais authentifiée et sera générée à la volée par ton navigateur…
Pas d’authentification du paquet client de possible donc !
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Ah oui, j’avais oublié ce truc :P
Faut que je regarde combien de sites institutionnels ne te sont donc plus accessibles…
Alors très certainement la réponse est : surtout tu ne joues pas avec ta vie, on t’envoie un OpSec via RSF sur place pour te mettre à l’abri (pas de TLS du tout + Tor + SecureDrop)
Idem, tu ne fais pas le con et tu restes bien à l’abri chez toi en attendant de savoir ce qui se passe (MitM TLS par la Birmanie qui pourrait te coûter une balle dans la tête par exemple)
Là OK, ce modèle de menace est recevable pour utiliser du 3DES ou du SSLv3.
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 01:06.
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…
Ce qui n’incite pas les nav’ a arrêter le support de RC4 et de 3DES…
Et toi, quand tu visites Facebook ou Google, tu es peut-être en train de te prendre un downgrade attack vers RC4 sans le voir, et donc tu es en train de tout balancer à la NSA, en clair, malgré ton GNU/Linux totalement à jour et ton navigateur dernier cri…
[^] # Re: Let’s Encrypt
Posté par Aeris (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 à 00:30.
Oui et non. En labo ça prend des millions de handshakes, mais la NSA a a priori une backdoor dessus car elle le casse en temps réel depuis 2013 : https://twitter.com/ioerror/status/398059565947699200
J’ai bien dit « équivalente » en terme de sécu. Quand tu as viré RC4 et 3DES (112 bits théorique mais certainement plus faible en réalité à cause de sa taille de bloc de 64 bits seulement), y’a plus vraiment de downgrade attack supplémentaire dispo entre ma config et 7525 :P
Sinon la diff PFS/non PFS, mais on sort du cadre des downgrades attacks (clefs incassables suffisamment vite à l’heure actuelle).
[^] # Re: Contre DNSSEC
Posté par Aeris (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 rien que pour DANE/TLSA, ça permet de fixer en partie le gros problème de la confiance en les CA, et rien que ça ça a le mérite d’exister et d’être promu !
[^] # Re: Let’s Encrypt
Posté par Aeris (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.
Les suites faillibles ayant encore de beau jour devant elles (parce que ce sont les seuls qui passent actuellement dans du matos hard ou sur des loads balancers, etc), les navigateurs ne sont pas prêts de les retirer.
Et donc si tu veux mettre à l’abris tous tes utilisateurs, tu passes à du secure only (sinon downgrade attack) côté serveur, et tu milites fortement pour aider les quelques qui resteront à la porte à passer à quelque chose de plus à jour et sécurisé, améliorant ainsi globalement la sécu de tous tes utilisateurs sur tous les autres serveurs sécurisés qu’ils visiteront.
Ça peut être fait là maintenant tout de suite dans l’instant.
Plutôt que d’espérer voir un jour les supports pourris virés des navs (hint : quelque chose entre longtemps et jamais) et donc l’ensemble de tes visiteurs à poil en permanence sauf sur les trop rares serveurs sécurisés en attendant.