Un scan montre que votre serveur prend encore en charge SSLv3/TLS 1.0 et RC4. Que faites-vous ?
Réponse courte
SSLv3, TLS 1.0 et RC4 sont cassés ou obsolètes et permettent des attaques par rétrogradation et déchiffrement ; désactivez-les donc et exigez TLS 1.2 ou 1.3 avec des suites de chiffrement robustes et à confidentialité persistante, en acceptant la rare perte de très vieux clients. Les laisser actifs par compatibilité maintient la faiblesse exploitable. Ajouter un second certificat ou passer à un certificat auto-signé ne supprime pas les protocoles faibles, et l'auto-signé nuit à la confiance sans corriger la cryptographie.
Un scan qui signale SSLv3, TLS 1.0 et RC4 rapporte de la cryptographie que l'industrie a retirée il y a des années. Ce ne sont pas des faiblesses théoriques — elles ont des attaques nommées et pratiques — donc la bonne décision est de désactiver les protocoles et chiffrements obsolètes et d'exiger un TLS moderne.
Pourquoi ils sont cassés
- SSLv3 est fatalement compromis par POODLE, qui permet à un attaquant réseau de déchiffrer des octets d'une session chiffrée.
- TLS 1.0 porte des faiblesses structurelles (par ex. BEAST) et est déprécié par PCI DSS et les principaux navigateurs.
- RC4 présente des biais qui rendent la récupération de texte clair faisable et est interdit par la RFC 7465.
Le danger plus profond est l'attaque par rétrogradation : même si un client moderne peut parler TLS 1.3, un attaquant actif peut réduire la négociation à l'option la plus faible que les deux parties proposent encore. Tant que votre serveur annonce RC4 ou SSLv3, vous restez exploitable — la seule disponibilité constitue le risque.
La bonne correction
Configurez le serveur pour exiger TLS 1.2 au minimum (préférez 1.3) et ne proposer que des suites de chiffrement robustes et à confidentialité persistante (échange de clés ECDHE, AES-GCM ou ChaCha20-Poly1305). La confidentialité persistante garantit que compromettre plus tard la clé à long terme du serveur ne peut pas déchiffrer des sessions précédemment capturées. Validez le résultat avec un nouveau scan. Le compromis — perdre une poignée de clients très anciens — est presque toujours acceptable et bien moins coûteux qu'une brèche.
Pourquoi les autres réponses sont fausses
- « Le laisser activé pour la compatibilité » préserve exactement la faiblesse vers laquelle un attaquant rétrograde ; le confort de quelques clients hérités expose tout le monde.
- Ajouter un second certificat traite l'identité/couverture SAN, pas la négociation de protocole et de chiffrement — les options faibles restent au menu.
- Passer à un certificat auto-signé est activement pire : cela rompt la chaîne de confiance (avertissements navigateur, MITM facilité) tout en laissant SSLv3/TLS 1.0/RC4 pleinement actifs. Cela confond confiance dans le certificat et robustesse du protocole.
L'examinateur vérifie que vous corrigez la cryptographie négociée, comprenez le risque de rétrogradation et ne confondez pas un changement de certificat avec un durcissement de protocole.
Questions de suivi probables
- Quelles attaques visent spécifiquement SSLv3 et RC4, et comment une attaque par rétrogradation force-t-elle leur usage ?
- Qu'apporte la confidentialité persistante (forward secrecy), et quelles suites de chiffrement la fournissent ?
- Comment déploieriez-vous ceci sans casser un petit ensemble de clients hérités que vous ne pouvez pas mettre à jour ?