C’est exactement ça. La sécurité de TLS n’est garantie que si tu ne publies aucune suite faillible côté serveur, sinon un downgrade attack peut forcer le navigateur à utiliser une suite faillible qu’il supporterait lui-aussi.
Non. La sécurité de TLS est garantie pour un couple (client,serveur) seulement si l'une des deux conditions est valide:
- Le serveur ne supporte aucune suite TLS faillible
- Le client ne supporte aucune suite TLS faillible
C'est d'ailleurs la propriété ci-dessus que tu décris dans ton exemple avec PFS.
Je suis un peu ce que tu fais, et je sais pas pourquoi tu mets toute la faute sur les opérateurs de serveurs.
Les éditeurs de navigateurs sont au tout aussi responsables. Ça n'a pas de sens de parler de la "sécurité d'un domaine" (au moins en ce qui concerne la configuration des suites TLS), c'est le couple (client,serveur) qui est sécurisé ou qui ne l'est pas. Suivant ta nomenclature faudrait mettre un F à Chrome et Firefox aussi (car ils supportent du 3DES, RC4 et autres suites faillibles).
Après c'est l'éternelle triade confidentialité-intégrité-disponibilité. Difficile d'avoir les trois propriétés en même temps. Un opérateur de serveur peut améliorer la confidentialité et l'intégrité en n'activant que des suites TLS très sures, mais ça se fera au détriment de la disponibilité. Oui une banque française devrait avoir une configuration similaire à ton site (quoiqu'on peut discuter de l'utilité de PFS pour les opérations bancaires mais passons...). Pour un opérateur de service comme Google, ça revient à priver une partie de la planète de TLS.
Bref, pour conclure ça n'a pas de sens de dire que le serveur example.com n'est pas sécurisé car il supporte RC4 ou 3DES. Pour qu'il y ait un problème de sécurité, il faut aussi que le client supporte RC4.
[^] # Re: Let’s Encrypt
Posté par X345 . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
Non. La sécurité de TLS est garantie pour un couple (client,serveur) seulement si l'une des deux conditions est valide:
- Le serveur ne supporte aucune suite TLS faillible
- Le client ne supporte aucune suite TLS faillible
C'est d'ailleurs la propriété ci-dessus que tu décris dans ton exemple avec PFS.
Je suis un peu ce que tu fais, et je sais pas pourquoi tu mets toute la faute sur les opérateurs de serveurs.
Les éditeurs de navigateurs sont au tout aussi responsables. Ça n'a pas de sens de parler de la "sécurité d'un domaine" (au moins en ce qui concerne la configuration des suites TLS), c'est le couple (client,serveur) qui est sécurisé ou qui ne l'est pas. Suivant ta nomenclature faudrait mettre un F à Chrome et Firefox aussi (car ils supportent du 3DES, RC4 et autres suites faillibles).
Après c'est l'éternelle triade confidentialité-intégrité-disponibilité. Difficile d'avoir les trois propriétés en même temps. Un opérateur de serveur peut améliorer la confidentialité et l'intégrité en n'activant que des suites TLS très sures, mais ça se fera au détriment de la disponibilité. Oui une banque française devrait avoir une configuration similaire à ton site (quoiqu'on peut discuter de l'utilité de PFS pour les opérations bancaires mais passons...). Pour un opérateur de service comme Google, ça revient à priver une partie de la planète de TLS.
Bref, pour conclure ça n'a pas de sens de dire que le serveur example.com n'est pas sécurisé car il supporte RC4 ou 3DES. Pour qu'il y ait un problème de sécurité, il faut aussi que le client supporte RC4.