4

Our current (default) Sophos firewall (Apache reverse proxy) settings does not allow Java 6 clients to connect over HTTPS. The ssltest result shows that the reason is "Client does not support DH parameters > 1024 bits".

ssltest reports with 'A' rating for other sites (e.g. https://bsi.de) prove that there are ways to configure a HTTPS firewall so that Java 6 clients are able to connect.

We contacted Sophos support. Their answer was that we should not lower our security settings. Instead, our client should consider a Java upgrade.

Both answers certainly sound reasonable. However we have no influence on the IT configuration of our client.

Question: is it possible to configure a Apache reverse proxy so that incoming Java 6 HTTPS connections are possible, without lowering security?

If I compare our server cipher suites with a server who supports Java 6 HTTPS connections, I can see that we have more ciphers enabled, so I guess that the reason for Java 6 connectivity problems is one of the extra ciphers. However I guess that removing some of DH ciphers could introduce connectivity problems with other clients.


Our client asked us to remove all DHE ciphers. These are:

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

We have several TLS_ECDHE_ ciphers installed.

A related article at https://security.stackexchange.com/questions/97750/usage-of-ephemeral-diffie-hellman-ciphers-in-2015-and-beyond says that

TLS_DHE_xxx cipher suites are not used much in the wild - Only one site (Wikipedia.org) in the top ten sites on Alexa.com actually uses them. None of the others do, instead relying on TLS_ECDHE_xxx or TLS_RSA_xxx ciphers. From this, I can only deduce that there are not many browsers out there that are affected by not using these ciphers, otherwise these large sites would be cutting people off.

So I guess it is safe to remove these ciphers if we know that no clients are require them, and see what happens.

5
  • Without lowering security? You can migrate to Java 8 ASAP. Java 6 has been EOL for years, and Java 7 is EOL already. Sep 23, 2015 at 8:28
  • @MichaelHampton our client will not migrate so soon. We have no influence on their IT configuration. The ssllabs report does not indicate that incoming HTTPS connections from Java 6 clients are unsafe.
    – mjn
    Sep 23, 2015 at 8:33
  • Yes, they are entirely unsafe. Java 6 is no longer capable of making secure connections. The workarounds your client is trying to give you only work with Java 7 clients anyway. And yes, your client is being utterly unreasonable. Sep 23, 2015 at 8:34
  • @MichaelHampton see my comment edit, sllabs reports do not indicate any major security problems with Java 6 clients
    – mjn
    Sep 23, 2015 at 8:36
  • As ssllabs.com themselves say, they simulate SSL handshakes to generate that table. This is generally reliable, but not always 100% accurate. Sep 23, 2015 at 8:42

0

You must log in to answer this question.

Browse other questions tagged .