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 ms> *** Finished <Elapsed ms> *** <Elapsed ms> [write] MD5 and SHA1 hashes: len = 16 <Elapsed ms> Padded plaintext before ENCRYPTION: len = 48 <Elapsed ms> main, WRITE: TLSv1 Handshake, length = 48 <Elapsed ms> main, READ: TLSv1 Change Cipher Spec, length = 1 <Elapsed ms> JsseJce: Using cipher AES/CBC/NoPadding from provider SunJCE <Elapsed ms> main, READ: TLSv1 Handshake, length = 48 <Elapsed ms> Padded plaintext after DECRYPTION: len = 48 <Elapsed 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:
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 ms> main, WRITE: TLSv1 Handshake, length = 48 <Elapsed ms> main, READ: TLSv1 Change Cipher Spec, length = 1
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.
No related posts.
Leave a comment
- SCP transfer only modified files
- How can I automate clearing and resetting a Linux user’s home directory to a default?
- Cron expression that runs every 5 minutes from 1:30 am – 6:00 am [duplicate]
- Understanding redundant power supplies
- Is there a way for administrators to disable users from installing Firefox extensions?