[Ach] Issue with OpenSSL >0.9.8l <1.0.0 (DHE key size)

[Aaron Zauner]

Hi,

Torsten Gigler wrote:
> For DHE you need a second Key:
> https://wiki.mozilla.org/Security/Server_Side_TLS#DHE_handshake_and_dhparam
No you don't?

I think you're confusing DH parameters with Keys. In case you're worried
of the parameter size check with the upstream software vendor. For
example: nginx and apache do now have sane defaults for some time.

See:
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

There's really no need to generate your own DH parameters. A lot of
blogs state that this should be done - clearly they have not understood
how Diffie-Hellman works.

Here is a nice description of how the protocol works:
http://cacr.uwaterloo.ca/hac/about/chap12.pdf

> But there are implementations that have real trouble with to large
> DH-key-sizes >1024bits (and to small, not focused here)
> http://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html
> 
> The Author, Hanno, is here on the list :-)
> JAVA had this issue:
> http://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception

I'm aware of that. But:

> 
> You can see the JAVA issue (for versions that support SNI, as the
> servers seem to use SNI):
> https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on
> (working)
> https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on
> (JAVA 6/7 (+8?) does not work)
> 0x16, EDH-RSA-DES-CBC3-SHA hides sometimes the failure of JAVA with
> DHE-RSA-AES128-SHA
> 
> I haven't seen a wireshark trace yet, but I haven't seen any error
> handling for this in RFC than a complete handshake failure and to hope
> that the client tries to send a second hello without the Cipher that
> caused the failure. [The clients sends all ciphers he can (generally)
> handle, the server hello includes only 1 Cipher that the server chose on
> base of this list, the server does not know that the client will have
> trouble with this, if the keysize is to large].

The DH parameters and size chosen have no effect on the underlying
blockcipher. Of course their security should match, but what's the
difference between DHE-RSA-AES128-SHA and DHE-RSA-AES256-SHA in terms of
the handshake? If it doesn't work for either of those two because for
example Java has an issue with the DH parameter size, it would not work
for the other blockcipher as well.

> So I think it is a good idea to exclude the Ciphers that would be the
> 1st Cipher for those legacy clients like JAVA: 0x00,0x33 -
> DHE-RSA-AES128-SHA and to use at least 2000 bits for the DH-Key (see
> BSI:
>
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.pdf?__blob=publicationFile).

The BSI (aka former crypto division of the BND) is giving complete
bullshit recommendations there. I'm not surprised at all. They do
recommend DHE_DSS only with a small footnote with problems on
"implementations of TLS". Which is wrong. It's just the DSS standard
that's flawed. Besides that I do not see them excluding AES128 with DHE.
So I'm still not sure what you exactly mean by that :)

BTW: Never trust recommendations by government bodies.

> I hope this has clarified this point, OK?
Not really :)

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140427/02b324d2/attachment.sig>