0

I am presently in a battle with a stubborn SSL implementation. I replaced the old keystore with a keystore that included:

  • a certificate from a public CA (yay no more self signed!)
  • an intermediate certificate (godaddy)
  • 2048-bit length cert/key, versus the old 1024.

Despite this, I am still receiving the "weak diffie-hellman key" error for my Chrome clients (Firefox digs it now I guess at least :D). I did some tests via nmap to observe what the server is willing to talk, and it supposedly checks out OK:

root@ubuntu14-en:~# nmap --script ssl-enum-ciphers -p 443  artifactory.mydomain.com  

Starting Nmap 6.40 ( http://nmap.org ) at 2015-09-10 08:41 CDT  
Nmap scan report for artifactory.mydomain.com (xxx.xx.x.xx)  
Host is up (0.00026s latency).  
PORT    STATE SERVICE  
443/tcp open  https  
| ssl-enum-ciphers:  
|   TLSv1.0:  
|     ciphers:  
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong  
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong  
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong  
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong  
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong  
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong  
|       TLS_RSA_WITH_RC4_128_MD5 - strong  
|       TLS_RSA_WITH_RC4_128_SHA - strong  
|     compressors:  
|       NULL  
|   TLSv1.1:  
|     ciphers:  
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong  
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong  
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong  
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong  
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong  
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong  
|       TLS_RSA_WITH_RC4_128_MD5 - strong   
|       TLS_RSA_WITH_RC4_128_SHA - strong  
|     compressors:  
|       NULL  
|   TLSv1.2:  
|     ciphers:  
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong  
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong  
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong  
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong  
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong  
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong  
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong  
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong  
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong  
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong  
|       TLS_RSA_WITH_RC4_128_MD5 - strong  
|       TLS_RSA_WITH_RC4_128_SHA - strong  
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 1.42 seconds

Can anyone else contribute their knowledge to how I can up the security to common appropriate standards that Chrome is expecting? I suspect it's something dumb like I need to lock down those ciphers more, but I thought "DHE_EXPORT" ciphers were the ones to look out for.

Thank you very much in advance.

nthieling
  • 103
  • 1
  • 4

2 Answers2

3

As well as disabling export DHE cipher suites, you need to use a 2048-bit Diffie-Helman group rather than the 1024-bit that Tomcat is probably using. It's believed that someone with the resources of the NSA could break 1024-bit. To do so, add -Djdk.tls.ephemeralDHKeySize=2048 to your Java or Catalina options. Note that this only works in Java 8 or later -- if you're on 7 (or earlier) then it's time to upgrade.

And while you're at it, disable the RC4 cipher suites -- RC4 is no longer secure.

Mike Scott
  • 7,993
  • 31
  • 26
  • If my certificate/key is 2048-bit, wouldn't that mean Tomcat is accommodating that? Or is there something else involved with a 1024-bit group that I am unaware of? – nthieling Sep 10 '15 at 15:03
  • It's not the number of bits in your key; it's the number of bits used to generate ephemeral keys, which is independent of the bit-length of your key. The ephemeral keys are used to achieve perfect forward secrecy, but it's not very perfect if they can be broken. – Mike Scott Sep 10 '15 at 15:24
1

None of these specifically addresses "weak diffie-hellman key" but they will help.

MD5 hashes are broken; get rid of them.

RC4 ciphers are weak/broken; get rid of them.

SHA1 ("SHA") hashes are also considered weak. If your SSL cert (not the allowed crypto in the ssl config) is using SHA1, chrome will complain. However, I think you can't get rid of SHA cipher configs and still support TLS 1.0, so you are stuck with that.

I would suggest disabling 3DES also; it's very slow compared to AES and has no security advantages.

Dan Pritts
  • 3,221
  • 26
  • 28
  • Thank you for your input- do you have any reference material on how cipher selection should be handled in Tomcat? I see so many conflicting views - I am using Tomcat 7. Does this sound appropriate? https://confluence.atlassian.com/display/JIRAKB/Server+has+a+weak,+ephemeral+Diffie-Hellman+public+key – nthieling Sep 10 '15 at 14:48
  • this could be a nice place to start for recommendations https://wiki.mozilla.org/Security/Server_Side_TLS – Koen van der Rijt Sep 10 '15 at 14:55
  • I don't normally do SSL with tomcat, I put apache in front of it, so I am not an expert. However, I would trust atlassian's advice. Also, note that if you are using "tomcat native", the SSL configuration is different - openssl does the encryption, not java. You mention "keystore" which IIRC is a java term - so presumably you're not using native. – Dan Pritts Sep 10 '15 at 15:36
  • Not using openssl in this case, java keystore which is called by tomcat with SSLEnabled=true, and keystoreFile=keystorefile.jks - thank you for the advice! I will be spinning up a test instance to see if I can make the magic happen on a non-prod tomcat system. – nthieling Sep 10 '15 at 18:17