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.
C’est en partie vrai, mais le problème a ensuite bootstrapé tout seul…
Pour gérer les serveurs tout pourris, les clients « riches » se sont mis à supporter RC4-MD5.
Ce qui a conduit à descendre la sécu de tout le monde (downgrade attack possible sur les servers) et à générer un cercle infernal.
Pour rappel quand même, en théorie le problème des clients « riches » vs les clients « pauvres » n’a pas/plus à avoir lieu : l’IETF a tranché et RC4 ne devrait plus jamais pouvoir être utilisé, nul part, ainsi que toutes les suites faillibles :
Si on applique RFC 7525 à la lettre, on trouve une config équivalente à la mienne (TLSv1.2 + ECHDE + AES only) et tous les serveurs du monde devrait être sur cette config (implémentation d’une RFC).
Que les serveurs sont beaucoup plus facilement mettable à jour et par des personnes qui sont en plus sensées savoir de quoi il retourne.
Alors que dès que tu es côté client, tu as une inertie énorme, l’impossibilité de forcer les maj, et des personnes qui ne comprennent pas ce qui est en train de se jouer.
En plus, si tu prends la situation actuelle, tu vas laisser beaucoup moins de personnes sur le carreau à pousser du TLSv1.2 + AES + ECDHE sur ton serveur (dans 99.999% des cas ça va passer et les pouillèmes restants sont des trucs vraiment moisis dont on devrait se foutre), que de désactiver RC4 côté client (et empécher la connexion à tous les serveurs ne supportant que ça, ie un gros paquet de monde).
Il est bien plus facile que chaque admin sys fasse sa petite portion de chemin vers un monde TLSv1.2 + AES + ECHDE only, les un après les autres, que de devoir attendre que la majeure partie des serveurs supportent TLSv1.2 + AES + ECHDE pour pouvoir passer le client en TLSv1.2 + AES + ECHDE only.
D’autant plus que ça mettra au moins tes visiteurs à l’abri, quelque soit leur navigateur.
Non. La sécurité de TLS est garantie pour un couple (client,serveur) seulement si l'une des deux conditions est valide:
- Le serveur ne supporte aucune suite TLS faillible
- Le client ne supporte aucune suite TLS faillible
Non, la condition nécessaire et suffisante se situe uniquement côté serveur pour un couple (client, serveur).
Si le serveur ne supporte aucune suite TLS faillible, alors même si le client en supporte une, il n’y a aucun downgrade attack de possible et la négociation TLS débouchera sur la sélection d’une suite fiable.
L’autre sens n’est pas possible, puisque pour un simple problème de compatibilité avec les autres serveurs, les clients doivent obligatoirement supporter des suites faillibles.
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.
Je suis un peu ce que tu fais, et je sais pas pourquoi tu mets toute la faute sur les opérateurs de serveurs.
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é (plus de downgrade attack possible puisque les suites faillibles ne sont pas supportées par le client).
Même si tu n’as pas d’autre sous-domaine…
Tu peux te retrouver avec des problèmes avec des CDN et des certificats wildcard déployés un peu trop à l’arrache qui pourrait être aussi valide pour ton domaine et qui pointe sur ton adresse IP, mais avec des paramètres TLS négociés bien plus faibles et un cross-accès à une resource critique… :D
Après, tu peux être un peu moins extrémiste, comme activer TLSv1.0 et TLSv1.1 (faillible à POODLE mais mitigation possible (désactiver Javascript)) ou AES non PFS (faillible au cassage de ta clef dans XX années, mais les données récoltées seront obsolètes pour la plupart).
C’est surtout RC4 (cassé par la NSA en temps réel), 3DES (trop faible et dans la zone rouge), les suites EXPORT et SSLv3 qui sont à désactiver puisque des attaques existent déjà pour eux.
En gros tout ce qui a du rouge ou du noir ici.
Le reste est globalement (gris) à très certainement (vert et bleu) fiable.
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?
C’est exactement ça. La sécurité de TLS n’est garantie que si tu ne publies aucune suite faillible côté serveur, sinon un downgrade attack peut forcer le navigateur à utiliser une suite faillible qu’il supporterait lui-aussi.
Avoir du PFS et du non PFS actif côté serveur n’est fiable que si le navigateur en face ne supporte que PFS.
Avoir du PFS et du non PFS actif côté client n’est fiable que si le serveur en face ne supporte que PFS.
Donc avoir PFS et non PFS en même temps, côté client ou serveur, c’est s’exposer soi-même à un downgrade dans le cas du navigateur, et exposer l’ensemble de ses clients supportant uniquement du non PFS ou les 2 dans le cas du serveur.
La seule config qui referme l’ensemble des failles existantes et des downgrade attack possibles est donc : https://tls.imirhil.fr/https/imirhil.fr
Ç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…)…
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.
En fait on a un vrai problème avec TLS parce que la dépendance est double :
On pourrait mettre à jour tous nos serveurs pour ne supporter que du TLSv1.2 + ECHDHE + AES-GCM, mais du coup on exclurait tous les anciens navs’ qui ne supportent pas AES ou pas TLSv1.2, ou pas ECHDHE…
On pourrait mettre à jour tous nos navigateurs pour ne supporter que du TLSv1.2 + ECHDHE + AES-GCM, mais du coup on exclurait tous les anciens serveurs qui ne supportent pas TLSv1.2.
Du coup, la seule stratégie viable est de migrer serveur et client à la fois, vers les mêmes suites de chiffrement, en même temps. Autant dire que c’est infaisable…
Et qu’on se traîne une longue traîne de trucs totalement moisi, à la fois côté serveur mais aussi côté client. Exposant à des downgrade attack l’ensemble du monde, y compris ceux à jours.
Au motif qu’on ne peut décemment pas mettre à la porte les utilisateurs de Windows XP ou IE 8…
Est-ce qu'il y a une proof of concept qui montre un downgrade de suite de chiffrement
Oui, c’est même là-dessus qu’est basé la faille FREAK.
Les outils pour ce MitM sont dispos ici.
À l’heure actuelle, c’est uniquement le downgrade vers *-EXPORT qui est utilisé, vu que c’est uniquement les tailles de clefs très faibles associées qui permettent la 2nde partie de l’attaque (le cassage de la clef en temps réel).
On peut par contre imaginer le même principe utilisé à l’échelle de la NSA, capable de casser RC4 en temps réel.
Et ça devrait bientôt être le cas de 3DES qui n’a que 112 bits de sécurité théorique (et encore moins en pratique puisqu’il n’utilise que des tailles de blocs de 64 bits) et donc déjà largement dans la zone jaune du « ça commence à puer franchement les gars ».
[^] # 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.
[^] # 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.
C’est en partie vrai, mais le problème a ensuite bootstrapé tout seul…
Pour gérer les serveurs tout pourris, les clients « riches » se sont mis à supporter RC4-MD5.
Ce qui a conduit à descendre la sécu de tout le monde (downgrade attack possible sur les servers) et à générer un cercle infernal.
Pour rappel quand même, en théorie le problème des clients « riches » vs les clients « pauvres » n’a pas/plus à avoir lieu : l’IETF a tranché et RC4 ne devrait plus jamais pouvoir être utilisé, nul part, ainsi que toutes les suites faillibles :
Si on applique RFC 7525 à la lettre, on trouve une config équivalente à la mienne (TLSv1.2 + ECHDE + AES only) et tous les serveurs du monde devrait être sur cette config (implémentation d’une RFC).
[^] # 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 05 janvier 2016 à 22:17.
Que les serveurs sont beaucoup plus facilement mettable à jour et par des personnes qui sont en plus sensées savoir de quoi il retourne.
Alors que dès que tu es côté client, tu as une inertie énorme, l’impossibilité de forcer les maj, et des personnes qui ne comprennent pas ce qui est en train de se jouer.
En plus, si tu prends la situation actuelle, tu vas laisser beaucoup moins de personnes sur le carreau à pousser du TLSv1.2 + AES + ECDHE sur ton serveur (dans 99.999% des cas ça va passer et les pouillèmes restants sont des trucs vraiment moisis dont on devrait se foutre), que de désactiver RC4 côté client (et empécher la connexion à tous les serveurs ne supportant que ça, ie un gros paquet de monde).
Il est bien plus facile que chaque admin sys fasse sa petite portion de chemin vers un monde TLSv1.2 + AES + ECHDE only, les un après les autres, que de devoir attendre que la majeure partie des serveurs supportent TLSv1.2 + AES + ECHDE pour pouvoir passer le client en TLSv1.2 + AES + ECHDE only.
D’autant plus que ça mettra au moins tes visiteurs à l’abri, quelque soit leur navigateur.
[^] # 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 05 janvier 2016 à 20:06.
Non, la condition nécessaire et suffisante se situe uniquement côté serveur pour un couple (client, serveur).
Si le serveur ne supporte aucune suite TLS faillible, alors même si le client en supporte une, il n’y a aucun downgrade attack de possible et la négociation TLS débouchera sur la sélection d’une suite fiable.
L’autre sens n’est pas possible, puisque pour un simple problème de compatibilité avec les autres serveurs, les clients doivent obligatoirement supporter des suites faillibles.
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.
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é (plus de downgrade attack possible puisque les suites faillibles ne sont pas supportées par le client).
[^] # 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.
Même si tu n’as pas d’autre sous-domaine…
Tu peux te retrouver avec des problèmes avec des CDN et des certificats wildcard déployés un peu trop à l’arrache qui pourrait être aussi valide pour ton domaine et qui pointe sur ton adresse IP, mais avec des paramètres TLS négociés bien plus faibles et un cross-accès à une resource critique… :D
[^] # 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.
Ils souffrent de la même erreur que Let’s Encrypt : s’asseoir sur tout le reste de la stack X.509/TLS et se contenter de tenir compte uniquement du certificat…
https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0000.html
[^] # 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 05 janvier 2016 à 15:04.
Après, tu peux être un peu moins extrémiste, comme activer TLSv1.0 et TLSv1.1 (faillible à POODLE mais mitigation possible (désactiver Javascript)) ou AES non PFS (faillible au cassage de ta clef dans XX années, mais les données récoltées seront obsolètes pour la plupart).
C’est surtout RC4 (cassé par la NSA en temps réel), 3DES (trop faible et dans la zone rouge), les suites EXPORT et SSLv3 qui sont à désactiver puisque des attaques existent déjà pour eux.
En gros tout ce qui a du rouge ou du noir ici.
Le reste est globalement (gris) à très certainement (vert et bleu) fiable.
[^] # 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 05 janvier 2016 à 14:49.
C’est exactement ça. La sécurité de TLS n’est garantie que si tu ne publies aucune suite faillible côté serveur, sinon un downgrade attack peut forcer le navigateur à utiliser une suite faillible qu’il supporterait lui-aussi.
Avoir du PFS et du non PFS actif côté serveur n’est fiable que si le navigateur en face ne supporte que PFS.
Avoir du PFS et du non PFS actif côté client n’est fiable que si le serveur en face ne supporte que PFS.
Donc avoir PFS et non PFS en même temps, côté client ou serveur, c’est s’exposer soi-même à un downgrade dans le cas du navigateur, et exposer l’ensemble de ses clients supportant uniquement du non PFS ou les 2 dans le cas du serveur.
La seule config qui referme l’ensemble des failles existantes et des downgrade attack possibles est donc : https://tls.imirhil.fr/https/imirhil.fr
Ç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…)…
[^] # 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 05 janvier 2016 à 14:23.
En fait on a un vrai problème avec TLS parce que la dépendance est double :
Du coup, la seule stratégie viable est de migrer serveur et client à la fois, vers les mêmes suites de chiffrement, en même temps. Autant dire que c’est infaisable…
Et qu’on se traîne une longue traîne de trucs totalement moisi, à la fois côté serveur mais aussi côté client. Exposant à des downgrade attack l’ensemble du monde, y compris ceux à jours.
Au motif qu’on ne peut décemment pas mettre à la porte les utilisateurs de Windows XP ou IE 8…
[^] # 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é à 4. Dernière modification le 05 janvier 2016 à 14:08.
Oui, c’est même là-dessus qu’est basé la faille FREAK.
Les outils pour ce MitM sont dispos ici.
À l’heure actuelle, c’est uniquement le downgrade vers *-EXPORT qui est utilisé, vu que c’est uniquement les tailles de clefs très faibles associées qui permettent la 2nde partie de l’attaque (le cassage de la clef en temps réel).
On peut par contre imaginer le même principe utilisé à l’échelle de la NSA, capable de casser RC4 en temps réel.
Et ça devrait bientôt être le cas de 3DES qui n’a que 112 bits de sécurité théorique (et encore moins en pratique puisqu’il n’utilise que des tailles de blocs de 64 bits) et donc déjà largement dans la zone jaune du « ça commence à puer franchement les gars ».