Aller au contenu principal

Annexe D. Notes d'implémentation (Implementation Notes)

Cette annexe fournit des conseils pratiques et des meilleures pratiques pour l'implémentation de TLS 1.2.

D.1. Génération et ensemencement de nombres aléatoires (Random Number Generation and Seeding)​

La sécurité de TLS dépend fortement de la qualité de la génération de nombres aléatoires. Les implémentations DOIVENT utiliser des générateurs de nombres pseudo-aléatoires cryptographiquement sécurisés (CSPRNG).

D.1.1. Exigences de génération de nombres aléatoires​

  • Source d'entropie: Utiliser des sources d'entropie de qualité cryptographique fournies par le système d'exploitation (telles que /dev/urandom sur les systèmes Unix)
  • Ensemencement: S'assurer que le PRNG est correctement ensemencé avant utilisation
  • Réensemencement: Réensemencer périodiquement pour maintenir le pool d'entropie
  • Éviter les sources faibles: Ne pas utiliser des valeurs prévisibles telles que les horodatages, les ID de processus comme seule source d'entropie

D.1.2. Recommandations d'implémentation​

/* Mauvaise pratique - Ne faites pas cela */
srand(time(NULL));
random_value = rand();

/* Bonne pratique - Utiliser le CSPRNG fourni par le système */
#ifdef _WIN32
    CryptGenRandom(...);  /* Windows */
#else
    /* Unix/Linux */
    int fd = open("/dev/urandom", O_RDONLY);
    read(fd, random_buffer, length);
    close(fd);
#endif

D.2. Certificats et authentification (Certificates and Authentication)​

D.2.1. Vérification des certificats​

Les implémentations DOIVENT vérifier correctement la chaîne de certificats:

  1. Vérification de la chaîne de certificats:

    • Vérifier la signature de chaque certificat
    • S'assurer que la chaîne de certificats atteint une autorité de certification racine de confiance
    • Vérifier la période de validité des certificats

  2. Vérification du nom d'hôte:

    • Vérifier le Common Name (CN) ou le Subject Alternative Name (SAN) dans le certificat
    • Prendre en charge les certificats génériques (tels que *.example.com)

  3. Vérification de la révocation:

    • Les implémentations DEVRAIENT vérifier l'état de révocation des certificats
    • Prendre en charge CRL (Certificate Revocation List) et/ou OCSP (Online Certificate Status Protocol)

D.2.2. Sélection de certificat​

Les serveurs devraient:

  • Prendre en charge plusieurs certificats (RSA, ECDSA, etc.)
  • Sélectionner le meilleur certificat en fonction des capacités du client
  • Équilibrer performance et sécurité

D.3. Suites de chiffrement (Cipher Suites)​

D.3.1. Sélection de suite de chiffrement​

Les implémentations DEVRAIENT:

  • Activer par défaut des suites de chiffrement fortes
  • Désactiver les suites de chiffrement avec des faiblesses connues (RC4, DES, chiffrements de qualité exportation)
  • Trier la liste des suites de chiffrement par priorité

D.3.2. Configuration recommandée​

Ordre de priorité (du plus élevé au plus bas):

  1. Suites de chiffrement AEAD (mode GCM)
  2. Suites offrant la confidentialité persistante (DHE/ECDHE)
  3. AES-256 plutôt qu'AES-128
  4. MAC SHA-256 ou plus fort
  5. Éviter le mode CBC (si possible)

Exemple de configuration:

1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
3. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
4. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
5. TLS_RSA_WITH_AES_256_CBC_SHA256
6. TLS_RSA_WITH_AES_128_CBC_SHA256

D.4. Pièges d'implémentation (Implementation Pitfalls)​

D.4.1. Attaques temporelles​

Problème: Les différences de timing dans la comparaison de mots de passe et la validation du rembourrage peuvent fuir des informations.

Solution: Utiliser une comparaison à temps constant:

/* Comparaison non sécurisée */
int compare(const unsigned char *a, const unsigned char *b, size_t len) {
    for (size_t i = 0; i < len; i++) {
        if (a[i] != b[i])
            return 0;  /* Sortie anticipée - fuite d'informations temporelles */
    }
    return 1;
}

/* Comparaison à temps constant */
int constant_time_compare(const unsigned char *a, const unsigned char *b, 
                         size_t len) {
    unsigned char result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= a[i] ^ b[i];
    }
    return result == 0;
}

D.4.2. Attaques par oracle de rembourrage​

Problème: Les erreurs de validation du rembourrage en mode CBC peuvent être exploitées.

Solution:

  • Utiliser une validation du rembourrage à temps constant
  • Retourner la même erreur pour toutes les échecs de déchiffrement
  • Envisager d'utiliser le mode AEAD (GCM) pour éviter ce problème

D.4.3. Attaques de rétrogradation de version​

Problème: Les attaquants peuvent tenter de forcer l'utilisation de versions de protocole plus faibles.

Solution:

  • Inclure la version négociée dans le message Finished
  • Vérifier la cohérence des champs de version
  • Implémenter la protection SCSV (Signaling Cipher Suite Value)

D.4.4. Attaques de renégociation​

Problème: La renégociation peut être utilisée pour injecter des commandes ou effectuer d'autres attaques.

Solution:

  • Implémenter RFC 5746 (Extension d'indication de renégociation)
  • Désactiver la renégociation pendant les opérations sensibles
  • Gérer correctement les changements de certificat client

D.4.5. Attaques par compression (CRIME)​

Problème: La compression TLS peut fuir des informations secrètes.

Solution:

  • Désactiver la compression au niveau TLS
  • Si la compression est nécessaire, l'implémenter au niveau de la couche application
  • Éviter de compresser des données contenant des secrets

D.4.6. Gestion des tampons​

Problème: Une gestion incorrecte des tampons peut entraîner des débordements ou des fuites d'informations.

Solution:

  • Toujours vérifier les champs de longueur
  • Utiliser des fonctions mémoire sécurisées (telles que memcpy_s)
  • Mettre à zéro les données sensibles après libération
/* Effacer les données sensibles */
void secure_zero(void *ptr, size_t len) {
    volatile unsigned char *p = ptr;
    while (len--)
        *p++ = 0;
}

/* Effacer la clé après utilisation */
unsigned char key[32];
/* ... utiliser la clé ... */
secure_zero(key, sizeof(key));

D.4.7. Gestion des erreurs​

Problème: Les messages d'erreur détaillés peuvent fuire des détails d'implémentation.

Solution:

  • Retourner des erreurs génériques aux entités externes
  • Les erreurs détaillées ne doivent être enregistrées qu'en interne
  • Éviter de fuir des informations temporelles

D.5. Optimisation des performances​

D.5.1. Reprise de session​

  • Implémenter le cache de session ou les tickets de session
  • Réduire le nombre de poignées de main complètes
  • Équilibrer sécurité et performance

D.5.2. Opérations en masse​

  • Traiter par lots les opérations de chiffrement/déchiffrement
  • Utiliser l'accélération matérielle (AES-NI, PCLMULQDQ, etc.)
  • Envisager d'utiliser des E/S asynchrones

D.5.3. Pool de connexions​

  • Réutiliser les connexions TLS
  • Implémenter la gestion du pool de connexions
  • Définir des valeurs de délai d'expiration raisonnables

Note: Pour les recommandations d'implémentation complètes et les explications détaillées, veuillez vous référer au texte complet de l'annexe D de la RFC 5246.

Dernière mise à jour le