Kbase 21387: Overhead Costs of Using SSL
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/16/2008 |
|
Status: Verified
GOAL:
What is the overhead costs associated with using SSL.
FIX:
One of the well-known characteristics of SSL is that it can significantly reduce application performance. This reduction can range anywhere from 25% to 73% based on the application design, the hardware it runs on, the SSL software vendor, and SSL configuration parameters. While it is very secure, that security comes at a cost.
The SSL protocol will exchange a number of messages between the Client and Server at the start of each "session". When establishing an SSL session, a minimum of 3 major operations are performed:
a) the Client authenticates the Server's identity.
b) the Client and Server agree on which cryptography algorithms to use.
c) the Client and Server exchange the key-material for the symmetric data encryption algorithm.
The authentication portion involves the use of public key cryptography and Digital Certificates.
Public key encryption is known to be very secure, but also very slow. The exchange of symmetric data encryption key-material is also based on public key encryption because it has to be secure. So it ends up with two operations that use slow cryptographic algorithms. Add to this the SSL vendor's efficiency in validating the Server's Digital Certificate and multiply it by how many Digital Certificates require validation. This will account for the amount of overhead involved in creating a single SSL session. This process hasn't changed appreciably since SSL's inception.
The symmetric data encryption keys are renegotiated on each new session for the simple reason that any encryption key can be broken, given enough time. So if someone captures SSL session data, eventually they'll decode it. To limit the liability, the amount of data that can be recovered is limited . By changing the symmetric data encryption key sooner than it takes to break it, someone's ability to crack a single key and use it over long periods of time to decrypt large amounts of data is defeated.
Once an SSL session is established, each data message exchanged between the Client and Server is cryptographically encoded with a symmetric encryption algorithm and MAC'd for security. The type of algorithms that can be used are configured by the Client and Server owners in accordance with the sensitivity of the data being exchanged. The speed of the various algorithm types can vary greatly. A more secure algorithm will run slower. The basic set of algorithms include, but are not limited to, RC2, RC4, DES, Triple-DES. Basically, the time required to send a single data message can be calculated based on the algorithm-speed, the MAC-speed, and the transmission line speed. Depending upon the routing overhead, this will remain reasonably constant so that a graph which linearly increases in time as the number of transmission bytes is increased, is obtained.
To combat the slowness of SSL due to its overhead, software developer's can take various approaches:
a) Establish the minimum number of SSL sessions between the Client and Server. Once established, hold the SSL session open and exchange the maximum number of data messages. Various opinions are given, but lean toward running an SSL session no longer than 24 hours. This time is less than what it takes to brute-force break a DES 56 bit key. So change the SSL sessions, hence the symmetric data encryption keys, every 24 hours. This can be done by either dropping and reestablishing the SSL session or, if it's supported by the SSL vendor, direct SSL to renegotiate the data encryption keys without dropping the session.
b) Use SSL session resumption. Sometimes starting and stopping SSL sessions is unavoidable. SSL allows TCP connections to be dropped and re-established by the Client within the same SSL session, therefore bypassing much of the overhead in establishing new SSL sessions. While it is much faster, it can be perceived as a security risk. SSL sessions that are resumed over a long period of time will not arbitrate new encryption keys. That gives intruders more ti.me to break the key and begin decrypting traffic.
All SSL session resumption is optional depending upon the SSL vendor and upon its use by the Client and Server application code. By default, most Servers do not turn it on, nor do Clients use it. Depending upon the application, it may not do any good.
There are a number of general rules that govern SSL session reuse. Every SSL session is cached by the Server. Each cached session has a finite lifetime (configurable) and if the Client does not resume the session within that period of time, it expires. If the session expires, it is not usable again and forces the Client to establish a full session. The session caches are also expensive in overhead time and so their size is governed. It keeps its size down by removing expired sessions and by dropping the oldest sessions even if they haven't expired yet (This may vary widely by SSL vendor). Any time the Server cannot find an SSL session the Client asks to reuse, it causes the Client to establish a full session. A large cache size and the frequency of connections may slow the Server system down more than if session reuse wasn't used. So a Server that handles a large number of Clients may not support session reuse well. Clients who allow long periods of time between Server connections also don't use session reuse well. It's likely the SSL session will have expired and the Client will have to establish a full session. These are all configurable parameters and they have to be tuned for the particular application and environment to see if it will improve performance or not.
c) Try plug-in hardware cryptographic accelerators. It speeds up the public and symmetric key cryptography and lowers session establishment overhead. SSL vendors who do support this are generally pretty prescriptive in regard to which hardware devices they support.
d) Try SSL accelerator appliances. They plug into the network between the outside network and the Client and/or Server systems. They increase SSL speed without sacrificing security. Remember that any network data between the system and the appliance is clear-text.
e) If the Client-Server configuration is static, VPNs might work. Combine http protocol with the VPN to possibly achieve greater speed and keep the security level high. However, VPNs also have configuration limitations and are not suitable for all environments. There are both software and hardware VPNs. Software VPNs result in all traffic being encrypted on the network. Hardware VPNs are typically concentrators or routers that result in the data being in clear-text between the system and the hardware device. There's a wealth of VPN information on the Web that will provide better information.
There may be other options not listed here. The best advice is to do research before writing the application. Don't assume that SSL can be dropped on top of the application to satisfy encryption requirements..