1. Introduction
SSL (Secure Sockets Layer) is a protocol that provides encryption and authentication for data transmitted over a network. SSL is widely used to secure web traffic, email, online banking, and other sensitive applications.
In this tutorial, we’ll discuss how much overhead SSL imposes on a network and servers.
2. Overhead
A network overhead consists of the data and resources required for controlling and managing a network. While overhead is necessary to keep networks running smoothly, too much of it degrades performance.
Further, during the SSL handshake, the asymmetric cryptography increases SSL overhead. The exact amount of overhead depends on various factors, such as:
- Data type and size
- Encryption algorithm
- Key length
- Certificate chain length
- Network latency
- Hardware acceleration
- Session resumption
- Online Certificate Status Protocol (OCSP) stapling
3. Overhead Types
The two main overhead types are the computational overhead and bandwidth overhead.
3.1. Computational Overhead
A computational overhead refers to the extra processing time required to encrypt and decrypt data and verify certificates and signatures.
Let’s take an example of the increased latency introduced by switching HTTP to HTTPS:
The availability of SSL hardware acceleration also determines the computational overhead. Furthermore, many current processors include instructions or coprocessors that can accelerate encryption, decryption, and hashing operations.
Intel’s AES-NI instruction set, for example, can cut CPU time for AES encryption by up to tenfold. Similarly, some network cards or appliances include dedicated SSL accelerators that can offload some or all of the server’s SSL processing.
Additionally, with best practices like early termination, Cache-Control, and HTTP/2 in place, we can overcome factors like TLS handshake delay and additional roundtrips. Furthermore, new protocols and faster connections are available to compensate for these delays.
3.2. Bandwidth Overhead
Bandwidth overhead refers to the additional bytes added to data packets to carry encryption keys, certificates, and other information.
Let’s discuss an SSL handshake example:
An SSL handshake establishes a secure connection between a server and a client. The server and client exchange public keys, issuer names, validity terms, and signatures. However, the more certificates they use, the more bytes are added to network traffic.
Further, the number and size of the certificates also affect the bandwidth overhead.
Additionally, session resumption and OCSP stapling can minimize bandwidth overhead. Session resumption allows the server and client to reuse an existing SSL session without repeating the entire SSL handshake process.
3.3. Computational Overhead vs. Bandwidth Overhead
One of the trade-offs in distributed system design is between computational overhead and bandwidth overhead:
Different techniques used in distributed systems are suitable for different scenarios. The choice depends on the available resources and the performance requirements.
4. What Factors Add Overhead?
Some of the factors that contribute to SSL overhead are encryption, decryption, the initial handshake, and additional headers and padding.
4.1. Encryption and Decryption
The server and the client must perform encryption and decryption operations on the data, which consume CPU cycles and memory. The encryption and decryption time depends on the algorithm and key length used, as well as hardware capabilities.
Let’s take an example of AES (Advanced Encryption Standard) Cipher block chaining – message authentication code (CCM) mode:
The processing time increases as a result of using AES encryption/decryption. Further, four-byte padding was added per packet for Message Integrity Check (MIC).
Modern hardware often supports hardware acceleration for encryption and decryption, which can reduce the processing time significantly.
4.2. Data Size
The encrypted data is usually larger than the original data because of the padding and the additional headers added by SSL. The data size increase depends on the encryption algorithm and mode used, as well as the size of the original data.
Here are some examples of data size overhead due to SSL:
- AES in CBC (Cipher Block Chaining) mode adds 16 bytes of padding for each block
- AES in GCM (Galois/Counter Mode) adds 16 bytes of authentication tag for each block.
- SSL headers add another 5 bytes for each record of data.
4.3. Network Delay
The SSL handshake requires several round trips of messages between client and server. The number of round trips depends on the SSL version and configuration, as well as whether session resumption and false start are enabled.
Furthermore, TLS 1.2 requires two round trips, but TLS 1.3 requires one.
5. Optimization
Although SSL adds some overhead to network performance and server resources, its benefits in terms of security and privacy outweigh its drawbacks in terms of overhead.
Furthermore, with correct optimization techniques, overhead can be significantly reduced or eliminated.
5.1. How to Measure Network Performance?
To minimize overhead, we first have to define how to quantify it. We can use several metrics to measure the impact of SSL overhead on the network performance:
- Throughput and latency of SSL-enabled and SSL-disabled connections
- The CPU and memory utilization of the server and the client
5.2. Session Management
SSL session management is a mechanism to establish and maintain secure connections between clients and servers.
Efficient SSL session management can reduce the handshake to one round trip and use less data for SSL. For example, we can set the minimum number of SSL sessions to reduce the overhead of creating and destroying sessions.
Further, to service multiple requests over a single SSL connection, we can use HTTP/2 or QUIC protocols.
5.3. Speeding up Encryption and Decryption
In general, encryption and decryption slow down data transfer and increase resource consumption. To speed them up, we can use shorter keys while maintaining appropriate security.
Additionally, cryptographic accelerators and SSL accelerator appliances can help speed up encryption and decryption.
5.4. Caching
Caching services serve static content over SSL. We can use a cache to store frequently accessed content on the client or intermediate servers. Further, caching reduces the number of requests that need to be encrypted and decrypted by the SSL protocol.
In turn, caching improves the network latency and overall performance.
5.5. Choosing the Optimization Techniques
Various factors such as latency, reliability, security, and scalability affect the choice of the most suitable solution.
However, no method minimizes overhead in all scenarios.
6. Conclusion
In this article, we discussed how SSL overhead affects the communication between a client and a server. Furthermore, we have analyzed the trade-off between computational overhead and bandwidth overhead in various techniques.
In general, however, SSL overhead is relatively low and manageable compared to its security and privacy benefits. Therefore, it is recommended to use SSL whenever possible for sensitive applications.