Aller au contenu

LOGJAM Attack on Diffie-Hellman

Attaque LOGJAM sur Diffie-Hellman

Description

Cette vulnérabilité indique que le serveur est susceptible de subir des attaques LOGJAM, qui exploitent des paramètres Diffie-Hellman faibles pour forcer une rétrogradation des connexions TLS vers une cryptographie de niveau export cassable.

LOGJAM se produit lorsque les serveurs TLS prennent en charge les suites de chiffrement DHE_EXPORT ou utilisent des paramètres Diffie-Hellman faibles de 512 bits. Les attaquants de l'homme du milieu (man-in-the-middle) peuvent forcer les clients à rétrograder d'un échange de clés DHE fort vers un DHE de niveau export faible, rendant ainsi le chiffrement vulnérable à une cryptanalyse hors ligne.

Comment ça marche :

  1. L'attaquant intercepte la poignée de main TLS (handshake) entre le client et le serveur.
  2. Il force la rétrogradation des chiffrements DHE forts vers DHE_EXPORT faible (512 bits).
  3. Il capture la connexion rétrogradée avec les paramètres DH faibles.
  4. Il utilise des tables de logarithmes discrets précalculées pour casser le DH 512 bits hors ligne.
  5. Il récupère les clés de session et déchiffre tout le trafic capturé.

Prérequis :

  • Le serveur prend en charge les suites de chiffrement DHE_EXPORT ou des paramètres DH faibles.
  • Position réseau de l'homme du milieu pour forcer la rétrogradation.
  • Tables de crible du corps de nombres (number field sieve) précalculées pour les nombres premiers DH courants.
  • Le client est vulnérable aux attaques de rétrogradation de protocole.

Scénario d'exemple : Un serveur VPN d'entreprise prend en charge les chiffrements hérités DHE_EXPORT pour des raisons de compatibilité. Un attaquant sur le réseau intercepte les connexions des employés et force la rétrogradation vers des paramètres DH de 512 bits. À l'aide de tables cryptographiques précalculées (dont la génération a coûté environ 18 000 $), l'attaquant casse l'échange DH faible en quelques heures et déchiffre tout le trafic VPN, exposant ainsi les identifiants de l'entreprise et les données sensibles.

L'attaque exploite les mêmes restrictions d'exportation des années 1990 que FREAK, démontrant comment l'affaiblissement de la cryptographie imposé par les gouvernements a créé des vulnérabilités durables dans le protocole d'échange de clés Diffie-Hellman utilisé par des millions de serveurs à travers le monde.

Recommandation

Pour atténuer les attaques LOGJAM :

Défense principale - Désactiver les chiffrements DH de niveau export :

# Apache - désactiver les chiffrements DH d'exportation
SSLCipherSuite HIGH:!aNULL:!MD5:!EXP:!DHE

# Préférable : utiliser ECDHE au lieu de DHE
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE

# Nginx - désactiver les chiffrements DH faibles
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE:!EXPORT:!DES:!RC4:!MD5;

Utiliser des paramètres DH forts :

Si DHE est requis, générez des paramètres personnalisés de 2048 bits ou plus : 

# Générer des paramètres DH forts
openssl dhparam -out dhparams.pem 2048

# Apache : utiliser des paramètres DH personnalisés
SSLOpenSSLConfCmd DHParameters /path/to/dhparams.pem

# Nginx : spécifier des paramètres DH personnalisés
ssl_dhparam /path/to/dhparams.pem;

Privilégier ECDHE par rapport à DHE :

ECDHE offre de meilleures performances et une sécurité accrue : 

# Prioriser les suites de chiffrement ECDHE
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305

Protection côté client :

// Java - disable weak DH
System.setProperty("jdk.tls.disabledAlgorithms", "DH keySize < 1024");

Tester LOGJAM :

# Test de la prise en charge de DHE_EXPORT
nmap --script ssl-enum-ciphers -p 443 example.com | grep DHE_EXPORT

# Ne devrait montrer aucun chiffrement DHE_EXPORT disponible
openssl s_client -connect example.com:443 -cipher DHE-EXPORT

Atténuations supplémentaires :

  • Utiliser TLS 1.3 qui supprime la prise en charge des paramètres DH faibles.
  • Implémenter la confidentialité persistante (perfect forward secrecy) avec l'échange de clés ECDHE.
  • Surveiller les modèles de négociation de chiffrement inhabituels.
  • Auditer régulièrement les configurations TLS pour détecter les paramètres faibles.

La solution fondamentale consiste à abandonner DHE au profit de ECDHE, qui offre une sécurité équivalente avec de meilleures performances et aucune vulnérabilité liée au niveau export.

Liens

Normes

  • SOC2_CONTROLS:
    • CC_6_7
    • CC_7_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_32
  • PCI_STANDARDS:
    • REQ_4_1
    • REQ_6_2
    • REQ_11_3
  • HIPAA_CONTROLS:
    • SECURITY252
    • SECURITY212
    • SECURITY213