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"

Community
  • 1
Casper
  • 93
  • 1
  • 6
  • I'm voting to close this question as off-topic because it's better suited for [Tomcat's IRC](http://tomcat.apache.org/irc.html) or [mailing lists](http://tomcat.apache.org/lists.html) – RoraΖ May 21 '15 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 '15 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](http://chat.stackexchange.com/rooms/151/the-dmz) if you would like to discuss it further. – RoraΖ May 21 '15 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 '15 at 16:40
  • @SteveDL Exactly right. Security is a cross-discipline area. Cordoning off things tightly is the wrong approach in discipline that crosses lines. This group knows the specifics of logjam, the other group knows some specifics of Tomcat. The right answer is going to come from someone with skills in BOTH areas, and that's more likely to come from here. I keep seeing this group trying to be have its focus narrowed more and more, and I think that's the wrong approach. – Steve Sether May 22 '15 at 19:04
  • 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 '15 at 13:44
  • @dave_thompson_085 It was SOJPM who replied to Rhino, not me. Slllabs sees the 786 bit DHE suites, with the latest cipherlist from weakdh. I'll try disabling all the non ECDHE-RSA-AES ciphers. The combination of your comment, Rhino's answer and SOJPM's comment sounds like a complete answer to my question. Thanks. – Casper May 27 '15 at 16:12
  • @dave_thompson_085 Could you make your comment an answer, please? Is there a list somewhere with the corresponding JSSE formatted ciphers? – Thaoden May 28 '15 at 15:52
  • Caper: sorry I missed the different user. @Thaoden my comment adds a little to the answer but isn't anywhere near an answer. The *recommended* setting for Tomcat is now correct on the weakdh website. To be precise, JSSE defines the *names* which are a subset of the RFC names in the IANA registry; Tomcat puts them in a comma-separated list https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_BIO_and_NIO – dave_thompson_085 Jun 01 '15 at 19:17

3 Answers3

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.

  • 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 '15 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. –  May 26 '15 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)

LvB
  • 8,336
  • 1
  • 27
  • 43
-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

jas-
  • 929
  • 5
  • 9