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

Mon May 5 22:42:00 CEST 2014

Hi Aaron,

Sorry for the late answer, I have been busy the last days.
Thank you for clarifying the background of the DH Parameters. I haven't dug so deep, how to set up
the DH protocol.

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
Known Canidates: Java 6u45, Java 7u25

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.
Has anyone traced that, yet?
(please see discussion at the End).

Kind regards
Torsten

Am 27.04.2014 23:57, schrieb Aaron Zauner:
> https://tools.ietf.org/html/rfc5114
>
> On Sun, Apr 27, 2014 at 11:54 PM, Aaron Zauner <azet at azet.org <mailto: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 <mailto: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.
>
Yes, It is about the length of the parameters.
>
>         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.
>
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).
So they simply fail (at Least with every new connection with their 1st SSL-Handshake):
<https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on>
According to https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on and
https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on fails if the
DHE-Parameter is > 1024 bits:
A.5) TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)       DH 2048 bits (p: 256, g: 1, Ys: 256)  FS   
112=> negotiated with: Android 2.3.7
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), Java 7u25 + 8b132(*)
[*: Note: unclear why Java does not use TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (|0x9e|) as mentioned in
https://www.ssllabs.com/ssltest/viewClient.html?name=Java&version=8b132]

If there is no 'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)' supported by the server, or
'TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)' has a higher Priority than
'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)' We will get the same for
A.8) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)        DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    128
=> could negotiate with: Android 2.3.7
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(*)

No other of the SSL clients is mentioned, by ssllabs.com use this Cipher,  in this Server Order (1-10).

=> what can we see for 'CipherB'
So if this Cipher 'TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)' gets a lower priority than 
'TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)', or if 0x33 is excluded from the Cipher List:
Android 2.3.7, Java 6u45 (should work without SNI), Java 7u25, Java 8b132(*) can use
'TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)'
Is this reasonable for you?

List of all Clients mentioned by ssllabs for the 2 test sites (only to see the full tests):
A) https://www.ssllabs.com/ssltest/analyze.html?d=dh2048.tlsfun.de&hideResults=on
 1) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)     DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    256=>
negotiated with: Android 4.4.2, OpenSSL 1.0.1e (g would be better ;-) )
 2) TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)     DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    256=>
negotiated with: Safari 6/iOS 6.0.1, Safari 7/iOS 7.1+OS X 10.9
 3) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)        DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    256=>
negotiated with:Android 4.0.4+4.1.1+4.2.2+4.3, BingPreview Dec 2013, Chrome 33/Win 7, Firefox 24.2.0
ESR/Win 7, Firefox 27/Win 8,

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, Yahoo Slurp
Oct 2013
 4) TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    256
=> actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
 5) TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)       DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    112=>
negotiated with: Android 2.3.7
 6) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)     DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    128=>
actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
 7) TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)     DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    128
=> actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
 8) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)        DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    128
=> actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
 9) TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x9a)           DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    128=>
actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
10) TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 2048 bits (p: 256, g: 1, Ys: 256)  FS    128
=> actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)

B) https://www.ssllabs.com/ssltest/analyze.html?d=dh1024.tlsfun.de&hideResults=on
 1) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)     DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    256=>
negotiated with: Android 4.4.2, OpenSSL 1.0.1e (g would be better ;-) )
 2) TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)     DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    256=>
negotiated with: Safari 6/iOS 6.0.1, Safari 7/iOS 7.1+OS X 10.9
 3) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)        DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    256=>
negotiated with:Android 4.0.4+4.1.1+4.2.2+4.3, BingPreview Dec 2013, Chrome 33/Win 7, Firefox 24.2.0
ESR/Win 7, Firefox 27/Win 8,

               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, Yahoo Slurp Oct 2013
 4) TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)   DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    256
=> actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
 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), 7u25, 8b132
 6) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)     DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    128=>
actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
 7) TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)     DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    128
=> actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
 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), 7u25, 8b132, if higher
Priority than 'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)'
 9) TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x9a)           DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    128=>
actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)
10) TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)   DH 1024 bits (p: 128, g: 1, Ys: 128)  FS    128
=> actually not used by reference clients, mentioned in ssllabs.com (with the given priority position)

>         > 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.
>
Well it could be one source...
I do think to use DH-Pamaters >200 bits is OK :-)
>
>         > 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/20140505/d408e407/attachment.html>