Transport Layer Security

Last updated Nov 21, 2022 Edit Source

A protocol designed to provide encryption, authentication and data integrity. It is a standardisation over SSL.

• Encryption: obfuscate what is sent from one computer to another
• Authentication: verify the validity of provided identificatin
• Integrity: detect message tampering and forgery

1. TLS runs ontop of an existing TCP connection. Hence, establishing a TLS handshake requires going through the full round trip to set up a three-way handshake first.
2. The client sends a number of specifications in plain text such as the version of TLS and list of supported ciphersuites
3. The server picks the TLS protocol version, decides the ciphersuite, attaches its certificate and sends the response back
4. Client generates a new symmetric key and encrypts it with the servers public key. Up until now, the data has been exchanged in clear text with exception of the new symmetric key.
5. Server decrypts the symmetric key, checks the message integrity by verifying the MAC and returns an encrypted Finished. The entire process can add a lot of extra latency!

One way to reduce the extra latency, is to add ways to share the same negotiated secret key data between connections.

A session ID can be generated by the server and sent to the client as part of ServerHello. The server maintains its own cache of session IDs and the negotiated session parameters for each peer while the client stores the session ID and sends it in subsequent requests as an indication to the server. Modified handshake: The problem with session caching, is the requirement for servers to store and maintain IDs for thousands of unique connections every day. This causes memory issues, and challenges on cache eviction.

Session tickets removes the requirement for servers to keep client session state, by generating a session ticket record on the server and sending it to the client. This ticket includs all the session data encrypted with a secret key by the server. This ticket can then be stored on the client safely and must be presented by the client to reuse session state.

Encryption is not so useful, if one is communicating in an encrypted tunnel with an attacker. There needs to be a way to verify the peer’s idenity.

• Alice trusts Bob, and they each have each others public key
• Charlies wants to communicate with Alice. He asks Bob to sign his public key with his own private key.
• Alice can check first that Bob signed Charlie’s public key, and since she trusts Bob, also trusts Bobs decision to sign Charlie. Alice can then check the message with Charlie’s public key As long as nobody in the chain gets compromised, it allows us to build and grow the list of trusted parties.

A trusted third party trusted by both the owner of the certificate and the party relying on the certificate. They help to store and verify each certificate, so one does not need to do so manually for every single website. The browser specifies which root CAs to trust, and the burden is then on the CA to verify each site they sign: