<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Aaron,<br>
<br>
Sorry for the late answer, I have been busy the last days.<br>
Thank you for clarifying the background of the DH Parameters. I
haven't dug so deep, how to set up the DH protocol.<br>
<br>
The main discussion point is, if CipherB should take care about
the fact that some (still used) SSL Clients do have an issue with
DHE >1024 Bits<br>
Known Canidates: <tt>Java 6u45, </tt><tt>Java 7u25 <br>
</tt><br>
I haven't seen traces for SMTP (with (bad) practice 'best
effort'), but there is the risk that they fall back to unencrypted
traffic, if a chosen Cipher failes.<br>
Has anyone traced that, yet?<br>
(please see discussion at the End).<br>
<br>
Kind regards<br>
Torsten<br>
<br>
Am 27.04.2014 23:57, schrieb Aaron Zauner:<br>
</div>
<blockquote
cite="mid:CAN8NK9EwYc6yiW_BH=QLKbnF7ANTYjo5okvtAyOx62bvBe2sDw@mail.gmail.com"
type="cite">
<div dir="ltr"><a moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc5114">https://tools.ietf.org/html/rfc5114</a><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Apr 27, 2014 at 11:54 PM, Aaron
Zauner <span dir="ltr"><<a moz-do-not-send="true"
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>
<div class="gmail_quote">On Sun, Apr 27, 2014 at 11:33
PM, Aaron Zauner <span dir="ltr"><<a
moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
Yes, It is about the length of the parameters.<br>
<blockquote
cite="mid:CAN8NK9EwYc6yiW_BH=QLKbnF7ANTYjo5okvtAyOx62bvBe2sDw@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
See:<br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
Yes, there is no dependency on basis of the Client- and Server-Hello
Packets. But some Clients fail, if the length of the DH-Parameter
used by the Server is too long for them (>1024bits).<br>
So they simply fail (at Least with every new connection with their
1st SSL-Handshake):<br>
<a moz-do-not-send="true"
href="https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on"
target="_blank"></a><br>
According to
<a class="moz-txt-link-freetext" href="https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on">https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on</a>
and
<a class="moz-txt-link-freetext" href="https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on">https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on</a>
fails if the DHE-Parameter is > 1024 bits:<br>
<tt><tt><tt>A.5) </tt>TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
(0x16) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 112</tt><tt>
=> </tt><tt><tt> negotiated with: </tt>Android 2.3.7<br>
</tt>B.5) TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 1024
bits (p: 128, g: 1, Ys: 128) FS 112 => negotiated with:
Android 2.3.7, Java 6u45 (should work without SNI), </tt><tt>Java
7u25 + 8b132(*)</tt><br>
[*: Note: unclear why Java does not use
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (<code>0x9e</code>) as mentioned
in
<a class="moz-txt-link-freetext" href="https://www.ssllabs.com/ssltest/viewClient.html?name=Java&version=8b132">https://www.ssllabs.com/ssltest/viewClient.html?name=Java&version=8b132</a>]<br>
<br>
<tt>If </tt><tt><tt>there is no </tt></tt><tt><tt><tt>'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
(0x16)' supported by the server, or </tt>'TLS_DHE_RSA_WITH_AES_128_CBC_SHA
(0x33)' has a </tt>higher Priority than
'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)'</tt> We will get the
same for <br>
<tt><tt>A.8) </tt>TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH
2048 bits (p: 256, g: 1, Ys: 256) FS 128 </tt><tt><tt>=> </tt><tt><tt>
could negotiate with: </tt>Android 2.3.7</tt></tt><br>
<tt>B.8) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits
(p: 128, g: 1, Ys: 128) FS 128 => Should also work for
Android 2.3.7, Java 6u45 (should work without SNI), Java 7u25 +
8b132(*)<br>
<br>
</tt>No other of the SSL clients is mentioned, by ssllabs.com use
this Cipher, in this Server Order (1-10).<br>
<br>
=> what can we see for 'CipherB'<br>
So if this Cipher <tt>'TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)' </tt>gets
a lower priority than 'TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)', or if
0x33 is excluded from the Cipher List:<br>
<tt>Android 2.3.7, Java 6u45 (should work without SNI), Java 7u25,
Java 8b132(*) can use </tt>'TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)'<br>
Is this reasonable for you?<br>
<br>
List of all Clients mentioned by ssllabs for the 2 test sites (only
to see the full tests):<br>
A)
<a class="moz-txt-link-freetext" href="https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on">https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on</a><br>
<tt> 1) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits
(p: 256, g: 1, Ys: 256) FS 256</tt><tt> => negotiated with:
Android 4.4.2, OpenSSL 1.0.1e (g would be better ;-) )<br>
</tt><tt><tt> 2) </tt>TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
(0x6b) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 256</tt><tt>
=> negotiated with: Safari 6/iOS 6.0.1, Safari 7/iOS 7.1+OS X
10.9<br>
</tt><tt><tt> 3) </tt>TLS_DHE_RSA_WITH_AES_256_CBC_SHA
(0x39) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 256</tt><tt>
=> </tt><tt>negotiated with:</tt><tt> Android
4.0.4+4.1.1+4.2.2+4.3, BingPreview Dec 2013, Chrome 33/Win 7, </tt><tt><tt>Firefox
24.2.0 ESR/Win 7, Firefox 27/Win 8,</tt> <br>
Googlebot Oct 2013, OpenSSL 0.9.8y, Safari 5.1.9/OS X 10.6.8,
Safari 6.0.4/OS X 10.8.4, </tt><tt><tt>Yahoo Slurp Oct 2013<br>
</tt></tt><tt><tt>4) </tt>TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
(0x88) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 256 => </tt><tt>actually
not used by reference clients, mentioned in ssllabs.com (with the
given priority position) <br>
</tt><tt><tt> 5) </tt>TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
(0x16) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 112</tt><tt>
=> </tt><tt><tt> negotiated with: </tt>Android 2.3.7<br>
</tt><tt><tt> 6) </tt>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
(0x9e) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 128</tt><tt>
=> actually not used by reference clients, mentioned in
ssllabs.com (with the given priority position) <br>
</tt><tt><tt> 7) </tt>TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
DH 2048 bits (p: 256, g: 1, Ys: 256) FS 128 </tt><tt>=>
actually not used by reference clients, mentioned in ssllabs.com
(with the given priority position) <br>
</tt><tt><tt> 8) </tt>TLS_DHE_RSA_WITH_AES_128_CBC_SHA
(0x33) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 128 </tt><tt>=>
actually not used by reference clients, mentioned in ssllabs.com
(with the given priority position)<br>
</tt><tt><tt> 9) </tt>TLS_DHE_RSA_WITH_SEED_CBC_SHA
(0x9a) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 128</tt><tt>
=> actually not used by reference clients, mentioned in
ssllabs.com (with the given priority position)<br>
</tt><tt><tt>10) </tt>TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
(0x45) DH 2048 bits (p: 256, g: 1, Ys: 256) FS 128 </tt><tt>=>
actually not used by reference clients, mentioned in ssllabs.com
(with the given priority position)</tt><br>
<br>
B)
<a class="moz-txt-link-freetext" href="https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on">https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on</a><br>
<tt><tt> 1) </tt>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH
1024 bits (p: 128, g: 1, Ys: 128) FS 256</tt><tt> =>
negotiated with: Android 4.4.2, OpenSSL 1.0.1e (g would be better
;-) )<br>
</tt><tt><tt>2) </tt>TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
(0x6b) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt>
FS 256</tt><tt> => negotiated with: Safari 6/iOS 6.0.1,
Safari 7/iOS 7.1+OS X 10.9<br>
</tt><tt><tt>3) </tt>TLS_DHE_RSA_WITH_AES_256_CBC_SHA
(0x39) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt>
FS 256</tt><tt> => </tt><tt>negotiated with:</tt><tt>
Android 4.0.4+4.1.1+4.2.2+4.3, BingPreview Dec 2013, Chrome 33/Win
7, F</tt><tt><tt>irefox 24.2.0 ESR/Win 7, Firefox 27/Win 8,</tt> <br>
Googlebot Oct 2013, OpenSSL 0.9.8y, Safari
5.1.9/OS X 10.6.8, Safari 6.0.4/OS X 10.8.4, </tt><tt><tt>Yahoo
Slurp Oct 2013</tt></tt><tt><br>
4) </tt><tt><tt><tt></tt></tt>TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
(0x88) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt>
FS 256 => </tt><tt>actually not used by reference clients,
mentioned in ssllabs.com (with the given priority position) <br>
</tt><tt><tt>5) </tt>TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
(0x16) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt>
FS 112</tt><tt> => </tt><tt><tt> negotiated with: </tt>Android
2.3.7, Java 6u45 (should work without SNI), 7u25, 8b132<br>
</tt><tt><tt>6) </tt>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
(0x9e) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt>
FS 128</tt><tt> => actually not used by reference clients,
mentioned in ssllabs.com (with the given priority position) <br>
</tt><tt><tt>7) </tt>TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
</tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt> FS
128 </tt><tt>=> actually not used by reference clients,
mentioned in ssllabs.com (with the given priority position) <br>
</tt><tt><tt>8) </tt>TLS_DHE_RSA_WITH_AES_128_CBC_SHA
(0x33) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt>
FS 128 </tt><tt>=> Should also work for Android 2.3.7, Java
6u45 (should work without SNI), 7u25, 8b132, if higher Priority
than </tt><tt><tt>'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)'<br>
</tt> </tt><tt><tt>9) </tt>TLS_DHE_RSA_WITH_SEED_CBC_SHA
(0x9a) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys:
128)</tt> FS 128</tt><tt> => actually not used by
reference clients, mentioned in ssllabs.com (with the given
priority position)<br>
</tt><tt><tt>10) </tt>TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
(0x45) </tt><tt><tt>DH 1024 bits (p: 128, g: 1, Ys: 128)</tt>
FS 128 </tt><tt>=> actually not used by reference clients,
mentioned in ssllabs.com (with the given priority position)</tt><br>
<br>
<blockquote
cite="mid:CAN8NK9EwYc6yiW_BH=QLKbnF7ANTYjo5okvtAyOx62bvBe2sDw@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
> 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 moz-do-not-send="true"
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>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
Well it could be one source...<br>
I do think to use DH-Pamaters >200 bits is OK :-)<br>
<blockquote
cite="mid:CAN8NK9EwYc6yiW_BH=QLKbnF7ANTYjo5okvtAyOx62bvBe2sDw@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
> 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>
</blockquote>
<br>
</body>
</html>