How TLS/SSL and X.509 really works

Posted by nerdcoding on December 16, 2018

Had you anytime the necessity to create TLS secured communication between some servers. Did you play around until anything apparently seems to work, but without a real understanding of the things that are going on? Then is little blog post is for you. Here I will provide only the theoretical background that needs to be known, to understand what TLS really is, how it works and for what X.509 is used.

Cryptography Techniques

Symmetric Cryptography

Cryptography techniques are best explained with the famous Alice and Bob characters.

Symmetric Cryptography

Alice and Bob want to create an encrypted connection for sending private messages to each other.

  1. In the first step, they need to reach an agreement which cipher algorithm they would use.

  2. Then one of them creates a private key and sends it to the other. With the usage of this key messages can be encrypted and decrypted.

  3. Now Alice could encrypt a message with the private key.

  4. And then send the encrypted message to Bob.

  5. Bob, also the owner of the private key, could use this key to decrypt the message he got from Alice.

Now a third person Eve comes into play and tries to eavesdrop the messages exchanged between Alice and Bob.

Symmetric Cryptography Eavesdropping

  1. When Eve eavesdrop a message and the cipher algorithm from step 1 is considered as safe, there is no possibility for Eve to decrypt the message and read it. But obviously, the problem with symmetric cryptography is the key exchange. The key is necessary to encrypt messages so that the necessary key exchange is done on an yet unencrypted connection. For Eve it would be easy to eavesdrop the exchanged key in step 2 and later decrypt all messages on the connection.

Asymmetric Cryptography / Public-Key Cryptography

In this technique, there exists two keys, a public-key known by everyone and a private key which stays a secret and is never exchanged. Both keys depend on each other but the mathematical computing power is very costly when tried to calculate the private key from an existing public-key. Everybody could get a public-key and with that, it is possible to encrypt a message. But the decryption of that message is only possible with the associated private key.

Asymmetric Cryptography

  1. Again Alice and Bob reach an agreement which public-key cipher algorithm they would use.

  2. Bob generates a public- and private-key pair and sends the public-key to Alice.

  3. Now Alice could encrypt a message with the public-key.

  4. And then send the encrypted message to Bob.

  5. Bob, the owner of the private-key, is able to decrypt the message he got from Alice.

The key exchange problem from the symmetric cryptography is solved now. Even if the eavesdropper Eve steals the public-key during the key exchange in step 2, it is not possible for Eve to decrypt any messages on the connection. The public-key protocol is also known as Diffie–Hellman key exchange named by its inventors.

Hybrid Cryptography

Most of the time public-key cryptography is not used to encrypt messages. The reason is asymmetric cryptography is much slower than symmetric cryptography. In the real world, hybrid cryptography is used most of the time. Here with the public-key cryptography, an encrypted connection is created and then a symmetric private key could be exchanged over this connection. For all further messages, the much faster symmetric cryptography could be used.

Certificates

Digital signatures

When Alice and Bob would like to create an encrypted connection, they could use a hybrid cryptography mechanism to do so. But before Alice could start the public-key exchange Alice needs to make sure, that the person on the other end of the connection really is Bob and not someone who pretends to be Bob. For this purpose, a trusted arbitrator Trent is needed.

Asymmetric Cryptography

  1. First of all, Bob creates a key pair consists of a public- and private-key.

  2. Bob sends the public-key to Trent.

  3. Trent needs to verify, that Bob really is Bob. For example, Bob has to submit some documents confirming his identity. When Trent is certain that the public-key really is from Bob, then Trent uses his private-signature-key which is only known to him, and signs Bob’s public-key. This signed public-key is called a certificate and such a certificate contains the public-key and some information about Bob.

  4. Trust sends the certificate to Bob.

  5. When Alice wants to create a connection with Bob, first of all Bob sends his certificate to Alice.

  6. Now Alice sends the received certificate back to Trent and asks for verification. Because Trent has signed the certificate with his own private-signature-key, he can verify, that this is the original certificate that no one has manipulated. This also means that the public-key inside of the certificate really is from Bob and not from someone who pretends to be Bob, because Trent made sure in step 3 that the public-key from Bob was signed and not from someone else.

When Trent positively verifies the certificate Alice can be sure, that the public-key in the certificate is from Bob and it is safe to start a hybrid cryptography connection with this public-key.

X.509

X.509 defines an internet public-key infrastructure certificate described in RFC 5280. With an X.509 certificate, we can exchange public-keys on the internet and the digital signature makes sure, that the peer is always the person that she claims to be. Consequently, with certificates, it is possible that a server application authenticates itself to his clients. For example, we take the application https://duckduckgo.com an online search engine provided by the "Duck Duck Go Inc". This company creates a public- and private-key pair, takes the public-key and extended with some additional information a certificate signing request (CSR) is created. This CSR could be signed by an authority and thus an X.509 certificate is created. When you enter https://duckduckgo.com in the address bar of your browser, a request to the server is made which sends its certificate as a response. The browser takes this certificate and asks the signing authority if it is valid and if it is really the certificate from "Duck Duck Go Inc". The authority can determine without any doubt, that this certificate was signed by him and it was not manipulated. Finally we as a client of the search engine https://duckduckgo.com can be sure we are communicating with a server of the "Duck Duck Go Inc". The server has authenticated itself to us.

This process depends on the trustworthiness of the authority who signs a CSR and creates the certificate. There are a lot of companies who provide a signing service. Such a company is called certificate authority (CA). Browser vendors keep a list of trustworthy CAs in their browsers. So when a server application sends it’s X.509 certificate to the browser, it will check if this certificate was signed by one of this trustworthy CAs. If it is not the browser will show a warning, that the connection is not safe.

TLS/SSL

The Transport Security Layer (TLS) is a protocol which realizes hybrid cryptography system and so is able to create an encrypted network communication. The predecessor of TLS was the protocol Secure Sockets Layer (SSL). The final version of SSL was 3.0 and the further development took place under the name TLS version 1.0. The name SSL is still widespread and most of the time the names TLS and SSL could be used synonymously.

TLS is in layer 4 (transport layer) of the OSI model and uses an underlying transport protocol such as TCP.

OSI model

Especially is TLS independent of the application protocol used in layer 7, so TLS could be used together with multiple application protocols such as HTTP (⇒ HTTPS) or SMTP (⇒ SMTPS). Internally the TLS protocol consists of two sub-protocols:

  1. TLS Record Protocol
    Uses the symmetric cryptography technique to send and receive encrypted messages over a network.

  2. TLS Handshake Protocol
    Uses the asymmetric cryptography technique to create an encrypted network communication between client and server. On this encrypted connection, the TLS Record Protocol can create the symmetric encryption used for all subsequent messages. Optionally it is possible to add authentication with X.509 certificates to the TLS Handshake Protocol.

TLS Handshake Protocol

The TLS Handshake Protocol could be used for three functions:

  1. Public-key exchange

  2. Authenticates the server to the client with an X.509 server certificate.

  3. And not widely used but possible, to authenticates the client to the server with an X.509 client certificate.

Basically, all three functions could be used independently. But most of the time the public-key exchange (1) and server authentication (2) are combined with each other. When you enter https://duckduckgo.com in your browser address bar TLS creates an encrypted connection to the server and the server authenticates itself with an X.509 certificate.

When a user wants to login into a web application the user mostly authenticates itself with a combination of username and password. But alternatively, this authentication could be used with an X.509 client certificate (3) instead of the usage of username and password.

In details the TLS Handshake Protocol works as follows:

TLS Handshake Protocol

  1. A client wants to start a communication with a server, then first of all the client sends a ClientHello message to the server. This message contains:

    • TLS protocol version

    • Session ID

    • Supported encryption algorithms

    • …​

  2. The server responds with a ServerHello message.

  3. And directly after the ServerHello the servers X.509 certificate is sent to the client.

    • 3.1 (Optional) When there is no server authentication with an X.509 server certificate, then the server will not send its certificate in step 3 and instead only sends its public-key with this "server key exchange message".

    • 3.2 (Optional) If it is required, that the client authenticates itself to the server with an X.509 client certificate, the server will request a client certificate with this message.

    • 3.3 (Optional) When the server requires an X.509 client certificate for authentication of the client, the client sends its certificate with this message.

  4. The client creates a symmetric cryptography secret (key), encrypts this secret with the public-key of the server and sends it to the server.

The TLS Handshake Protocol finishes at this point. The server is authenticated to the client and both parties created a symmetrically encrypted network connection. Now all subsequent communication could be done with the TLS Record protocol.