I have a java application that makes an SSL connection to a remote server.

When I run the application from my development machine (which is geographically closer to the remote server, on a different network, and is running Win7) the connection takes less than a second to complete.

When I run the application from a production machine (Solaris) the SSL connection takes more than 10 seconds to complete.

I would like to understand what I can do to speed up this connection time.

I've switched debug tracing on (with an extended printstream that logs the elapsed time):


I can see that the majority of the lost time occurs after the client has completed the Client Change Cipher Spec, between a write and a read.

<Elapsed  [4249]ms>    *** Finished
<Elapsed  [4251]ms>    ***
<Elapsed  [4251]ms>    [write] MD5 and SHA1 hashes:  len = 16
<Elapsed  [4254]ms>    Padded plaintext before ENCRYPTION:  len = 48
<Elapsed  [4258]ms>    main, WRITE: TLSv1 Handshake, length = 48
<Elapsed [11230]ms>    main, READ: TLSv1 Change Cipher Spec, length = 1
<Elapsed [11231]ms>    JsseJce: Using cipher AES/CBC/NoPadding from provider SunJCE
<Elapsed [11360]ms>    main, READ: TLSv1 Handshake, length = 48
<Elapsed [11360]ms>    Padded plaintext after DECRYPTION:  len = 48
<Elapsed [11364]ms>    *** Finished

What options can I consider to assist speeding up the handshake?

  • Updating the JRE? The server is currently running on 1.4.2.
  • Reverse DNS? I've seen some recommendations that Reverse DNS can assist to speed up an SSL Handshake. Neither my development server of the production server currently is using Reverse DNS.
  • Network troubleshooting - Indication from the network team is that the network is fine?
  • Increase CPU/Memory - Monitoring has indicated that we aren't hitting 100% of either memory or CPU during the handshake?
  • /dev/random? I've seen references that accessing /dev/random while the random data used in the handshake on solaris can be slow?

This article describes the SSL Handshake in detail – scroll down to The SSL Protocol section that has the diagram an notes explaining the 15 step process of the handshake:

This article describes shows the SSL Handshake complete with the debug messages for reference:

-- Edit
Testing on a different machine inside the problem network showed some interesting results. The first 10 steps of the SSL handshake happened twice as fast, but the delay writing during the 'finished' phase took 80% of the total elapsed handshake time.

<Elapsed  [1816]ms>    main, WRITE: TLSv1 Handshake, length = 48
<Elapsed [10078]ms>    main, READ: TLSv1 Change Cipher Spec, length = 1
  • We added a reverse DNS lookup and it appears to have given about a 20% improvement (Will retest to ensure this wasn't just an anomaly). Still looking for more improvements though.
    – Sival Dot
    Feb 23, 2012 at 22:13

2 Answers 2


Have you tried connecting from another machine at the same site, is it still as slow? Is the remote machine Solaris as well?

I would say try updating the JVM, if you can test on an identical machine first.

For reverse dns, putting an entry in /etc/hosts should be enough.

What model and OS version is the Solaris machine? Some have crypto chips you could try and see if it is enabled or not.

  • Tried another Solaris machine at same site. It is also slow which points to a network issue I guess? Upgrading the JVM is an option, but I've tested on my Dev machine with the same version and it doesn't have the same issue. I'll check the Solaris version.
    – Sival Dot
    Feb 23, 2012 at 22:57

The cause of this specific instance of this problem was a reverse DNS lookup on the server was failing.

This was triggered by a change in DNS nameservers at the client end that weren't being picked up at the server end.

This issue was able to be isolated using Wireshark on both the client and server machines, and was able to be confirmed using: dig

dig @namserverURL -x serverIP +trace

Once the DNS issues were sorted out the SSL Handshake speed was vastly improved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.