0

I have the requirement of configuring all of our applications to use only PFS ciphersuites where possible.

I have an application (HP Network Automation), which supports DHE key exchange (although not ECDHE), but when I limit it down to only the following two suites:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

I cannot connect via IE11, FF or Chrome.

I have looked at wireshark traces, and when I have no restrictions on the server end, the Firefox Client Hello contains 66 suites, including 6b and 67, which are the two listed above.

However, when I restrict the server to only offering the above 2 suites, my Client Hello only contains 11 suites, and doesn't include 6b or 67.

I thought the Client Hello was the first real communication, (not including TCP handshake), so how can server configuration influence the CLient Hello?

N.B. These applications can only be accessed via intranet and VPN, so we have control over which clients will connect. We don't need to offer legacy suites.

gtmcclinton
  • 197
  • 1
  • 2
  • 6
  • I doubt that the first ClientHello is from Firefox. Firefox does not offer that much cipher suites. The second test with 11 instead of 66 suites looks more like what FF does. See also [SSLLabs report](https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox&version=47&platform=Win%207&key=132) for FF 47/Windows 7 which includes only 13 ciphers. 66 looks more like some openssl test client. – Steffen Ullrich Sep 07 '16 at 11:00
  • certainly possible - I have been using openssl s_client! – gtmcclinton Sep 07 '16 at 11:26
  • Maybe got mixed up with tcpdump buffering issues! – gtmcclinton Sep 07 '16 at 11:28

2 Answers2

1

I can confirm that I have tested hardened web servers for compliance and had no issues with IE or FF negotiating these ciphers. The only hiccup is that default configuration of FF, unlike other browsers, is configured to accept AES128-based suites over AES256-based suites if both enabled.

Kirill Sinitski
  • 989
  • 6
  • 12
  • The reasoning I hear behind this is that AES256, although it has a longer bit length, is not in any practical way more secure than AES128, and is not worth the extra computation time needed. – gtmcclinton Sep 07 '16 at 14:54
  • I also heard rumours of a possible side channel attack against AES256, related to the longer computation time – gtmcclinton Sep 07 '16 at 15:05
  • I double-checked this, and realized that SHA256 support is spotty. For example, in FF type in about:config then search for security.ssl3 to see all available ciphers. I checked with PaleMoon I use and TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 isn't supported, but TLS_DHE_RSA_WITH_AES_256_CBC_SHA is. – Kirill Sinitski Sep 08 '16 at 13:21
0

If you look at the supported ciphers of IE11 and Firefox 47 on Qualys, they actually don't support these two ciphers, which was a surprise to me.

I got round it by enabling TLS_DHE_RSA_WITH_AES_128_CBC_SHA (no SHA256) for Firefox, and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for IE11

gtmcclinton
  • 197
  • 1
  • 2
  • 6