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

[Aaron Zauner]

https://tools.ietf.org/html/rfc5114


On Sun, Apr 27, 2014 at 11:54 PM, Aaron Zauner <azet at azet.org> wrote:

> To clarify: there are standard DH parameters that software distributions
> ship in their code (like - for example - the RSA exponent 65537).
> Like with the RSA exponent, these are standardized for a reason, you might
> even reduce security by generating parameters on your own.
> It's up to the software implementation to negotiate with sufficient DH
> parameter size, if it does not do that, it's clearly a software bug.
> Many software projects do not even support self-generated DH parameters to
> be used.
>
> Aaron
>
>
> On Sun, Apr 27, 2014 at 11:33 PM, Aaron Zauner <azet at azet.org> wrote:
>
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140427/372396bd/attachment.html>