Am 12.06.2015 um 04:01 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Arthur,
On 6/11/15 4:34 PM, Arthur Ramsey wrote:
On 06/11/2015 02:35 PM, Christopher Schultz wrote: Arthur,
On 6/11/15 2:14 PM, Arthur Ramsey wrote:
Is anyone aware of a way to mitigate the Logjam attack with
tomcat 7 and java 7?
Disable DHE_EXPORT on the server?
I believe I have, but Qualys SSL Server Test still fails me on
the Logjam check.
SSLCipherSuite="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SH
A256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-A
ES128-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-AES25
6-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
You
also have DHE-* ciphers in there, which is probably the problem.
Remove those and I think Qualys will be happier. Really, who is using
DHE in the first place?
I use tcnative and openssl-1.0.2a both compiled from source
in production today, but I would be open to JSSE too. I
believe I need Java 8 to mitigate CVE-2015-4000 with JSSE.
Why?
See
http://stackoverflow.com/questions/30352105/how-to-set-custom-dh-grou
p-in-java-sslengine-to-prevent-logjam-attack
Understood.
I thought you just wanted to remove the EXPORT and DHE
ciphers in general. Increasing the number of bits in the DH parameters
will in fact require an upgrade.
I don't see anyway to use a unique 2048-bit or greater DH
group with tcnative currently.
I believe you are correct; there is a bug in BZ:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56108
It looks like 1.1.34 will have this feature. You can build the
current trunk of the 1.1 branch and probably be okay.
Thanks, I'll give it a try. Scary to use in production, but it
may be my best answer.
I'm not sure if there is anything I can do at compile time.
I'd rather not change the cipher suites as I want to maintain
browser support.
You should disable EXPORT certificates no matter what. Or were you
talking about the DH parameters?
I was talking about DH parameters.
My server configuration passed the Qualys SSL Server Test
with flying colors until Logjam, so I would be worried about
regressions on other security fixes if I used JSSE.
-chris
- -chris
There's two parts under Logjam:
- a downgrade attack that makes the real attack very feasible. The
downgrade only works if client and derver support the export ciphers (it
is not necessary that they are the preferred ciphers) and the attacker
is an active man-in-the-middle, ie. she can observe and change the
communication. In this case the encryption can be forced to use a 512
Bit key and is relatively easy to break.
To mitigate the downgrade attack, it should be posible to just disable
export ciphers on the server side, which is doable per configuration.
- in addition for non-export ciphers, key length of 768 bits and 1024
bits are assumed to be atackable depending on the computing ressources
tha attacker has at her hand. 768 is expected to be breakable using
academic computing ressources, 1024 bits using national computing resources.
To mitigate this, one should use longer keys. I think that is not
possible with current tcnative 1.1.33. Only the head of 1.1 has code to
allow that. This code would
- use a longer key automatically, if the key in the server
certificate is longer. E.g. a 2048 bit RSA key would lead to using also
a 2048 bit DHE key automatically. This 2048 DH params are standard DH
params but should nevertheless be safe due to their length.
- allows to add custom DH params to the certificate file to choose
completely custom DH params.
With existing 1.1.33 you can choose your cipher suite, so that non-DHE
ciphers come first and set SSLHonorCipherOrder such that the client
chooses the first matching cipher and DHE will likely not be used, only
by client who do not support a cipher to the left of DHE in your cipher
list.
Note that old Java versions as clients (6, maybe 7 depending on patch
level?) have a problem with DHE keys longer than 768 or 1024 bits
(depending on JVM details). So by mitigating Logjam you might run into
compatibility issues with those.
It would be interesting to know, what details SSLLabs tell you, e.g. if
they say you are vulnerable to the export downgrade attack (really bad),
or "just" to your DH params should be longer. You can use the OpenSSL
commandline client in version 1.0.2 to check, what param length a
handshake results in:
openssl s_client -connect www.example.com:443 -cipher "EDH" | \
grep "Server Temp Key"
See: https://www.openssl.org/blog/
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
