"3DES is considered weak and must be avoided, using it cap your score to "C"."
Alors que la RFC 7525 qui te sert de référence dit le contraire :
3DES a un autre biais, sa taille de bloc, qui n’est que de 64 bits, soit bien trop faible.
L’ANSSI déconseille aussi ce cipher (cf http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 & 11) et recommande au moins du 128 bits (en taille de clef & en taille de bloc).
Je me pose des questions car ce "perfect" bloque plein d'utilisateurs considérés encore comme sûrs, c'est "perfect" vis à vis de quoi?
C’est « perfect » au sens qu’on n’a aucun des warning/erreurs précédents.
il est imparfait si il bloque des utilisateurs sans raison de sécurité au moment du test
Faux.
Le fait d’avoir du 3DES actif côté serveur suffit à pouvoir tomber dessus en cas de mauvaise configuration (ordre des suites côté client) ou en cas d’attaque (downgrade attack).
On n’est donc pas à l’abris d’une merde dès que 3DES est dispo quelque part.
On a aussi vu que le non support de PFS exposait violamment à la NSA (par exemple via Heartbleed) en cas de compromission de la clef privée dans le futur.
Idem, sauf à utiliser uniquement des suites PFS (puisque la présence d’une non PFS rendrait la connexion potentiellement non fiable), on est à poil.
Du coup, un serveur du monde réel qui ne veut pas se couper de gens sans raison de sécurité en 2015 se tape un "C" sur cryptcheck la où il obtient un "A+" sur SSLLabs...
Ne pas se couper des gens à l’heure actuelle, c’est exploser en plein vol à la prochaine grosse faille de sécu sur ces protocoles. TLSv1.0 & TLSv1.1 sont dorénavant faillibles à du Poodle, et une escalade de cette faille rendrait vulnérables tous les utilisateurs de ces protocoles.
La note « A » est donc la seule configuration valable actuellement qui résistera dans le temps et évitera d’avoir à patcher à l’arrache (ou non, cf RC4 & MD5 qui persistent malgré les risques...).
Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1. Dernière modification le 13 octobre 2015 à 10:19.
3DES a un autre biais, sa taille de bloc, qui n’est que de 64 bits, soit bien trop faible.
L’ANSSI déconseille aussi ce cipher (cf http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 & 11) et recommande au moins du 128 bits (en taille de clef & en taille de bloc).
C’est « perfect » au sens qu’on n’a aucun des warning/erreurs précédents.
Faux.
Le fait d’avoir du 3DES actif côté serveur suffit à pouvoir tomber dessus en cas de mauvaise configuration (ordre des suites côté client) ou en cas d’attaque (downgrade attack).
On n’est donc pas à l’abris d’une merde dès que 3DES est dispo quelque part.
On a aussi vu que le non support de PFS exposait violamment à la NSA (par exemple via Heartbleed) en cas de compromission de la clef privée dans le futur.
Idem, sauf à utiliser uniquement des suites PFS (puisque la présence d’une non PFS rendrait la connexion potentiellement non fiable), on est à poil.
Ne pas se couper des gens à l’heure actuelle, c’est exploser en plein vol à la prochaine grosse faille de sécu sur ces protocoles. TLSv1.0 & TLSv1.1 sont dorénavant faillibles à du Poodle, et une escalade de cette faille rendrait vulnérables tous les utilisateurs de ces protocoles.
La note « A » est donc la seule configuration valable actuellement qui résistera dans le temps et évitera d’avoir à patcher à l’arrache (ou non, cf RC4 & MD5 qui persistent malgré les risques...).
Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html