Aller au contenu principal

11. Considérations de sécurité (Security Considerations)

La sécurité du protocole TLS repose sur les hypothèses suivantes:

11.1. Force cryptographique (Cryptographic Strength)​

La sécurité de TLS repose fondamentalement sur la force des primitives cryptographiques utilisées. Les implémenteurs doivent:

  • Utiliser des suites de chiffrement fortes
  • Éviter les algorithmes aux faiblesses connues (tels que DES, RC4, MD5)
  • Mettre à jour régulièrement les bibliothèques cryptographiques pour corriger les vulnérabilités connues

11.2. Génération de nombres aléatoires (Random Number Generation)​

La sécurité du protocole TLS dépend fortement de la génération de nombres aléatoires cryptographiquement forts. Les implémentations DOIVENT (MUST):

  • Utiliser des générateurs de nombres pseudo-aléatoires cryptographiquement sécurisés (CSPRNG)
  • S'assurer que le générateur de nombres aléatoires dispose de sources d'entropie suffisantes
  • Réensemencer régulièrement le générateur de nombres aléatoires

11.3. Validation des certificats (Certificate Validation)​

Une validation appropriée des certificats est essentielle pour prévenir les attaques de l'homme du milieu:

  • Vérifier l'intégrité de la chaîne de certificats
  • Vérifier l'état de révocation des certificats (CRL ou OCSP)
  • Vérifier la correspondance du nom d'hôte
  • Vérifier la période de validité du certificat

11.4. Attaques de retour arrière de version (Version Rollback Attacks)​

Les implémentations DOIVENT (MUST) empêcher les attaques de retour arrière de version. TLS utilise les numéros de version dans ClientHello et ServerHello, ainsi que verify_data dans le message Finished, pour détecter les tentatives de retour arrière de version.

11.5. Attaques connues (Known Attacks)​

Les implémentations doivent être conscientes des attaques connues suivantes:

  • BEAST (Browser Exploit Against SSL/TLS): Attaque contre le mode CBC de TLS 1.0. TLS 1.2 atténue cela avec des IV explicites.
  • CRIME (Compression Ratio Info-leak Made Easy): Attaque exploitant la compression TLS. Il est recommandé de désactiver la compression TLS.
  • Lucky 13: Attaque temporelle contre le remplissage en mode CBC. Les implémentations doivent utiliser des comparaisons à temps constant.
  • POODLE: Attaque contre SSL 3.0. SSL 3.0 devrait être désactivé.
  • Attaque de Bleichenbacher: Attaque contre le remplissage RSA PKCS#1 v1.5. TLS 1.2 inclut des protections contre cela.

11.6. Renégociation (Renegotiation)​

La renégociation peut introduire des risques de sécurité. La RFC 5246 définit l'extension de renégociation sécurisée pour résoudre ces problèmes. Les implémentations doivent:

  • Implémenter la RFC 5746 (Extension d'indication de renégociation TLS)
  • Gérer soigneusement les demandes de renégociation
  • Envisager de refuser la renégociation pendant les opérations sensibles

11.7. Déni de service (Denial of Service)​

Les poignées de main TLS sont relativement coûteuses (en particulier les opérations de clé publique). Les serveurs doivent:

  • Mettre en œuvre la limitation de débit
  • Envisager d'utiliser la reprise de session pour réduire le nombre de poignées de main complètes
  • Surveiller et détecter les modèles anormaux

11.8. Sécurité de l'implémentation (Implementation Security)​

Au-delà des considérations de sécurité au niveau du protocole, les implémentations doivent également:

  • Prévenir les débordements de tampon
  • Effacer en toute sécurité les données sensibles (clés, texte en clair)
  • Utiliser des comparaisons à temps constant pour prévenir les attaques temporelles
  • Gérer correctement les conditions d'erreur

Note: Pour une analyse de sécurité complète, veuillez vous référer à la section 11 et à l'annexe F de la RFC 5246.

Dernière mise à jour le