Je suis même étonné que cette attaque ne sort que maintenant.
Pareil.
en fait, je me demande où est la "nouveauté" : par design (partie non authetifiée, dont l'intégrité sur qui cause n'est pas testée, donc il modifie tout ce qu'il veut), un MITM peut choisir le protocole à utiliser en refusant les protocoles "trop sécurisés" et c'est le client qui passe de lui-même en une version plus faible.
Le problème vient donc "juste" que SSLv3 est plus ou moins (il faut du temps quand même) troué est qu'il peut toujours être utilisé (il est accepté autant côté client que serveur), et donc ce problème apparait automatiquement (par design) dès qu'on a su que SSLv3 avait un problème.
La nouveauté est-elle que quelqu'un a regardait comment fonctionnait la phase de négociation du protocole et s'en rendu compte que n'importe quel MITM peut choisir le protocole utilisé? C'est gros (car c'est assez basique), sutout qu'on aura alors exactement le même problème quand on aura TLSv2.0 et que TLSv1.x sera troué : qu'est-ce qui est prévu pour ne pas avoir le même problème plus tard? On redécouvrira cette faille de la négociation à ce moment-la (est-ce que TLSv1.3 a un mécanisme pour détecter que c'était pas le protocole qui été préféré par le client)?
Ou alors, j'ai loupé un passage du problème, je n'arrive pas à comprendre. Quelqu'un pour expliquer en quoi ça ne fait pas partie du design de l'initialisation HTTPS qu'un MITM puisse décider quel protocole utiliser (quel mécanisme est mis en oeuvre pour sécuriser la liste des protocoles supportés qui est envoyée au serveur, et qui est ici cassé)?
[^] # Re: Quelques ressources supplémentaires sur le sujet
Posté par Zenitram (site web personnel) . En réponse à la dépêche CVE-2014-3566 — Vulnérabilité POODLE. Évalué à 2.
Pareil.
en fait, je me demande où est la "nouveauté" : par design (partie non authetifiée, dont l'intégrité sur qui cause n'est pas testée, donc il modifie tout ce qu'il veut), un MITM peut choisir le protocole à utiliser en refusant les protocoles "trop sécurisés" et c'est le client qui passe de lui-même en une version plus faible.
Le problème vient donc "juste" que SSLv3 est plus ou moins (il faut du temps quand même) troué est qu'il peut toujours être utilisé (il est accepté autant côté client que serveur), et donc ce problème apparait automatiquement (par design) dès qu'on a su que SSLv3 avait un problème.
La nouveauté est-elle que quelqu'un a regardait comment fonctionnait la phase de négociation du protocole et s'en rendu compte que n'importe quel MITM peut choisir le protocole utilisé? C'est gros (car c'est assez basique), sutout qu'on aura alors exactement le même problème quand on aura TLSv2.0 et que TLSv1.x sera troué : qu'est-ce qui est prévu pour ne pas avoir le même problème plus tard? On redécouvrira cette faille de la négociation à ce moment-la (est-ce que TLSv1.3 a un mécanisme pour détecter que c'était pas le protocole qui été préféré par le client)?
Ou alors, j'ai loupé un passage du problème, je n'arrive pas à comprendre. Quelqu'un pour expliquer en quoi ça ne fait pas partie du design de l'initialisation HTTPS qu'un MITM puisse décider quel protocole utiliser (quel mécanisme est mis en oeuvre pour sécuriser la liste des protocoles supportés qui est envoyée au serveur, et qui est ici cassé)?