Improving SSL Connectivity

Question

I have a short-lived client process that talks to the server through SSL. A process is often called and runs only for a short time (usually less than 1 second). This process is intended to be used as part of a shell script used to perform large tasks and can be called quite often.

The SSL confirmation that it runs every time it starts shows up as a significant performance bottleneck in my tests, and I would like to reduce this if possible.

One thing that comes to mind is to take the session identifier and store it somewhere (sort of like a cookie) and then reuse it on the next call, however it makes me feel awkward as I think there will be some security issues around that.

So I have a few questions

• It is a bad idea?
• Is this possible with OpenSSL?
• Are there any better ways to speed up the SSL connectivity process?

Answer 1

After the handshake, you can get SSL session information from your connection using SSL_get_session() . Then you can use i2d_SSL_SESSION() to serialize it into a form that can be written to disk.

When you need to connect to the same server, you can download session information from disk, then disconnect it with d2i_SSL_SESSION() and use SSL_set_session() to set it (up to SSL_connect() ).

The SSL session on disk should only be accessible to the user the tool is working with, and legacy sessions should be overwritten and deleted frequently.

Answer 2

You must reliably use the session cache (which supports OpenSSL), see the documentation for SSL_CTX_set_session_cache_mode , SSL_set_session and SSL_session_reused for more information on how this is achieved.

Answer 3

Perhaps you are using a persistent connection, so installation is a one-time cost?

You can ignore the connection logic so that your client code still considers that it is executing a connection / process / disconnect cycle.

Answer 4

Interestingly, I ran into an OpenSSL handshake problem only today. The Windows implementation of RAND_poll uses the Windows heap API as a source of random entropy.

Unfortunately, because of the “bug fixes” in Windows 7 (and Server 2008), the heap enumeration APIs (which now debug the APIs) can now take more than a second to call once the heap is full of allocations. This means that both SSL connections and receptions can take from 1 second to more than a few minutes.

Ticket provides some useful tips on how to fix openssl to achieve faster FAR handshakes.