SSL Labs says that a website I control supports weak ciphersuites because they have DH 1024 bit, e.g. this one: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f).

I tried to connect to the website from my laptop while Wireshark was open, and I can see that the communication is performed with that ciphersuite, but what I see is:

  • p length: 256
  • g length: 256

So it seems right. Where the 1024 bit information comes from? Are there other parameters I should check?

  • 1
    ECDHE isn't identical to DHE, one is standard Diffie-Hellman that works with primes and the other is elliptic curve Diffie-Hellman which works with field operations. They do approximately the same thing, but ECDHE can be secure with 256 bit keys while DHE should use 2048 bits or more
    – Natanael
    Feb 26, 2019 at 17:11
  • The 256 bit key is the symmetric session key. The 1024 DH refers to the initial connection before the session key is agreed upon by the client and server... possible duplicate Feb 26, 2019 at 23:11
  • 1
    @Natanael: the length fields in ServerKX (and other TLS messages) displayed by Wireshark are in octets not bits, and 256*8=2048 !=1024. The selected ciphersuite is not ECDHE, and although theoretically 4492 allowed explicit curves no one implements them, so all actual ECDHE handshakes use a named curve with no p,a,b,G,n,h much less p,g sent at all. Feb 27, 2019 at 4:04
  • Fabio: it's rare for Qualys to make a mistake, but not impossible. Do you control the server enough to verify it is actually getting the hits from ssllabs, i.e. they aren't being misrouted to somewhere else? Ideally could you get a trace at the server and examine that? Feb 27, 2019 at 4:06
  • Possibly related information regarding Microsoft Server and 1024 DH - external link Feb 27, 2019 at 14:04


You must log in to answer this question.

Browse other questions tagged .