0

I have an apache 2.4.10 to upgrade to 2.4.12, underlying openssl 0.9.8, with the following SSL configuration:

SSLCipherSuite DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!EXPORT
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on

With the upgrade, I want to change the cipher suites to

SSLCipherSuite DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA:DES-CBC3-SHA:DHE-RSA-AES256-CBC-SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:!EXPORT 

Versions of OpenSSL and Java are:

OpenSSL 0.9.8j-fips 07 Jan 2009

java version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
Java HotSpot(TM) 64-Bit Server VM (build 22.1-b02, mixed mode)

Obviously, everything should stay the same with all the clients. However, there is a Java 7 SE client which refuses to connect with the new Apache 2.4.12 and the new config, but works with the old one (internal error from client after Server hello done).

Does anyone have some ideas?

4
  • Have you tried to upgrade OpenSSL to the current version? You didn't indicate which version of 0.9.8 you have exactly.
    – Ramhound
    Commented Jul 2, 2015 at 12:06
  • I could gnash my teeth for having had the same proposal yesterday, already. I asked them sysadmins to upgrade to OpenSSL >1.0.0, which they refused before the year 2017. Commented Jul 2, 2015 at 13:39
  • Can you provide the information about which release of the 0.9.8 branch you are using?
    – Ramhound
    Commented Jul 2, 2015 at 14:00
  • I added the version numbers in the original question. Commented Jul 3, 2015 at 6:53

2 Answers 2

0

Not a complete answer yet, but some ideas/directions:

That cipherlist change is meaningless. The term you added TLS_DHE_RSA_WITH_AES_256_CBC_SHA is in standard RFC format, also used by Java and some other things like Wireshark, but NOT the format used by OpenSSL; the OpenSSL format is DHE-RSA-AES256-SHA which was/is already in your list. Also, !EXPORT is useless here; it would remove any export suites that had been added, but none have been, and it would prevent any further specs from adding them back, but there are no further specs.

Some early versions of Java 7 SSL (JSSE), I don't remember exactly which but probably including 7.03, did have their default cipherlist in the wrong order, which could result in selecting a poorer than necessary ciphersuite, but your SSLHonorCipherOrder on ignores the client order, so that can't be it.

Recent versions of httpd have started defaulting to larger DH groups (for DHE, which you are preferring), and that does cause problems for Java 7 (and earlier) at least using its default crypto providers. But http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile says these changes were 2.4.7 and .10, so .10 to .12 shouldn't make any further change I know of. Query: Do you in fact have DH 1024bit configured as http://httpd.apache.org/docs/2.4/ssl/ssl_faq.html#javadh suggests?

If that isn't it, I would need more data. Is anything written in the httpd log(s) when the problem occurs? Can you get more details from the Java client with the problem, like an exact exception message? (Is this a client you can run yourself, or does it belong to another person or persons?) Can you get a network capture of a failed attempt with Wireshark or tcpdump or similar? If all else fails, can someone run the Java client with -Djavax.net.debug=ssl or equivalent, and get the (rather voluminous) resulting output?

1
  • thank you so long. I will test what I can and return here as soon as I know more. I am the administrator of the Java client, but neither its developer nor the admin of the Apache server. Commented Jul 6, 2015 at 8:26
0

The paragraph stating

Some early versions of Java 7 SSL

by @dave_thompson_085 led me to the final solution. Problem and solution are both well described on the Apache website.

There is a block to be appended to the PEM file which forces certain TLS v1.0 session parameters needed by Java SE 7.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .