Négociation initiale d'une session TLS: abaisser la sécurité

Le
Kevin Denis
Bonjour,

Une négociation SSL/TLS (comme https) démarre par une négociation ou
le client et le serveur se mettent d'accord sur les algorythme à
utiliser.
Si je trace une session TCP d'unc lient chrome vers https://xxx
je constate _en clair_ que le client propose 36 Cipher suites,
comme par exemple: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA.
Le serveur répond, toujours en clair, qu'il choisit
TLS_RSA_WITH_AES_256_CBC_SHA, puis la suite se fait en chiffré.

Savez vous s'il est possible d'intervenir sur le début de cette
négociation pour remplacer les 36 propositions du client par une
seule afin de pousser le serveur à la choisir?
L'idée étant de forcer le client et le serveur à utiliser une
cipher suite "faible" pour permettre un cassage de session plus
aisé par la suite.

La deuxième question étant: quels sont les cipher suite "faible" et
sont-ils encore acceptés par les serveurs et les clients?

Merci
--
Kevin, et désolé pour casser l'uptime de silence de plusieurs mois :-)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Thomas Pornin
Le #23890631
According to Kevin Denis
Savez vous s'il est possible d'intervenir sur le début de cette
négociation pour remplacer les 36 propositions du client par une
seule afin de pousser le serveur à la choisir?



Globalement, non. À la fin du "handshake", mais avant d'échanger des
données, client et serveur s'échangent des messages de contrôle
"Finished", couverts par le chiffrement et contrôle d'intégrité, et le
contenu des Finished est calculé via un hash sur les messages
précédents, _incluant_ les messages initiaux qui contiennent la liste
des cipher suites. Un attaquant ne peut donc pas modifier cette liste,
sauf s'il arrive à forcer l'utilisation d'une cipher suite tellement
faible qu'il peut la casser totalement dans la fraction de seconde qui
suit, et ainsi modifier les messages "Finished" (et si le client et le
serveur acceptent d'utiliser une cipher suite aussi faible que ça, ils
n'ont que ce qu'ils méritent).

Dans SSLv2, on pouvait faire ce genre de truandage, et c'était un
problème.


La deuxième question étant: quels sont les cipher suite "faible" et
sont-ils encore acceptés par les serveurs et les clients?



Les cipher suites "export" ont tendance à utiliser des clés symétriques
de 40 bits, ce qui est moult faibles. Je ne crois pas que beaucoup de
monde s'en serve actuellement ; elles étaient justifiées par les
lois d'import/export des USA d'avant l'an 2000. Ces cipher suites ne
sont pas activées par défaut dans les navigateurs Web usuels.


--Thomas Pornin
Philippe
Le #23980021
Généralement, les serveurs sont configurés pour ne plus accepter ni le SSL
V2 et ni les algorithmes faibles.
Les seuls cas où ce n'est pas vrai, c'est lorsqu'ils sont mal administrés ou
dans des pays où l'utilisation d'algorithmes forts (ou plutôt normaux) est
interdite.

"Kevin Denis" a écrit dans le message de groupe de discussion :


Bonjour,

Une négociation SSL/TLS (comme https) démarre par une négociation ou
le client et le serveur se mettent d'accord sur les algorythme à
utiliser.
Si je trace une session TCP d'unc lient chrome vers https://xxx
je constate _en clair_ que le client propose 36 Cipher suites,
comme par exemple: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA.
Le serveur répond, toujours en clair, qu'il choisit
TLS_RSA_WITH_AES_256_CBC_SHA, puis la suite se fait en chiffré.

Savez vous s'il est possible d'intervenir sur le début de cette
négociation pour remplacer les 36 propositions du client par une
seule afin de pousser le serveur à la choisir?
L'idée étant de forcer le client et le serveur à utiliser une
cipher suite "faible" pour permettre un cassage de session plus
aisé par la suite.

La deuxième question étant: quels sont les cipher suite "faible" et
sont-ils encore acceptés par les serveurs et les clients?

Merci
--
Kevin, et désolé pour casser l'uptime de silence de plusieurs mois :-)
Publicité
Poster une réponse
Anonyme