RC4 est considéré comme un algorithme peu fiable. Le WEP a été
cassé à cause de lui.
Ceci dit, je constate que des sites web HTTPS continuent d'utiliser
RC4 comme algorithme symétrique pour échanger des données.
Par exemple:
$ openssl s_client -connect XXXXXXXXXXXXXXXXXXX.fr:443
(...Snip...)
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 0007308CF260412FFC7109863864F2E9FF401E0C585858584B48A75600004928
Session-ID-ctx:
Master-Key: 98C43659E4BF4B292B39B6ECF56FD566C6061B4CEC0ED53EE0AA1E5C05E025E1F63952F7B57E8ABE14CC09A772A9EE08
Key-Arg : None
Start Time: 1263052630
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
RC4-MD5 en 2010, ça ne semble pas vraiment sérieux? C'est le site d'une
banque.
Ceci dit, RC4 a été cassé de deux raisons, il me semble:
1- on est capable de distinguer un flux chiffré par RC4 d'un flux aléatoire.
Ceci nous concerne peu.
2- Chaque début de connexion laisse fuiter un peu d'information
C'est ce qui permet de casser le WEP: l'ouverture d'un très grand nombre
de connexions par le rejeu de paquets ARP. Chaque paquet laisse fuiter
de l'information et permet ainsi de reconstituer la clé WEP.
Est-ce applicable à une connexion HTTPs et comment?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Kevin Denis
Le 09-01-2010, Kevin Denis a écrit :
Est-ce applicable à une connexion HTTPs et comment?
Je me réponds à moi même: http://www.rsa.com/rsalabs/node.asp?id 09 Le point (2) répond explicitement à cette question: "There are two reasons why the new attacks do not apply to RC4-based SSL." -- Kevin
Le 09-01-2010, Kevin Denis <kevin@nowhere.invalid> a écrit :
Est-ce applicable à une connexion HTTPs et comment?
Je me réponds à moi même:
http://www.rsa.com/rsalabs/node.asp?id 09
Le point (2) répond explicitement à cette question:
"There are two reasons why the new attacks do not apply to RC4-based SSL."
--
Kevin
Est-ce applicable à une connexion HTTPs et comment?
Je me réponds à moi même: http://www.rsa.com/rsalabs/node.asp?id 09 Le point (2) répond explicitement à cette question: "There are two reasons why the new attacks do not apply to RC4-based SSL." -- Kevin
Jean-Marc Desperrier
Kevin Denis wrote:
$ openssl s_client -connect XXXXXXXXXXXXXXXXXXX.fr:443 (...Snip...) [...] RC4-MD5 en 2010, ça ne semble pas vraiment sérieux? C'est le site d'une banque.
Ca parait quand même peu sérieux dans le sens où openssl s_client est censé utiliser le chiffrement le plus fort disponible.
Globalement, on recommande de ne plus autoriser le MD5, mais bon, la manière dont il est utilisé dans le SSL est toujours sure, et n'est pas concernée par les attaques connues.
Cependant entre laisser passer le RC4-MD5, et interdire d'utiliser quoi que ce soit de plus sûr, il y a une marge, d'autant plus que pour arriver à ce résultat, il faut soit utiliser un serveur antédiluvien, soit volontairement désactiver les algorithmes plus forts.
Kevin Denis wrote:
$ openssl s_client -connect XXXXXXXXXXXXXXXXXXX.fr:443
(...Snip...)
[...]
RC4-MD5 en 2010, ça ne semble pas vraiment sérieux? C'est le site d'une
banque.
Ca parait quand même peu sérieux dans le sens où openssl s_client est
censé utiliser le chiffrement le plus fort disponible.
Globalement, on recommande de ne plus autoriser le MD5, mais bon, la
manière dont il est utilisé dans le SSL est toujours sure, et n'est pas
concernée par les attaques connues.
Cependant entre laisser passer le RC4-MD5, et interdire d'utiliser quoi
que ce soit de plus sûr, il y a une marge, d'autant plus que pour
arriver à ce résultat, il faut soit utiliser un serveur antédiluvien,
soit volontairement désactiver les algorithmes plus forts.
$ openssl s_client -connect XXXXXXXXXXXXXXXXXXX.fr:443 (...Snip...) [...] RC4-MD5 en 2010, ça ne semble pas vraiment sérieux? C'est le site d'une banque.
Ca parait quand même peu sérieux dans le sens où openssl s_client est censé utiliser le chiffrement le plus fort disponible.
Globalement, on recommande de ne plus autoriser le MD5, mais bon, la manière dont il est utilisé dans le SSL est toujours sure, et n'est pas concernée par les attaques connues.
Cependant entre laisser passer le RC4-MD5, et interdire d'utiliser quoi que ce soit de plus sûr, il y a une marge, d'autant plus que pour arriver à ce résultat, il faut soit utiliser un serveur antédiluvien, soit volontairement désactiver les algorithmes plus forts.
Thomas Pornin
According to Jean-Marc Desperrier :
Ca parait quand même peu sérieux dans le sens où openssl s_client est censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose. En SSL, le client dit ce qu'il sait faire, mais c'est le serveur qui choisit les algorithmes qui vont effectivement être utilisés. Si un client ne veut vraiment pas faire de RC4+MD5, alors son seul recours est de ne pas dire au serveur qu'il sait gérer ça.
--Thomas Pornin
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
Ca parait quand même peu sérieux dans le sens où openssl s_client est
censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose. En SSL, le client dit ce qu'il
sait faire, mais c'est le serveur qui choisit les algorithmes qui vont
effectivement être utilisés. Si un client ne veut vraiment pas faire de
RC4+MD5, alors son seul recours est de ne pas dire au serveur qu'il sait
gérer ça.
Ca parait quand même peu sérieux dans le sens où openssl s_client est censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose. En SSL, le client dit ce qu'il sait faire, mais c'est le serveur qui choisit les algorithmes qui vont effectivement être utilisés. Si un client ne veut vraiment pas faire de RC4+MD5, alors son seul recours est de ne pas dire au serveur qu'il sait gérer ça.
--Thomas Pornin
Jean-Marc Desperrier
Thomas Pornin wrote:
According to Jean-Marc Desperrier:
> Ca parait quand même peu sérieux dans le sens où openssl s_client est > censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose.
Oui, je n'ai pas été très précis.
Ce que je voulais dire est que sachant que le client est openssl et avec les paramètres indiqués, il n'y a pas de doute qu'il a proposé au serveur tout une palanquée d'algo plus solides que RC4-MD5 et que c'est bien la responsabilité du serveur d'avoir choisi parmi ceux là un algorithme aussi faible, il n'y a pas été contraint par un client qui lui aurait proposé uniquement des algo faibles.
Thomas Pornin wrote:
According to Jean-Marc Desperrier<jmdesp@alussinan.org>:
> Ca parait quand même peu sérieux dans le sens où openssl s_client est
> censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose.
Oui, je n'ai pas été très précis.
Ce que je voulais dire est que sachant que le client est openssl et avec
les paramètres indiqués, il n'y a pas de doute qu'il a proposé au
serveur tout une palanquée d'algo plus solides que RC4-MD5 et que c'est
bien la responsabilité du serveur d'avoir choisi parmi ceux là un
algorithme aussi faible, il n'y a pas été contraint par un client qui
lui aurait proposé uniquement des algo faibles.
> Ca parait quand même peu sérieux dans le sens où openssl s_client est > censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose.
Oui, je n'ai pas été très précis.
Ce que je voulais dire est que sachant que le client est openssl et avec les paramètres indiqués, il n'y a pas de doute qu'il a proposé au serveur tout une palanquée d'algo plus solides que RC4-MD5 et que c'est bien la responsabilité du serveur d'avoir choisi parmi ceux là un algorithme aussi faible, il n'y a pas été contraint par un client qui lui aurait proposé uniquement des algo faibles.
Kevin Denis
Le 14-01-2010, Jean-Marc Desperrier a écrit :
> Ca parait quand même peu sérieux dans le sens où openssl s_client est > censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose.
Oui, je n'ai pas été très précis.
Ce que je voulais dire est que sachant que le client est openssl et avec les paramètres indiqués,
Comportement identique avec firefox.
il n'y a pas de doute qu'il a proposé au serveur tout une palanquée d'algo plus solides que RC4-MD5 et que c'est bien la responsabilité du serveur d'avoir choisi parmi ceux là un algorithme aussi faible, il n'y a pas été contraint par un client qui lui aurait proposé uniquement des algo faibles.
Mais est-ce réellement un algo faible? Le lien que j'ai fourni semble montrer que non. Donc je n'ai pas forcément à cacher l'URL. https://www.labanquepostale.fr
RC4 laisse donc fuiter un peu d'informations sur la clé ayant servi à générer les IVs. Sur un flux HTTPS, de quelle clé parle t'on? De la clé générée aléatoirement suite à l'échange RSA. La connaissance de cette clé permet de déchiffrer un seul flux. Ensuite, comment générer un très grand nombre d'IVs? Autant en WEP c'est possible en envoyant un très grand nombre de requêtes ARP, autant en HTTPS, je ne vois pas.
Mais j'ai peut-être mal compris l'enchainement des étapes, et RC4 est peut-être à risque?
En jouant avec différentes options d'openssl (-cipher, -serverpref, -no_tls1 etc..) je peux négocier en RC4-SHA mais pas au dela. Je n'ai peut-être pas testé toutes les options mais je ne suis pas parvenu à dialoguer en AES, quoi qu'il en soit. -- Kevin
Le 14-01-2010, Jean-Marc Desperrier <jmdesp@alussinan.org> a écrit :
> Ca parait quand même peu sérieux dans le sens où openssl s_client est
> censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose.
Oui, je n'ai pas été très précis.
Ce que je voulais dire est que sachant que le client est openssl et avec
les paramètres indiqués,
Comportement identique avec firefox.
il n'y a pas de doute qu'il a proposé au
serveur tout une palanquée d'algo plus solides que RC4-MD5 et que c'est
bien la responsabilité du serveur d'avoir choisi parmi ceux là un
algorithme aussi faible, il n'y a pas été contraint par un client qui
lui aurait proposé uniquement des algo faibles.
Mais est-ce réellement un algo faible? Le lien que j'ai fourni semble
montrer que non. Donc je n'ai pas forcément à cacher l'URL.
https://www.labanquepostale.fr
RC4 laisse donc fuiter un peu d'informations sur la clé ayant
servi à générer les IVs.
Sur un flux HTTPS, de quelle clé parle t'on? De la clé générée
aléatoirement suite à l'échange RSA. La connaissance de cette clé
permet de déchiffrer un seul flux. Ensuite, comment générer un
très grand nombre d'IVs? Autant en WEP c'est possible en envoyant un
très grand nombre de requêtes ARP, autant en HTTPS, je ne vois pas.
Mais j'ai peut-être mal compris l'enchainement des étapes, et RC4
est peut-être à risque?
En jouant avec différentes options d'openssl (-cipher, -serverpref,
-no_tls1 etc..) je peux négocier en RC4-SHA mais pas au dela. Je
n'ai peut-être pas testé toutes les options mais je ne suis pas
parvenu à dialoguer en AES, quoi qu'il en soit.
--
Kevin
> Ca parait quand même peu sérieux dans le sens où openssl s_client est > censé utiliser le chiffrement le plus fort disponible.
Le client propose, le serveur dispose.
Oui, je n'ai pas été très précis.
Ce que je voulais dire est que sachant que le client est openssl et avec les paramètres indiqués,
Comportement identique avec firefox.
il n'y a pas de doute qu'il a proposé au serveur tout une palanquée d'algo plus solides que RC4-MD5 et que c'est bien la responsabilité du serveur d'avoir choisi parmi ceux là un algorithme aussi faible, il n'y a pas été contraint par un client qui lui aurait proposé uniquement des algo faibles.
Mais est-ce réellement un algo faible? Le lien que j'ai fourni semble montrer que non. Donc je n'ai pas forcément à cacher l'URL. https://www.labanquepostale.fr
RC4 laisse donc fuiter un peu d'informations sur la clé ayant servi à générer les IVs. Sur un flux HTTPS, de quelle clé parle t'on? De la clé générée aléatoirement suite à l'échange RSA. La connaissance de cette clé permet de déchiffrer un seul flux. Ensuite, comment générer un très grand nombre d'IVs? Autant en WEP c'est possible en envoyant un très grand nombre de requêtes ARP, autant en HTTPS, je ne vois pas.
Mais j'ai peut-être mal compris l'enchainement des étapes, et RC4 est peut-être à risque?
En jouant avec différentes options d'openssl (-cipher, -serverpref, -no_tls1 etc..) je peux négocier en RC4-SHA mais pas au dela. Je n'ai peut-être pas testé toutes les options mais je ne suis pas parvenu à dialoguer en AES, quoi qu'il en soit. -- Kevin
Thomas Pornin
According to Kevin Denis :
Mais est-ce réellement un algo faible?
Ça dépend de ce qu'on appelle "faible".
En gros, il y a trois classes d'algorithmes :
1. Ceux pour lesquels un attaquant réel peut ou a déjà monté une attaque, en conditions pratique, aboutissant à une brèche de la cible de sécurité sous-jacente. Exemples : RSA avec une clé de 320 bits, et le chiffrement intégré dans le format Zip (avant qu'ils ne se mettent à l'AES).
2. Ceux pour lesquels la recherche (académique) n'a pas pu exhiber la moinde faiblesse théorique. Exemples : AES, RSA avec une clé de 2048 bits.
3. Les autres. Exemples : SHA-1, RC4.
Dans le monde de la recherche, on applique le terme de "faible" aux catégorie 1 et 3. Du point de vue de l'attaquant, "faible", ça veut dire "ça vaut le coup que j'attaque le système", donc c'est la catégorie 1 seulement. RC4 et HMAC-avec-MD5, i.e. les deux morceaux dont on parle ici dans le cadre de SSL, sont dans la catégorie 3. C'est donc faible, ou pas, suivant qui parle.
Du point de vue de la banque, la cible est double : elle veut qu'on ne l'attaque pas, et elle veut aussi avoir un "risque notoirement faible". Risque notoirement faible, ça veut dire que le banquier veut pouvoir dormir la nuit, ou, d'un point de vue plus business, le banquier veut pouvoir négocier une assurance avec un taux suffisamment faible. Savoir si des algorithmes de "catégorie 3" font l'affaire est une question de jugement de la part du banquier, et il n'y a pas de règle absolue en la matière. Si le banquier demande son avis à un universitaire, ce dernier lui dira : "catégorie 3 c'est pas beau", parce que dans le milieu universitaire c'est comme ça qu'on travaille. Mais le banquier n'est pas un universitaire...
Du point de vue du client, c'est encore une autre affaire. Le client confie ses sous à la banque. Donc le client a envie que le banquier soit compétent en matière de sécurité, ou au moins "responsable" (au sens de : en cas de problème, c'est le banquier qui paye). L'usage par le banquier d'algorithmes de 3ème catégorie n'est pas un signe absolu d'incompétence, mais face à un client un peu sourcilleux et "de fibre universitaire", c'est tout de même un mauvais signal. Mais, là encore, c'est à chaque client de se faire son avis.
--Thomas Pornin
According to Kevin Denis <kevin@alinto.comNOSPAM>:
Mais est-ce réellement un algo faible?
Ça dépend de ce qu'on appelle "faible".
En gros, il y a trois classes d'algorithmes :
1. Ceux pour lesquels un attaquant réel peut ou a déjà monté une attaque,
en conditions pratique, aboutissant à une brèche de la cible de sécurité
sous-jacente. Exemples : RSA avec une clé de 320 bits, et le chiffrement
intégré dans le format Zip (avant qu'ils ne se mettent à l'AES).
2. Ceux pour lesquels la recherche (académique) n'a pas pu exhiber la
moinde faiblesse théorique. Exemples : AES, RSA avec une clé de 2048 bits.
3. Les autres. Exemples : SHA-1, RC4.
Dans le monde de la recherche, on applique le terme de "faible" aux
catégorie 1 et 3. Du point de vue de l'attaquant, "faible", ça veut dire
"ça vaut le coup que j'attaque le système", donc c'est la catégorie 1
seulement. RC4 et HMAC-avec-MD5, i.e. les deux morceaux dont on parle
ici dans le cadre de SSL, sont dans la catégorie 3. C'est donc faible,
ou pas, suivant qui parle.
Du point de vue de la banque, la cible est double : elle veut qu'on ne
l'attaque pas, et elle veut aussi avoir un "risque notoirement faible".
Risque notoirement faible, ça veut dire que le banquier veut pouvoir
dormir la nuit, ou, d'un point de vue plus business, le banquier veut
pouvoir négocier une assurance avec un taux suffisamment faible. Savoir
si des algorithmes de "catégorie 3" font l'affaire est une question de
jugement de la part du banquier, et il n'y a pas de règle absolue en la
matière. Si le banquier demande son avis à un universitaire, ce dernier
lui dira : "catégorie 3 c'est pas beau", parce que dans le milieu
universitaire c'est comme ça qu'on travaille. Mais le banquier n'est pas
un universitaire...
Du point de vue du client, c'est encore une autre affaire. Le client
confie ses sous à la banque. Donc le client a envie que le banquier soit
compétent en matière de sécurité, ou au moins "responsable" (au sens de :
en cas de problème, c'est le banquier qui paye). L'usage par le banquier
d'algorithmes de 3ème catégorie n'est pas un signe absolu
d'incompétence, mais face à un client un peu sourcilleux et "de fibre
universitaire", c'est tout de même un mauvais signal. Mais, là encore,
c'est à chaque client de se faire son avis.
1. Ceux pour lesquels un attaquant réel peut ou a déjà monté une attaque, en conditions pratique, aboutissant à une brèche de la cible de sécurité sous-jacente. Exemples : RSA avec une clé de 320 bits, et le chiffrement intégré dans le format Zip (avant qu'ils ne se mettent à l'AES).
2. Ceux pour lesquels la recherche (académique) n'a pas pu exhiber la moinde faiblesse théorique. Exemples : AES, RSA avec une clé de 2048 bits.
3. Les autres. Exemples : SHA-1, RC4.
Dans le monde de la recherche, on applique le terme de "faible" aux catégorie 1 et 3. Du point de vue de l'attaquant, "faible", ça veut dire "ça vaut le coup que j'attaque le système", donc c'est la catégorie 1 seulement. RC4 et HMAC-avec-MD5, i.e. les deux morceaux dont on parle ici dans le cadre de SSL, sont dans la catégorie 3. C'est donc faible, ou pas, suivant qui parle.
Du point de vue de la banque, la cible est double : elle veut qu'on ne l'attaque pas, et elle veut aussi avoir un "risque notoirement faible". Risque notoirement faible, ça veut dire que le banquier veut pouvoir dormir la nuit, ou, d'un point de vue plus business, le banquier veut pouvoir négocier une assurance avec un taux suffisamment faible. Savoir si des algorithmes de "catégorie 3" font l'affaire est une question de jugement de la part du banquier, et il n'y a pas de règle absolue en la matière. Si le banquier demande son avis à un universitaire, ce dernier lui dira : "catégorie 3 c'est pas beau", parce que dans le milieu universitaire c'est comme ça qu'on travaille. Mais le banquier n'est pas un universitaire...
Du point de vue du client, c'est encore une autre affaire. Le client confie ses sous à la banque. Donc le client a envie que le banquier soit compétent en matière de sécurité, ou au moins "responsable" (au sens de : en cas de problème, c'est le banquier qui paye). L'usage par le banquier d'algorithmes de 3ème catégorie n'est pas un signe absolu d'incompétence, mais face à un client un peu sourcilleux et "de fibre universitaire", c'est tout de même un mauvais signal. Mais, là encore, c'est à chaque client de se faire son avis.
