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 '19 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 – RubberStamp Feb 26 '19 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. – dave_thompson_085 Feb 27 '19 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? – dave_thompson_085 Feb 27 '19 at 4:06
  • Possibly related information regarding Microsoft Server and 1024 DH - external link – RubberStamp Feb 27 '19 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.