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 :-)
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
Thomas Pornin
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
According to Kevin Denis <kevin@alinto.comNOSPAM>:
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.
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
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 :-)
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 :
slrnja2s1b.v4n.kevin@slackwall.local.tux...
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 :-)
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 :-)
