[SSL: DH_KEY_TOO_SMALL] dh key too small

Suivi d’un emplacement dans le code source, comme « (_ssl.c:1082) ». curl et les autres clients OpenSSL affichent la même raison sous la forme « dh key too small ».

Python ssl module (OpenSSL, security level 2) — ssl.SSLError, SSL_R_DH_KEY_TOO_SMALL

Ce que cela signifie

Le serveur a choisi un échange de clés Diffie-Hellman sur corps fini (DHE) avec un groupe plus petit que ce qu’accepte le client, généralement de 1024 bits. Python 3.10 et les versions ultérieures utilisent le niveau de sécurité 2 d’OpenSSL, qui exige un DH d’au moins 2048 bits : le client interrompt donc le handshake. Le certificat du serveur n’est pas en cause.

Pourquoi cela se produit

• Le serveur utilise un groupe DH de 1024 bits

  fréquente

  Les anciennes versions d’Apache httpd (avant la 2.4.7, elles utilisaient des paramètres fixes de 1024 bits), les anciens serveurs Java et les configurations qui chargent encore un fichier dhparam généré il y a des années. Les travaux sur Logjam (2015) ont montré que le DH de 1024 bits était à la portée d’attaquants disposant de moyens importants.

• Le niveau de sécurité par défaut plus strict de Python

  fréquente

  Python 3.10 a relevé sa valeur par défaut au niveau de sécurité 2 d’OpenSSL. Un code qui se connectait sans problème sous Python 3.9 peut échouer après une mise à jour, alors que le serveur n’a pas changé.

• Appareils embarqués et équipements

  occasionnelle

  Les interfaces d’administration des imprimantes, des autocommutateurs (PBX) et des équipements industriels ne proposent souvent que du DHE avec de petits groupes.

Comment corriger l’erreur

1. 1.

   Confirmer la taille de l’échange de clés

   Connectez-vous une fois au niveau de sécurité 1 avec openssl s_client et lisez « Server Temp Key ».

   # "Server Temp Key: DH, 1024 bits" confirms the weak group
   openssl s_client -connect legacy.example.com:443 -servername legacy.example.com \
     -cipher 'DEFAULT:@SECLEVEL=1' </dev/null 2>/dev/null | grep 'Server Temp Key'

2. 2.

   Propriétaires de serveurs : utiliser ECDHE ou un groupe de 2048 bits

   Privilégiez les suites ECDHE (et TLS 1.3) ; si DHE est nécessaire, configurez un groupe de la RFC 7919 d’au moins 2048 bits.

   # nginx: prefer ECDHE; if DHE must stay, use a 2048-bit (or larger) group
   ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
   ssl_dhparam /etc/nginx/ffdhe2048.pem;   # RFC 7919 group

3. 3.

   Contournement temporaire : abaisser le niveau de sécurité pour un seul hôte

   « DEFAULT:@SECLEVEL=1 » dans un contexte dédié accepte le DH de 1024 bits pour cet hôte uniquement. N’utilisez pas ce réglage dans des contextes partagés ou par défaut : il accepte aussi d’autres paramètres faibles.

   # Temporary workaround for one legacy host: security level 1 accepts 1024-bit DH
   import ssl, urllib.request
   
   ctx = ssl.create_default_context()
   ctx.set_ciphers("DEFAULT:@SECLEVEL=1")
   urllib.request.urlopen("https://legacy.example.com/", context=ctx)

← Parcourir toute la base de données des erreurs de signature