Aller au contenu principal

Annexe F. Analyse de sécurité (Security Analysis)

Cette annexe fournit une analyse de sécurité du protocole TLS 1.2.

F.1. Protocole de poignée de main (Handshake Protocol)​

F.1.1. Authentification et échange de clés (Authentication and Key Exchange)​

Les objectifs de sécurité de base du protocole de poignée de main TLS sont:

  1. Authentification: Vérifier l'identité des pairs communicants
  2. Accord de clé: Établir de manière sécurisée un secret partagé
  3. Intégrité: S'assurer que les messages de poignée de main n'ont pas été altérés

F.1.1.1. Échange de clés anonyme (Anonymous Key Exchange)​

L'échange de clés anonyme n'est PAS recommandé!

Les suites de chiffrement Diffie-Hellman anonymes (DH_anon) ne fournissent pas d'authentification:

  • Vulnérable aux attaques de type homme du milieu
  • À utiliser uniquement dans des environnements contrôlés spécifiques
  • Les environnements de production devraient éviter l'utilisation

Risque de sécurité:

Client <---> Attaquant <---> Serveur
         |         |
         Deux échanges DH séparés
         Le client pense communiquer avec le serveur
         Le serveur pense communiquer avec le client
         Les deux communiquent en fait avec l'attaquant

F.1.1.2. Échange de clés RSA et authentification (RSA Key Exchange and Authentication)​

L'échange de clés RSA fournit:

  • Authentification du serveur (via certificat)
  • Authentification facultative du client
  • Transmission confidentielle du secret pré-maître

Caractéristiques de sécurité:

  • Certificat serveur signé par une CA de confiance
  • Le client vérifie la chaîne de certificats
  • Secret pré-maître chiffré avec la clé publique du serveur
  • Seul le détenteur de la clé privée du serveur peut déchiffrer

Limitations:

  • Ne fournit pas de confidentialité persistante
  • Si la clé privée du serveur est compromise, les sessions passées peuvent être déchiffrées

F.1.1.3. Échange de clés Diffie-Hellman avec authentification (Diffie-Hellman Key Exchange with Authentication)​

DHE (Diffie-Hellman éphémère) fournit:

  • Authentification du serveur
  • Confidentialité persistante
  • Garanties de sécurité plus fortes

Avantages en matière de sécurité:

  1. Confidentialité persistante:

    • Chaque session utilise de nouvelles paires de clés éphémères
    • Même si les clés à long terme sont compromises, les sessions passées restent sécurisées

  2. Authentification:

    • Paramètres DH signés par la clé privée du serveur
    • Le client vérifie la signature

Recommandé: Les suites de chiffrement DHE et ECDHE (DHE à courbe elliptique) sont le choix recommandé pour les déploiements TLS modernes.

F.1.2. Attaques de rétrogradation de version (Version Rollback Attacks)​

TLS utilise plusieurs couches de défense pour empêcher la rétrogradation de version:

  1. Version dans ClientHello et ServerHello:

    • Indique explicitement la version négociée
    • Le message Finished inclut le hachage de ces valeurs

  2. Message Finished:

    • Contient le MAC de tous les messages de poignée de main
    • Toute modification entraînera l'échec de la vérification

  3. TLS_FALLBACK_SCSV (RFC 7507):

    • Mécanisme de signalisation supplémentaire
    • Empêche les attaques de rétrogradation

F.1.3. Détection des attaques contre le protocole de poignée de main (Detecting Attacks Against the Handshake Protocol)​

TLS fournit les mécanismes suivants pour détecter les attaques:

  1. Intégrité des messages:

    • Le message Finished vérifie l'ensemble de la poignée de main
    • Le PRF garantit la force cryptographique

  2. Vérification des certificats:

    • Vérification complète de la chaîne de certificats
    • Vérification du nom d'hôte
    • Vérification de la révocation

  3. Protection contre les attaques temporelles:

    • Opérations à temps constant
    • Gestion uniforme des erreurs

F.1.4. Reprise de sessions (Resuming Sessions)​

Considérations de sécurité pour la reprise de session:

Caractéristiques de sécurité:

  • Réutilise le secret maître
  • Réduit la charge de calcul
  • De nouveaux nombres aléatoires garantissent l'unicité de la clé

Risques potentiels:

  • Stockage sécurisé des tickets de session
  • Protection des clés de chiffrement des tickets
  • Paramètres de délai d'expiration appropriés

Recommandations:

  • Limiter la durée de vie de la session
  • Rotation régulière des clés de chiffrement des tickets
  • Implémenter un mécanisme de révocation de session

F.2. Protection des données d'application (Protecting Application Data)​

F.2.1. Confidentialité des données​

TLS fournit:

  • Algorithmes de chiffrement forts (AES, etc.)
  • Matériel clé unique par enregistrement
  • Protection de l'intégrité (MAC ou AEAD)

F.2.2. Intégrité des données​

Chaque enregistrement TLS inclut:

  • MAC (pour les suites de chiffrement traditionnelles)
  • Étiquette d'authentification (pour les suites de chiffrement AEAD)
  • Numéro de séquence (empêche la relecture)

F.3. IV explicites (Explicit IVs)​

TLS 1.2 utilise des IV explicites pour traiter l'attaque BEAST dans TLS 1.0:

Problème de TLS 1.0:

  • Utilisait le bloc de texte chiffré précédent comme IV pour l'enregistrement suivant
  • Un IV prévisible permet des attaques par texte clair choisi

Solution de TLS 1.2:

  • Chaque enregistrement inclut un IV explicite généré aléatoirement
  • L'IV n'est plus prévisible
  • Atténue l'attaque BEAST

F.4. Sécurité des modes de chiffrement composites (Security of Composite Cipher Modes)​

F.4.1. Mode CBC​

Problèmes connus:

  • Attaques par oracle de rembourrage
  • Attaque temporelle Lucky 13
  • Attaque BEAST (TLS 1.0)

Atténuations:

  • TLS 1.2 utilise des IV explicites
  • Validation du rembourrage à temps constant
  • Messages d'erreur uniformes

F.4.2. Mode AEAD​

Avantages:

  • Fournit simultanément confidentialité et authentification
  • Non affecté par les attaques par oracle de rembourrage
  • Implémentation plus simple
  • Meilleures performances

Recommandé: Les déploiements modernes devraient prioriser les suites de chiffrement AEAD (GCM, CCM, ChaCha20-Poly1305).

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

Les poignées de main TLS sont relativement coûteuses et peuvent être utilisées pour des attaques DoS.

F.5.1. Vecteurs d'attaque​

  • Grand nombre de demandes de poignée de main
  • Épuisement des ressources (CPU, mémoire)
  • Surcharge de vérification des certificats

F.5.2. Stratégies d'atténuation​

Côté serveur:

  • Limitation de débit
  • Énigmes client
  • Priorité de reprise de session
  • Limites de ressources

Couche réseau:

  • Cookies SYN
  • Limites de connexion
  • Règles de pare-feu

F.6. Notes finales (Final Notes)​

F.6.1. Limitations connues​

TLS 1.2 ne peut pas empêcher:

  • La compromission des points de terminaison
  • La compromission de l'autorité de certification
  • La sélection de mots de passe faibles
  • Les attaques d'ingénierie sociale

F.6.2. Meilleures pratiques​

  1. Rester à jour:

    • Surveiller les annonces de sécurité
    • Mettre à jour les implémentations rapidement
    • Désactiver les algorithmes faibles

  2. Gestion de la configuration:

    • Utiliser des suites de chiffrement fortes
    • Activer toutes les fonctionnalités de sécurité
    • Auditer régulièrement la configuration

  3. Surveillance et réponse:

    • Enregistrer les événements de sécurité
    • Surveiller les modèles anormaux
    • Préparer un plan de réponse aux incidents

F.6.3. Migration vers TLS 1.3​

TLS 1.3 (RFC 8446) fournit:

  • Poignée de main plus rationalisée
  • Garanties de sécurité plus fortes
  • Suppression des algorithmes faibles
  • Performances améliorées

Recommandation: Les nouveaux déploiements devraient envisager d'utiliser TLS 1.3 tout en maintenant la compatibilité ascendante avec TLS 1.2.

Note: Pour une analyse de sécurité complète et une discussion détaillée, veuillez vous référer au texte complet de l'annexe F de la RFC 5246. Consultez également la RFC 7457 (résumant les attaques connues contre TLS et DTLS) pour les dernières considérations de sécurité.

Dernière mise à jour le