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

[Aaron Zauner]

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/d99abeb3/attachment.html>