4.4.5. SSL, TLS
These are sets of cryptographic protocols designed to enable secure communication in the internet, SSL being first introduced by Netscape in 1995 (in version 2.0, as version 1.0 was never oficially published due to design flaws it had). TLS took over in 1999 and is constantly under development, its version 1.3 is still in draft status.
Let us first take a glance from a distance on how the SSL/TLS secure the connection. At first, the client and server execute a handshake procedure, where the server first authenticates itself and then both parties generate a common, symmetric key for further communication. For reason clarified in section on load balancing it is worth mentioning that SSL/TLS communication initialization is in L5 OSI and works in L6 OSI layers, only leveraging lower OSI layers for transportation of encrypted messages.
SSL/TLS provides
- authentication -- during handshake both parties' identities can be verified;
- message confidentiality -- messages are encrypted using a symmetric key, hence overhearing the communication does not lead to information disclosure;
- message integrity -- each message is appended with a MAC (message authentication code) based on a key shared between communicating parties: the message cannot be modified and a matching MAC calculated without the key.
Authentication
The authentication is based on X.509 certificates as described above, and the suites of algorithms available in each version of SSL/TLS are following:
Fig.4.4.5/1
Establish a symmetric key
After the server is authenticated, both communicating parites establish a symmetric key and further use it for encrypting the communication. The available block ciphers are:
- AES in GCM, CCM and CBC modes, 128 and 256 bits keys;
- DES in CBC mode with 40 (for compliance with US regulations) or 56 bits key;
- 3DES in EDE CBC modes and 112 (effective) bit key;
- Camellia in CBC and GCM modes with 128 and 256 bits keys;
- ARIA in CBC and GCM modes with 128 and 256 bits keys;
- SEED in CBC mode with 128 bits key;
- IDEA in CBC mode with 128 bits key;
- RC2 in CBC mode with 40 (for compliance with US regulations) bits key;
Even though SSL/TLS standards offer such a wide suite of ciphers to be used for securing communication, some of them have been shown to be insecure. A good overview is presented in wiki-tls but the main facts are as follows:
- The all-famous and well-known RC4 stream cipher is thoroughly insecure and, even though provided in all versions of SSL/TLS suites, should not be used.
- All implementations of ciphers offered by SSL have been proven insecure. Incidentally, the SSL 2.0 has no support for multiple-service single-client scenario, which naturally excludes its use in a cloud setting, where multiple virtual servers are supposed to serve the same client flawlessly.
- Security of the newer TLS suites depends on implementation and fixes/patches to the libraries providing the routines.
- While TLS 1.2 provides most secure application of ciphers, accepting only this version is an accessibility-limiting factor.
Here is what happens during initialization phase of TLS session.
Fig. 4.4.5/2
Notes
- Before step 5. the server can request client's certificate for two-way authentication. In such case, the client responds with its certificate before step 6. Next, before step 7. the client verifies its certificate by signing (using its secret key, which is paired with the public one in the certificate) the entire communication so far. The server can verify the signature based on data from the certificate.
- If both sides exchange the same sessionID in steps 1. and 2., they immediatelly go to step 7. using master key established for the referenced session. If the key is valid, the communication continues; otherwise the handshake must be re-established.
- Should any of the steps in the handshake fail, the connection is broken and all temporary secrets are discarded.