28 January 2016
SSL and the newer version TLS are used commonly to protect people while communicating with e-commerce and online banking websites. This type of protection mitigates the risk of someone being able to observe what you are sending and receiving with the website.
Let's have an in depth look at how the protocols of SSL/TLS work when you visit a https website.
Architecture
SSL/TLS has two layers of protocols which 'sit' on top of the TCP layer (OSI layer 4). SSL/TLS is designed to make use of TCP to provide a secure end-to-end service between two parties.
As you can see from the diagram we have the Record Protocol which provides basic security services to the higher layers, such as HTTP.
The higher layer contains the protocols, Handshake Protocol, Change Cipher Spec Protocol, Alert Protocol, we will cover these in detail shortly.
Record Protocol
The two services the Record Protocol provide to SSL connections are:
Confidentiality: The Handshake Protocol establishes a shared symmetric key that is then used for encrypting the actual payload.
Message Integrity: The Handshake Protocol establishes another shared symmetric key that is used with a Message Authentication Code (MAC) for integrity and data origin authentication.
With the above in mind let's walk through the process the Record Protocol goes through when passing data up and down the stack.
Assuming we are sending data...
- The original application data is broken down into smaller blocks
- Then apply optional data compression to the block - but its rarely used and as of TLS 1.3 its support has been removed (IETF).
- A message authentication code (MAC) is applied to validate the integrity of the chunk
- The block is then encrypted
- The Record Protocol header is then added {Higher level protocol used (e.g. alert), version (e.g. 3.1 == TLS 1.0), plaintext length}
- This is then passed 'down' to TCP for processing
(The reverse of this process happens at the receiving peer connection)
Higher Level Protocols
We are now going to look at the three higher level protocols that use the Record Protocol.
Change Cipher Spec Protocol
Very simply this protocol notifies the other end of the communication to switch to communicate securely using the cipher suites agreed in the handshake.
Alert Protocol
SSL/TLS messages are transferred using this protocol, for example an invalid certificate message (bad_certificate), could be sent to the receiver via this protocol. There are two types of alerts warning and fatal.
Handshake Protocol
The handshake protocol allows both parties to agree on the the encryption and MAC algorithms, and associated keys. No payload data is transferred until the handshake completes.
The basic handshake is as follows (assuming only unilateral authentication with the server):
Let's break down these messages and see what each one is doing:
client_hello
Contains the highest version of SSL/TLS version the client supports, a random nonce generated by the client, a session ID (initial handshake will be zerod out), a list of possible cipher suites (see below) the client supports (these contain the authentication algorithm to use, encryption algorithm to use, and key agreement protocol)
Client now awaits a response from the server...
server_hello
Contains the highest version of SSL/TLS that the server supports that the client supports, a random nonce generated by the server, the session ID provided by the client or a new session id if none supplied by the client. The server chooses which cipher suite to use, for example:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
which breaks down as:
- Protocol - TLS
- Key exchange algorithm - ECDHE_RSA - Elliptic Curve Diffie Helman Ephemeral with RSA. How the client will agree on the symmetric keys.
- Encryption algorithm - AES_128_GCM - The algorithm used for encrypting the payload data with the keys agreed. AES 128 (Advanced Encryption Standard with a key length of 128 bits) and using the block mode GCM (Galois/Counter Mode), which also provides message authentication to the encrypted data.
- Pseudorandom function - SHA256 - The type of algorithm used for the generation of the master secret, which is used to seed the creation of session keys. In this cipher suite it is using the well known SHA256 hash algorithm to offer high levels of entropy.
certificate
This message contains the certificate used to sign the servers public key and any intermediate certificates in the X509 certificate chain.
server_key_exchange
Using the key agreement protocol from the cipher suite the server sends any elements it needs to the client. Example, for Ephermeral Diffie Helman this would be 3 parameters plus a signature on those parameters. The parameters are the two global DH parameters plus the servers DH public key.
server_hello_done
This indicates to the client the server is done with all the hello messages and will await a reply from the client
Now the server is done the client responds with the next part of the handshake
client_key_exchange
Similar to the server_key_exchange where by the client sends any parameters to the server, that the server may need to agree on keys.
change_cipher_spec (from client)
This is not technically part of the handshake protocol and uses the Change Cipher Spec Protocol. This tells the server than all messages coming from the client will now be encrypted and protected.
finished (from client)
Immediately after the change_cipher_spec the client sends the finished message which is now protected - The server can verify that it has the correct keys and that the integrity of all the previous messages are true by checking the final MAC which is calculated over all the previous messages sent and received from the clients perspective.
Finally the server completes the handshake
change_cipher_spec (from server)
&
finished (from server)
These are almost identical to the client versions.
We now have a SSL/TLS connection up and running! So next time you visit a website with a https:// at the beginning, such as your bank, you now know what happens in the those first few seconds.
Read other insights