• 11
name

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191

Backtrace:

File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

name Punditsdkoslkdosdkoskdo

SSL/TLS via Tomcat - replaced keystore, still weak DH

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.

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.

  • 3
Reply Report
    • 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?
      • 1
    • 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.

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.

  • 1
Reply Report
      • 1
    • 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.
      • 1
    • 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.

Trending Tags