Mar 15, 2012

How to speed up SSLHandshake?


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
Asked by Sival Dot


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.

Answered by Sival Dot

No related posts.

Leave a comment