9

Can anyone verify this fix secures against the Logjam vulnerability for Apache Tomcat?

I'm sceptical about it's effectiveness, since it doesn't mention how to implement the user defined 2048 bit DH parameter file in Tomcat, but its cipher list does use "DHE" ciphers. Yesterday there was a mention about a "SSLDHParametersFile" setting, but it was removed, possibly due to this bug, where it says Tomcat can only handle 1024 bit DH key lengths. But I'm not an expert on this, possibly mixing things up here.

At the moment, the WeakDH site says you should add this cipher list to the Connector in the server.xml file (for JSSE) to fix it:

ciphers="ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384, DHE-RSA-AES128-GCM-SHA256, DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA, ECDHE-ECDSA-AES256-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA256, DHE-RSA-AES256-SHA256, DHE-DSS-AES256-SHA, DHE-RSA-AES256-SHA, AES128-GCM-SHA256, AES256-GCM-SHA384, AES128-SHA256, AES256-SHA256, AES128-SHA, AES256-SHA, AES, CAMELLIA, DES-CBC3-SHA"

Improve this question
9
  • I'm voting to close this question as off-topic because it's better suited for Tomcat's IRC or mailing lists
    – RoraΖ
    May 21, 2015 at 13:25
  • 3
    @raz This is inherently an information security question. The fact that it's a question about server configuration is irrelevant. This group is inherently cross-functional, and covers many disciplines. Please don't turn Information Security into a finger pointing exercise where we refer them to another forum, and they do the same thing.
    – Steve Sether
    May 21, 2015 at 15:45
  • 1
    The OP is asking if a specific configuration for Tomcat will fix a security vulnerability. Pointing the OP to the people who are experts in the software is not finger pointing. They are in a better position of knowing whether or not that fix specific to Tomcat will work, or possibly provide a better solution than InfoSec SE. Feel free to join The DMZ if you would like to discuss it further.
    – RoraΖ
    May 21, 2015 at 16:35
  • @raz in this specific case, given the discussions we've had on the chat I'm inclined to thinking that Tomcat experts might provide a wrong answer, as multiple factors are involved in correcting Logjam.
    – Steve Dodier-Lazaro
    May 21, 2015 at 16:40
  • 1
    Tomcat by default uses Java SSL (JSSE). The cipherlist originally on weakdh, which you quoted, is in OpenSSL format and won't work at all; the website is now fixed. The bug report you link to is about TCNative /APR (and OpenSSL) and irrelevant to JSSE. Your comment on @Rhino answer says you disabled all DHE (keeping only ECDHE) but your edit here implies ssllabs is still seeing DHE suites with 768-bit; which is correct? If you do want to use (nonEXPORT) DHE in JSSE, you need to run on Java8 to get 1024-bit DHE (and that's a fixed/shared group).
    – dave_thompson_085
    May 27, 2015 at 13:44

3 Answers 3

Reset to default
8

So I think I've interpreted your question correctly. If not, fire away in the comments.

Confusingly there are several factors in diffie hellman: are you doing it over elliptic curves or not, what size group have you got (let's assume "strong" and "not strong") and whether you generate ephemeral private/public keypairs or not.

The problem with logjam is this: if you have a plain old group variant of DHE, then if you can persuade the server to downgrade to the export (weak variety) level strength, then with some precomputations made before you can break the secret generated for a session in minutes.

This is conditional on being able to downgrade size variable to a smaller one - if you can do this over the plain old DHE variant, then you're in business.

This requires the cipher suite have DHE_..._EXPORT_... in it, such as TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA. Now that has a bunch of other problems like 40-bit DES and whatnot, but essentially, there could feasibly be some servers out there that support EXPORT variants of DHE with better symmetric ciphers. Or they could actually be negotiating 40-bit DES if persuaded.

The point is to perform a downgrade attack. The cipher suite list you've given doesn't allow for export ciphers.

You could turn off all non-EC variants of DH. However, this might limit client side support. Whether or not you can be so limiting is really up to you. But "DHE" in and of itself is fine, unless there's export in there somewhere. Make sure export ciphers are disabled, and follow Thomas' advice in the answer you linked.

Now on to SSLDHParametersFile - in DHE, the prime and generator of the group can actually be fixed ahead of time - the bit that is ephemeral is the private key chosen in that group. This way, by setting the parameters you can control what size group your server uses.

For example, the output of this might be:

openssl dhparam 2048 -text
<snip>
    PKCS#3 DH Parameters: (2048 bit)
    prime:
        00:bd:90:31:72:a5:bf:eb:96:b0:0e:1c:1e:3f:ff:
        cd:0a:e2:fc:14:72:50:19:f8:6d:e9:25:3c:3d:21:
        3b:3c:e3:93:9b:2e:a1:b5:98:dc:25:88:9c:9e:55:
        1a:78:36:a8:10:67:f2:f1:37:e7:6b:c7:b8:39:85:
        a7:ec:aa:e9:2f:4e:10:17:fd:72:e1:22:2e:ab:97:
        4b:bf:7b:a2:68:6d:94:a8:ae:df:e0:fb:66:ad:79:
        02:9c:09:ba:47:60:40:12:a8:27:46:ba:8f:a9:8b:
        bd:f5:d2:4e:67:0c:7a:49:f3:9d:80:98:50:4d:8c:
        72:38:47:91:4b:54:1f:3b:74:b5:81:30:c7:89:71:
        b0:87:8a:82:66:b0:06:f6:2e:a6:2b:e8:18:51:23:
        2d:09:d9:0a:87:03:7b:85:8a:27:c6:bd:fa:e9:16:
        70:b3:bf:ad:77:d5:55:72:22:e7:7c:6b:4e:31:2c:
        86:91:7a:51:11:ac:23:9d:5f:3d:f1:f2:83:02:98:
        72:a2:a4:c5:a8:26:40:25:02:59:00:80:22:37:ac:
        38:95:07:76:f5:31:3d:19:f6:81:36:6c:14:fa:d8:
        46:10:e1:b4:fa:5f:e2:9d:2f:a1:78:47:5d:9c:f9:
        ac:0c:06:83:dc:f4:2d:81:17:d4:34:1b:6f:c2:c7:
        2c:0b
    generator: 2 (0x2)

Tellingly, from your example bug, it sounds like it is not possible to use these parameter files quite yet with Tomcat. I'm not an expert on Tomcat, so, I can't really say but if you have instructed the cipher suites to not allow export, OpenSSL should default to a 1024-bit DH group, which is good enough for now.

You can, then, when the patch is available, upgrade your DH parameters as you see fit.

Improve this answer
2
  • Well, I turned off all non ECDHE-RSA-AES* cipher suites. According to Qualys this "only" breaks: very old android, WinXP, openssl older than 1.0.0 and java 6. If you allow TLS 1.0 and 1.2.
    – SEJPM
    May 22, 2015 at 11:46
  • @SOJPM if you don't need these platforms I see nothing wrong with doing that personally. I think IE has trouble with EC up to a certain point, but I can't remember. Best to test. In any case, disabling older ciphersuites that you don't need is the best outcome. If you can only use TLS 1.2 that's best, but obviously for most service providers this isn't practical.
    – user70990
    May 26, 2015 at 12:37
2

As an addition to the awnser I list my practise:

For the moment I would not allow direct communications with tomcat, but setup a Reverse Proxy Connection using nginx.

And have nginx do all the SSL bits. The main advantages are that nginx can be setup with better DH keys and Cipher support. as a bonus if someone is trying to 'hack' my tomcat through overflow injection. it will propably only get to the nginx proxy and not to the tomcat itself. (so another layer to defeat for an attacker)

Improve this answer
-3

Disable any CBC mode ciphers and SSL protocols, only enable TLS 1.1 & 1.2 protocols in your server.xml.

Mozilla has a good guide for allowed ciphers as well. https://wiki.mozilla.org/Security/Server_Side_TLS

Improve this answer
1
  • AEAD-only is not viable. Many clients (e.g. all Apple devices) don't support AEAD.
    – Z.T.
    Jun 6, 2015 at 14:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .