<div dir="ltr"><a href="https://tools.ietf.org/html/rfc5114">https://tools.ietf.org/html/rfc5114</a><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 27, 2014 at 11:54 PM, Aaron Zauner <span dir="ltr"><<a href="mailto:azet@azet.org" target="_blank">azet@azet.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">To clarify: there are standard DH parameters that software distributions ship in their code (like - for example - the RSA exponent 65537).<div>
Like with the RSA exponent, these are standardized for a reason, you might even reduce security by generating parameters on your own.<br>
<div>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. <br></div><div>Many software projects do not even support self-generated DH parameters to be used.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Aaron</div></font></span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 27, 2014 at 11:33 PM, Aaron Zauner <span dir="ltr"><<a href="mailto:azet@azet.org" target="_blank">azet@azet.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><br>
Torsten Gigler wrote:<br>
> For DHE you need a second Key:<br>
> <a href="https://wiki.mozilla.org/Security/Server_Side_TLS#DHE_handshake_and_dhparam" target="_blank">https://wiki.mozilla.org/Security/Server_Side_TLS#DHE_handshake_and_dhparam</a><br>
</div>No you don't?<br>
<br>
I think you're confusing DH parameters with Keys. In case you're worried<br>
of the parameter size check with the upstream software vendor. For<br>
example: nginx and apache do now have sane defaults for some time.<br>
<br>
See:<br>
<a href="http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html" target="_blank">http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html</a><br>
<br>
There's really no need to generate your own DH parameters. A lot of<br>
blogs state that this should be done - clearly they have not understood<br>
how Diffie-Hellman works.<br>
<br>
Here is a nice description of how the protocol works:<br>
<a href="http://cacr.uwaterloo.ca/hac/about/chap12.pdf" target="_blank">http://cacr.uwaterloo.ca/hac/about/chap12.pdf</a><br>
<div><br>
> But there are implementations that have real trouble with to large<br>
> DH-key-sizes >1024bits (and to small, not focused here)<br>
> <a href="http://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html" target="_blank">http://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html</a><br>
><br>
> The Author, Hanno, is here on the list :-)<br>
> JAVA had this issue:<br>
> <a href="http://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception" target="_blank">http://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception</a><br>


<br>
</div>I'm aware of that. But:<br>
<div><br>
><br>
> You can see the JAVA issue (for versions that support SNI, as the<br>
> servers seem to use SNI):<br>
> <a href="https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on" target="_blank">https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on</a><br>
> (working)<br>
> <a href="https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on" target="_blank">https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on</a><br>
> (JAVA 6/7 (+8?) does not work)<br>
> 0x16, EDH-RSA-DES-CBC3-SHA hides sometimes the failure of JAVA with<br>
> DHE-RSA-AES128-SHA<br>
><br>
> I haven't seen a wireshark trace yet, but I haven't seen any error<br>
> handling for this in RFC than a complete handshake failure and to hope<br>
> that the client tries to send a second hello without the Cipher that<br>
> caused the failure. [The clients sends all ciphers he can (generally)<br>
> handle, the server hello includes only 1 Cipher that the server chose on<br>
> base of this list, the server does not know that the client will have<br>
> trouble with this, if the keysize is to large].<br>
<br>
</div>The DH parameters and size chosen have no effect on the underlying<br>
blockcipher. Of course their security should match, but what's the<br>
difference between DHE-RSA-AES128-SHA and DHE-RSA-AES256-SHA in terms of<br>
the handshake? If it doesn't work for either of those two because for<br>
example Java has an issue with the DH parameter size, it would not work<br>
for the other blockcipher as well.<br>
<div><br>
> So I think it is a good idea to exclude the Ciphers that would be the<br>
> 1st Cipher for those legacy clients like JAVA: 0x00,0x33 -<br>
> DHE-RSA-AES128-SHA and to use at least 2000 bits for the DH-Key (see<br>
> BSI:<br>
><br>
<a href="https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.pdf?__blob=publicationFile" target="_blank">https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.pdf?__blob=publicationFile</a>).<br>


<br>
</div>The BSI (aka former crypto division of the BND) is giving complete<br>
bullshit recommendations there. I'm not surprised at all. They do<br>
recommend DHE_DSS only with a small footnote with problems on<br>
"implementations of TLS". Which is wrong. It's just the DSS standard<br>
that's flawed. Besides that I do not see them excluding AES128 with DHE.<br>
So I'm still not sure what you exactly mean by that :)<br>
<br>
BTW: Never trust recommendations by government bodies.<br>
<div><br>
> I hope this has clarified this point, OK?<br>
</div>Not really :)<br>
<span><font color="#888888"><br>
Aaron<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>