Enabling SSL session reuse (important)

2015 年 9 月 3 日1,0350

An SSLsession is started by a handshake procedure that involves multiple round
trips (see the following figure). The client and server have to exchange four
messages with a latency of around 50 milliseconds each. In total, we have at least 200
milliseconds of overhead while establishing a secure connection. In addition to that,
both the client and the server need to perform public-key cryptographic operations
in order to share a common secret. These operations are computationally expensive

image

The client can request an abbreviated handshake in effect (see the following figure),
saving a full round-trip of 100 milliseconds and avoiding the most expensive part of
the full SSL handshake:

image

 

The abbreviated handshake can be accomplished either through the session identifiers
mechanism defined by RFC 5246, or through the session ticketsmechanism detailed in
RFC 5077.
To make abbreviated handshakes with session identifiers possible, the server needs
to store session parameters in a cache keyed by a session identifier. In Nginx, this
cache can be configured to be shared with all worker processes. When a client
requests an abbreviated handshake, it provides the server with a session identifier
so that it can retrieve session parameters from the cache. After that, the handshake
procedure can be shortened and public-key cryptography can be skipped.
To enable SSL session cache, use the ssl_session_cachedirective:
http {
ssl_session_cache builtin:40000;
[...]
}

 

This configuration enables SSL session caching with built-in OpenSSL session cache.
The number in the first argument (40000) specifies the size of the cache in sessions.
The built-in cache cannot be shared between worker processes. Consequently, this
reduces efficiency of SSL session reuse.
The following configuration enables SSL session caching with a cache shared
between worker processes:
http {
ssl_session_cache shared:ssl:1024k;
[...]
}
This creates a shared SSL session cache named ssland enables SSL session reuse
with this cache. The size of the cache is now specified in bytes. Each session occupies
around 300 bytes in such cache.
It is possible to perform an abbreviated SSL handshake without the server state using
an SSL session tickets mechanism. This is done by packaging session parameters into
a binary object and encrypting it with a key known only to the server. This encrypted
object is called a session ticket.
A session ticket then can be safely transferred to the client. When the client wishes
to resume a session, it presents the session ticket to the server. The server decrypts it
and extracts the session parameters.
Session ticketsare an extension of the TLS protocol and can be used with TLS 1.0 and
further (SSL is a predecessor of TLS).
To enablesession tickets, use the ssl_session_ticketsdirective:
http {
ssl_session_tickets on;
[...]
}
Naturally, both mechanisms can be enabled at once:
http {
ssl_session_cache shared:ssl:1024k;
ssl_session_tickets on;
[...]
}

 

Forsecurity reasons, cached session lifetime is limited so that session parameters
cannot be attacked while session is active. Nginx sets the default maximum SSL
session lifetime to 5 minutes. If security is not a big concern and visitors spend
considerable time on your website, you can extend the maximum session lifetime,
increasing the efficiency of SSL in effect.
The maximum SSL session lifetime is controlled by the ssl_session_timeout
directive:
http {
ssl_session_cache shared:ssl:1024k;
ssl_session_tickets on;
ssl_session_timeout 1h;
[...]
}
The preceding configuration enables both session reuse mechanisms and sets the
maximum SSL session lifetime to 1 hour

0 0