SSL/TLS Main Concepts
In this post I will describe the main concepts involved during an HTTPS connection. Hopefully this post might help those who want to understand or remind SSL / TLS principles or those who are struggling with SSL handshake failures.
Encryption
Encryption is the process of translating messages (based on a predefined algorithm) in such a way that only authorized parties can read it.
There are two types of encryption:
- Symmetric encryption: a key is shared between communicating parts and will be used during both steps, encryption and decryption.
- Asymmetric encryption: two keys are now involved, a public and a private one. The public key is available for anyone but the private one is known only by the owner. The encryption will be made using the public key and the decryption can be only achieved by the corresponding private key.
X.509 certificate
The main objective of a X.509 certificate is to bind a public key with the identity contained in the certificate itself.
It includes:
- A certificate version
- A serial number to uniquely identify the certificate
- The certificate public key
- A subject distinguished name to identify the certificate owner
- An issuer distinguished name to identify the certificate issuer (we will detail this notion hereafter)
- A validity period (From, To)
- Some optional extensions such as the extended key usage to identify the certificate role (client or server role) etc…
Let’s come back to the issuer notion. A certificate can be self-trusted, for example: “I swear I am the server certificate of www.mywebsite.com, you have to trust me”.
In that case, the client must blindly trust the certificate.
Or it can be also trusted by a certificate authority (CA): “I am the server certificate of www.mywebsite.com and this authority (CA) guarantees it”.
An issuer certifies the ownership of a public key by the subject distinguished name. It can be either a private or a public third-party authority such as GoDaddy, VeriSign etc…
At the end, if a certificate is trusted by other CAs, we will have this type of chain:
In this example, *.google.com is trusted by Google Internet Authority G2 (a Google’s private CA) and is itself trusted by GeoTrust Global CA (a public CA).
Last but not least, concerning the certificate generation process, everything starts from a private key.
This private key is used then to generate a public certificate (either a .CRT or .CER).
At this stage, the certificate is still self-trusted. The next step is to generate from the certificate a CSR (Certificate Signing Request) and send it to a certificate authority. This authority will certify you are really the owner of the public key (there are different levels of verification to get a certification, this is what we called the certificate class). At the end, you will receive another public certificate, this time trusted by the certificate authority.
Of course during this process the private key remains private and is not shared with the certificate authority.
One-way vs two-way SSL
There is something really important to understand, the difference between one-way SSL and two-way SSL (also called mutual SSL).
In both cases, the server has to present its SSL server certificate to let the client verify the server identity.
Indeed, if you navigate with a web browser on https://www.facebook.com, the Facebook server will send you its own server certificate. Nevertheless, you are going to use one-way SSL.
The reason is simple and concerns the authentication part. In this very example, you will be authenticated in Facebook service using credentials (basically a user/password).
With two-way SSL, the authentication will not be managed by some credentials (such as an HTTP basic authentication or a WS-Security UsernameToken for instance) but directly from a SSL client certificate (certificate authentication).
This is the main key difference between both SSL approaches. In day-to-day Internet navigation we are all using one-way SSL but with B2B exchanges the mutual SSL is way more frequent.
This is not a question of encryption security though, both approaches are secure in terms of data encryption. This is simply for the authentication part where we consider that a private key is more protected/hidden than simple credentials.
With certificate authentication, there are also simple ways to manage revocation if a certificate should no longer be trusted for instance.
SSL handshake: deep dive
In this section, we are going to dig into a two-way SSL connection.
Following the standard 3-way TCP handshake, if a client wants to send data to a server over HTTPS, it has to pass another handshake: the SSL one.
This handshake can be split into 8 different steps:
1. The client sends to the server a Client Hello to propose the SSL options: protocol, protocol version, cipher (encryption algorithm), session-specific data, and other information that the server will need.
2. The server sends to the client a Server Hello to confirm the SSL options. It is worth saying that an SSL handshake failure may occur directly during this step. If for instance the SSL (or TLS) version proposed by the client is not supported by the server, it will return an error. Or if among the cipher list proposed by the client, the server cannot support any of them, it will also return an error. If a handshake occurs during this step, you must check whether the client and the server are compatible.
3. The server sends its SSL server certificate
4. The client checks the server identity based on its SSL server certificate.
The client relies on a truststore containing all the trusted certificates (on the opposite the client keystore contains its own client certificate and the private key). If an error occurs you have to check whether the certificate has been well added in the truststore.
This verification step may depend according to the HTTP server type and its configuration. The verification can be done for instance only on the different CA. It means the HTTP server will not check if the SSL server certificate itself is trusted, but it will check if the CAs (the ones on top) are present in the truststore.
This might be a best practice because an SSL certificate has often a shorter validity period than a CA (it might simplify the operational part).
Other errors may occur at this stage, if for instance, the SSL certificate is no more valid or if the client requires receiving only certificates whose extended key usage is set to server certificate (it is normally part of the standard verification but some HTTP servers disable this very check).
5. The client sends its SSL client certificate.
6. The server checks the client identity based on its SSL client certificate. This step is similar to the fourth one. The server will also verify if the SSL client certificate is present in its truststore.
7. If the server acknowledges the client identity, the client will generate a session key, encrypt it with the SSL server certificate (the public key of course) and sends it to the server. The session key is so based on an asymmetric encryption.
The server receives the encrypted session key, decrypt it using its own private key.
Other actions may be done during this step such as the Change Cipher Spec to potentially decide on another cipher during the data transmission.
8. The client starts to send data to the server. Each packet is encrypted using the session key. This time though the encryption is symmetric because it is based on the same secret session key, shared between the client and the server.
Moreover, it is worth noting that symmetric encryption is faster than asymmetric encryption. This is the reason why we use it for data exchange.
The server receives a packet and then decrypts it with the session key.
Conclusion
For the one-way SSL, the steps are almost the same except for the fifth and sixth. Because the authentication is not based on a client certificate, these steps will not be executed during the handshake.
The session key tough is still asymmetrically encrypted using the server public key and each packet is still symmetrically encrypted.
In this post, I used SSL and TLS acronyms. Please note that, even if TLS is now the de facto standard, both protocols are structurally very similar and intends to fulfill the same security requirements:
- Server authentication based on the server certificate
- Client authentication in case of a two-way SSL/TLS connection based on the client certificate
- Confidentiality of the exchanged data
- Integrity of the exchanged data
Last but not least, if you are facing SSL handhake failure, it is often really useful to capture the network traffic (based on TCPdump or Wireshark for instance). This way you may have some clues to identify where the problem comes from. Good luck!
N.B. I am not a security expert but I spent literally days on HTTPS connection issues with external partners so I just wanted to share some knowledge :)
