How TLS/SSL works

Introduction

Laymen explanation

If I want to communicate banking website, I want to ensure that server is not bogus, my account info is not visible to anyone, my transaction is not readable or modified by someone. Also, I should be able communicate this server without manually establishing trust. TLS protocol is designed to fulfil these requirements.

Technical explanation

Handshake

In order to establish a cryptographically secure data channel, the connection peers must agree on which cipher suites will be used and the keys used to encrypt the data. The TLS protocol specifies a well-defined handshake sequence to perform this exchange. The ingenious part of this handshake, and the reason TLS works in practice, is its use of public key cryptography (also known as asymmetric key cryptography), which allows the peers to negotiate a shared secret key without having to establish any prior knowledge of each other, and to do so over an unencrypted channel. As part of the TLS handshake, the protocol also allows both connection peers to authenticate their identity.

Packet format

Finally, with encryption and authentication in place, the TLS protocol also provides its own message framing mechanism and signs each message with a message authentication code (MAC).

Key exchange mechanism

There are multiple key exchange options available. Option for choosing RSA or Elliptic curve, option to choose Elliptic curve along with traditional key exchange of sending secret key using RSA public key of server.

DHE_RSA is important since it offers something known as Perfect Forward Secrecy, a pompous name for the following property: if your server gets thoroughly hacked, to the point that the attacker obtains a copy of the server private key, then he will also be able to decrypt past TLS sessions (which he recorded) if these sessions used RSA, while he will not be able to do so if these sessions used DHE_RSA.

RSA, Diffie-Hellman and Forward Secrecy

Due to a variety of historical and commercial reasons the RSA handshake has been the dominant key exchange mechanism in most TLS deployments. But it has a critical weakness: the same public-private key pair is used both to authenticate the server and to encrypt the symmetric session key sent to the server. As a result, if an attacker gains access to the server’s private key and listens in on the exchange, then they can decrypt the the entire session. Worse, even if an attacker does not currently have access to the private key, they can still record the encrypted session and decrypt it at a later time once they obtain the private key.

By contrast, the Diffie-Hellman key exchange allows the client and server to negotiate a shared secret without explicitly communicating it in the handshake: the server’s private key is used to sign and verify the handshake, but the established symmetric key never leaves the client or server and cannot be intercepted by a passive attacker even if they have access to the private key.

Best of all, Diffie-Hellman key exchange can be used to reduce the risk of compromise of past communication sessions: we can generate a new "ephemeral" symmetric key as part of each and every key exchange and discard the previous keys. As a result, because the ephemeral keys are never communicated and are actively renegotiated for each the new session, the worst-case scenario is that an attacker could compromise the client or server and access the session keys of the current and future sessions. However, knowing the private key, or the ephemeral key, for those session does not help attacker decrypt any of the previous sessions! The combination of Diffie-Hellman and the use of ephemeral session keys are what enables "Forward Secrecy".

TLS Session Resumption

• A client sends a ClientHello message mentioning the session id from the previous TLS connection.

• If the server recognises the session id sent by the client, then server responds with the same session id in the ServerHello message. The client uses this to recognise that a resumed handshake is being performed.

• The server now sends a ChangeCipherSpec record, essentially telling the client, "Everything I tell you from now on will be encrypted."

• Finally, the server sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.

• Finally, the client sends a ChangeCipherSpec, telling the server, "Everything I tell you from now on will be encrypted. "

• The client sends its own encrypted Finished message.

SSL session tickets vs session ids

In the last exchange of a full SSL handshake, the server can include a “New Session Ticket” message which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket.

RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid to maintain a server-side session cache since the whole session state is remembered by the client, not the server.

The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty “Session Ticket” extension in the “Client Hello” message. The server will answer with an empty “Session Ticket” extension in its “Server Hello” message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into SSL.

Reference

http://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls

https://technet.microsoft.com/en-us/library/cc785811(v=ws.10).aspx

http://chimera.labs.oreilly.com/books/1230000000545/ch04.html

https://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake

http://stackoverflow.com/questions/19939247/ssl-session-tickets-vs-session-ids