Quand SSLv3 a été jugé trop troué, il a été désactivé à ce moment-la (et pas avant).
Pas d’accord. La désactivation massive de SSL 3.0 date d’il y a quelques mois (c’est POODLE qui a donné le coup de pied au cul nécessaire), et ça fait bien plus longtemps que ça qu’on savait que SSL 3.0 avait trop de failles.
Firefox et Chrome ont désactivé SSL 3.0 après POODLE non pas parce que c’était la faille de trop, mais parce que c’est avec cette faille qu’ils se sont rendus compte qu’il y avait encore trop de serveurs dans la nature qui offraient sans sourciller du SSL 3.0.
Quel risque réel de downgrade avec TLS 1.0?
Faible a priori si client et serveur supportent le mécanisme anti-repli (mécanisme qui au passage n’aurait jamais du être nécessaire si serveurs et clients avaient respecté le protocole TLS, au lieu d’adopter le comportement du « ça passe pas en TLS n alors je me fous de la sécurité et je tente en TLS n−1, ah ben là ça passe c’est donc bien que ça devait être une erreur et pas une tentative d’attaque », mais c’est une autre histoire). Après, on n’est jamais à l’abri d’une erreur dans une implémentation (erreur à laquelle tu fermes complètement la porte en ne supportant pas le protocole plus faible en premier lieu).
Note, je ne suis pas en train de dire de ne pas supporter TLS 1.0 (même si idéalement il faudrait). Comme indiqué sur la page du wiki de Mozilla que j’ai cité par ailleurs, c’est à évaluer en fonction du public attendu.
ça c'est une autre histoire, mais pareil pourquoi désactiver alors que c'est peut-être le seul moyen et qu'il vaut mieux un peu de sécu que pas du tout?
J’aimerais vraiment que tu me trouves un client encore en service (même avec 0.00009% de part de marché) qui ne supporte rien de mieux que les suites EXPORT.
Et contrairement à d’autres technos déjà déconseillées mais contre lesquelles les attaques relèvent encore aujourd’hui de la spéculation (SHA-1 par exemple, on soupçonne fortement que créer des collisions est à la portée d’un adversaire de niveau étatique mais ça n’a pas encore été fait — de même que casser du RSA 1024 bits), il existe des attaques complètement réalistes (et à la portée de quiconque a un peu d’argent à dépenser sur Amazon EC2) contre les suites EXPORT.
Je n’ai pas d’objection à ce qu’on continue à supporter une technologie obsolète après avoir pesé les avantages et les inconvénients, si on estime qu’on peut encore avoir des clients qui en ont besoin.
Le problème, c’est de continuer à supporter une technologie obsolète sans avoir fait cette analyse, juste parce que cette technologie est activée par défaut. Il est à peu près certains que la plupart des administrateurs de sites web ne savaient même pas que leur logiciel serveur offrait par défaut des suites EXPORT (full disclosure : je ne le savais pas non plus).
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
Pas d’accord. La désactivation massive de SSL 3.0 date d’il y a quelques mois (c’est POODLE qui a donné le coup de pied au cul nécessaire), et ça fait bien plus longtemps que ça qu’on savait que SSL 3.0 avait trop de failles.
Firefox et Chrome ont désactivé SSL 3.0 après POODLE non pas parce que c’était la faille de trop, mais parce que c’est avec cette faille qu’ils se sont rendus compte qu’il y avait encore trop de serveurs dans la nature qui offraient sans sourciller du SSL 3.0.
Faible a priori si client et serveur supportent le mécanisme anti-repli (mécanisme qui au passage n’aurait jamais du être nécessaire si serveurs et clients avaient respecté le protocole TLS, au lieu d’adopter le comportement du « ça passe pas en TLS n alors je me fous de la sécurité et je tente en TLS n−1, ah ben là ça passe c’est donc bien que ça devait être une erreur et pas une tentative d’attaque », mais c’est une autre histoire). Après, on n’est jamais à l’abri d’une erreur dans une implémentation (erreur à laquelle tu fermes complètement la porte en ne supportant pas le protocole plus faible en premier lieu).
Note, je ne suis pas en train de dire de ne pas supporter TLS 1.0 (même si idéalement il faudrait). Comme indiqué sur la page du wiki de Mozilla que j’ai cité par ailleurs, c’est à évaluer en fonction du public attendu.
J’aimerais vraiment que tu me trouves un client encore en service (même avec 0.00009% de part de marché) qui ne supporte rien de mieux que les suites EXPORT.
Et contrairement à d’autres technos déjà déconseillées mais contre lesquelles les attaques relèvent encore aujourd’hui de la spéculation (SHA-1 par exemple, on soupçonne fortement que créer des collisions est à la portée d’un adversaire de niveau étatique mais ça n’a pas encore été fait — de même que casser du RSA 1024 bits), il existe des attaques complètement réalistes (et à la portée de quiconque a un peu d’argent à dépenser sur Amazon EC2) contre les suites EXPORT.
Je n’ai pas d’objection à ce qu’on continue à supporter une technologie obsolète après avoir pesé les avantages et les inconvénients, si on estime qu’on peut encore avoir des clients qui en ont besoin.
Le problème, c’est de continuer à supporter une technologie obsolète sans avoir fait cette analyse, juste parce que cette technologie est activée par défaut. Il est à peu près certains que la plupart des administrateurs de sites web ne savaient même pas que leur logiciel serveur offrait par défaut des suites EXPORT (full disclosure : je ne le savais pas non plus).