Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l'accès chiffrés aux serveurs web. Il n'y a donc plus aucun site web qui est à l'abri d'une attaque man in the middle.
Faux.
La faille n'a pas été découverte. Comme expliqué plus loin, c'est connu depuis longtemps. La nouveauté, c'est qu'un vecteur d'attaque a été découvert, et un exploit fonctionnel a été developpé.
Concrètement, l'attaque consiste à injecter du texte connu dans une page web (via du JavaScript introduit dans une publicité vérolée par exemple). Après, il suffit d'écouter la conversion (il faut quand même une session de 30 minutes pour l'exploit actuel) pour découvrir la clef AES. L'exploit permet donc de déchiffrer la page mais aussi les cookies et donc de s'identifier sur le site visé.
Totalement faux. L'exploit ne récupère pas la clef AES (d'ailleurs cette clef change entre chaque session) mais permet de récupérer des morceaux de cleartext, un byte à la fois.
Le principe est le suivant : l'attaquant force la victime, via un JS introduit dans un flux non chiffré, à récupérer des éléments à des URLs précises, sur un site https (le simple fait d'inclure une image est suffisant). En utilisant des URL suffisamment longues et en introduisant des décalages, il est possible de deviner le dernier byte d'un bloc chiffré en AES-CBC.
Il est donc possible de deviner le cookie pour https://www.paypal.com d'une victime, bien que cette victime ne visite pas le site.
Il y a 3 manières de mitiger le problème :
Tout le monde passe en TLS 1.2. Ca va demander pas mal de temps de dev des deux côtés, vu que openssl ne supporte pas encore TLS1.2 et NSS non plus.
Les clients utilisent le workaround implémenté dans openssl, qui consiste à découper le premier paquet en deux. L'attaque n'est apparemment pas réalisable sur le deuxième paquet.
Les services sensibles sur https peuvent forcer la réécriture du cookie d'authentification à chaque accès, ou mieux, forcer la réécriture d'un cookie tampon contenant des valeurs aléatoires.
Si TLS était mieux conçu, il aurait suffit d'activer AES256-CTR par défaut comme en SSH.
# Précisions
Posté par Aris Adamantiadis (site web personnel) . En réponse à la dépêche Faille dans SSL 3.0 et TLS 1.0. Évalué à 10. Dernière modification le 25 septembre 2011 à 19:15.
Faux.
La faille n'a pas été découverte. Comme expliqué plus loin, c'est connu depuis longtemps. La nouveauté, c'est qu'un vecteur d'attaque a été découvert, et un exploit fonctionnel a été developpé.
Totalement faux. L'exploit ne récupère pas la clef AES (d'ailleurs cette clef change entre chaque session) mais permet de récupérer des morceaux de cleartext, un byte à la fois.
Le principe est le suivant : l'attaquant force la victime, via un JS introduit dans un flux non chiffré, à récupérer des éléments à des URLs précises, sur un site https (le simple fait d'inclure une image est suffisant). En utilisant des URL suffisamment longues et en introduisant des décalages, il est possible de deviner le dernier byte d'un bloc chiffré en AES-CBC.
Il est donc possible de deviner le cookie pour https://www.paypal.com d'une victime, bien que cette victime ne visite pas le site.
Il y a 3 manières de mitiger le problème :
Si TLS était mieux conçu, il aurait suffit d'activer AES256-CTR par défaut comme en SSH.