Auteur Sujet: Découverte d'une faille dans le protocole SSL 3.0  (Lu 3588 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Découverte d'une faille dans le protocole SSL 3.0
« le: 15 octobre 2014 à 15:55:43 »
This POODLE bites: exploiting the SSL 3.0 fallback

Posted: Tuesday, October 14, 2014

Today we are publishing details of a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker. I discovered this issue in collaboration with Thai Duong and Krzysztof Kotowicz (also Googlers).

SSL 3.0 is nearly 15 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue.

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

Google Chrome and our servers have supported TLS_FALLBACK_SCSV since February and thus we have good evidence that it can be used without compatibility problems. Additionally, Google Chrome will begin testing changes today that disable the fallback to SSL 3.0. This change will break some sites and those sites will need to be updated quickly.

In the coming months, we hope to remove support for SSL 3.0 completely from our client products.

Thank you to all the people who helped review and discuss responses to this issue.


https://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting-ssl-30.html

COMMENTAIRE

SSL est un machin vieux et obsolète qu'on aurait dû supprimer il y a longtemps; IE 6 nous met dans le caca, encore une fois.

corrector

  • Invité
IE 6
« Réponse #1 le: 18 octobre 2014 à 05:36:48 »
Concernant la disparition de IE 6 :

https://www.modern.ie/en-us/ie6countdown
« Modifié: 06 novembre 2014 à 23:11:04 par corrector »

corrector

  • Invité
Découverte d'une faille dans le protocole SSL 3.0
« Réponse #2 le: 20 octobre 2014 à 00:20:31 »
Est-ce que ça intéresse quelqu'un si j'essaie d'expliquer en détail en quoi consiste la faille?

tivoli

  • Toulouse (31)
  • Abonné Bbox fibre
  • *
  • Messages: 1 944
  • Toulouse (31)
Découverte d'une faille dans le protocole SSL 3.0
« Réponse #3 le: 20 octobre 2014 à 07:14:05 »
Toujours :-)

vivien

  • Administrateur
  • *
  • Messages: 47 087
    • Twitter LaFibre.info
Découverte d'une faille dans le protocole SSL 3.0
« Réponse #4 le: 20 octobre 2014 à 07:56:19 »
Ce qui est marrant, c'est que j'ai désactivé SSL v3.0, quelques semaines avant :

Concrètement voici ce que cela change :
- SSLv2 : interdit (aucun changement)
- SSLv3 : autorisé avant et interdit maintenant
- TLSv1 : autorisé (aucun changement)
- TLSv1.1 : autorisé (aucun changement)
- TLSv1.2 : autorisé (aucun changement)

Il est en effet conseillé de désactiver SSLv3.
L'effet de bord, c'est la perte de Internet Explorer 6 (et peut être Internet Explorer 7, je n'ai pas testé).
L'affichage ne se fait même pas en mode dégradé avec un message d’alerte mais la personne a un message "Internet Explorer ne peut pas afficher cette page web"

Internet Explorer 8, la dernière version d'IE sous Windows XP est toujours supporté pleinement.

corrector

  • Invité
Découverte d'une faille dans le protocole SSL 3.0
« Réponse #5 le: 06 novembre 2014 à 04:12:50 »
C'est un peu technique, je vais essayer de décrire en gros le principe de l'attaque.

Pour fixer le contexte, le problème concerne la partie symétrique du protocole, qui vient après la phase d'initialisation à base de crypto asymétrique; la phase asymétrique a permis d'établir un secret partagé qui permet de sécuriser des communications symétriques.

La couche de chiffrement (que ça soit de SSL, de TLS, de SSH...) prend des messages de taille raisonnable de la couche applicative et les traite afin de fournir deux garanties :
- secret du contenu (*)
- intégrité

(*) Le secret concerne la valeur de chaque octet du message, pas la longueur. SSL ne promet jamais de cacher la longueur d'un message. Ce n'est pas un objectif réaliste dans ce contexte. (Je devrais peut être développer ça ailleurs.)

Ces garanties sont symétriques, elles concernent les deux directions.

Chaque paquet de données à envoyer est donc chiffré avec une clé de chiffrement, et un code de détection d'erreur ("MAC") est utilisé pour l'intégrité. Ce code est basé sur un hachage cryptographique et une clé secrète par le procédé du HMAC.

Le contexte d'utilisation de SSL, comme de la plupart des chiffrements sur Internet, est basé sur l'hypothèse maximaliste d'un adversaire
- capable d'intercepter et de modifier tout message
- qui peut forcer n'importe quelle partie à envoyer en chiffré un message choisi
- qui peut mélanger un message choisi à des secrets

Par exemple, l'adversaire peut poliment demander à une partie d'envoyer M1 S1 M2 S2 M3 S3 ... à l'autre partie, où l'adversaire choisit M1 M2 ... et S1 S2 ... sont des secrets que l'adversaire veut découvrir.

Donc pour les couches supérieures, c'est très confortable; même un usage Web est possible, et le Web (*) est un des pires contextes de pour la sécurité : un site peut utiliser des éléments venant d'un autre site, ce qui rend la sémantique et les propriétés de sécurité d'un site Web assez "space".

(*) le Web c'est ce truc avec des navigateurs qui communiquent par HTTP, qui décodent le HTML, qui gèrent les IMG et les FORM, qui ont des FRAME et des IFRAME, qui gèrent les cookies HTTP, qui exécutent le JS, et qui permettent d'ouvrir plusieurs onglets simultanèment; ce n'est pas wget ou curl; ce n'est pas non plus SOAP.

Sur le Web, je peux demander à un client SSL (un navigateur) d'envoyer à un serveur TLS (un serveur Web Serv) ceci :

GET /M1 HTTP/1.1
Host: Serv
...
S1


Ce que contient M1 et qu'il existe réellement sur le serveur Web n'a aucune importance puisque la réponse n'a pas d'intérêt.

S1 est l'ensemble de en-têtes HTTP que l'adversaire n'est pas censé pouvoir deviner, notamment les cookies.

Remarquez que je peux demander autant de fois que je veux à un navigateur de faire ça, il suffit d'inclure des IMG sur un site tiers quelconque (sauf si l'utilisateur ne se connecte jamais à un site non sécurisé en même temps). Jamais le navigateur ne va afficher une alarme, et jamais il ne va activer de contre-mesures.

SSL est supposé être assez robuste pour gérer cela.

corrector

  • Invité
Découverte d'une faille dans le protocole SSL 3.0
« Réponse #6 le: 06 novembre 2014 à 17:15:00 »
(...)

Il y a deux types de chiffrement utilisables dans SSL et TLS :
- par octet (on dit par flot), comme RC4.
- par bloc (p.ex. 16 octets d'un coup) comme DES, 3DES, et AES.

L'attaque POODLE ne concerne que les chiffrements par bloc dans SSL.

Les messages envoyés par la couche applicative sont rarement garantis d'avoir une taille en multiple d'un bloc, donc il faut spécifier une méthode de rembourrage afin d'arriver à un tel multiple. Différents protocoles crypto utilisent différents rembourrages; dans SSL le rembourrage est ajouté à la fin de telle sorte que

M || MAC || fill

forme un message de taille multiple d'un bloc.

notations :
M est le message
MAC est le code d'intégrité
fill est le rembourrage
|| est la concaténation