8.6 – Securing TCP connections: SSL

• A secure version of TCP is commonly known as Secure Sockets Layer (SSL).
  • A slightly enhanced version of SSL version 3, called Transport Layer Security (TLS), has been standardized by the IETF.
• The SSL protocol was originally designed by Netscape.
• SSL is often used to provide security over HTTP. However, because SSL secures TCP, it can be employed by any application that runs over TCP.
• SSL provides a simple Application Programmer Interface (API) with sockets, which is similar and analogous to TCP’s API.

8.6.1 – The Big Picture

• We’ll first describe a simplified version of SSL that we’ll call “almost-SSL”before we describe the full SSL.
• Almost-SSL has three phases:
  • Handshake
    • During the handshake phase, Bob needs to establish aTCP connection, verify that Alice is really Alice, and send Alice a master secret key (which will be used by both Alice and Bob to generate all the symmetric keys they need for the SSL session)
    • Once the TCP connection is established, Bob sends Alice a hello message. Alice then responds with her certificate, which contains her public key. Because the certificate has been certified by a CA, Bob knows for sure that the public key in the certificate belongs to Alice.
      • Bob then generates a Master secret (MS), encrypts the MS with Alice’s public key to create the Encrypted Master Secret (EMS), and sends the EMS to Alice.
      • Alice decrypts the EMS with her private key to get the MS.
  • Key derivation
    • The MS could be used as the symmetric session key for all subsequent encryption and data integrity checking. It is, however, generally considered safer to use different cryptographic keys, and also to use different keys for encryption and integrity checking.
    • Alice and Bob use the MS to generate 4 keys:
      • $$E_B = $$ Session encryption key for data sent from Bob to Alice
      • $$M_B = $$ Session MAC key for data sent from Bob to Alice
      • $$E_A = $$ Session encryption key for data sent from Alice to Bob
      • $$M_A = $$ Session MAC key for data sent from Alice to Bob
    • The two encryption keys will be used to encrypt data; The two MAC keys will be used to verify the integrity of the data.
  • Data transfer
    • SSL breaks the data stream into records, append a MAC to each record for integrity checking, and then encrypts the record+MAC.
    • To create the MAC, Bob inputs the record data along with the key $$M_B$$ into a hash function, as discussed in 8.3.
    • To encrypt the package record+MAC, Bob uses his session encryption key $$E_B$$. This encrypted package is then passed to TCP for transport over the Internet.
    • The approach above isn’t bullet-proof when it comes to providing data integrity for the entire message stream. Suppose that a man-in-the-middle inserts, delete and replace segments in the stream of TCP segments sent by Bob, reverse the order of the segment, adjust the TCP sequence numbers, and then send the two reverse-ordered segments to Alice.
    • Assuming that each TCP segment encapsulates exactly one record, let’s now take a look at how Alice would process these segments:
      • TCP running in Alice would think everything is fine and pass the two records to the SSL sublayer
      • SSL in Alice would decrypt the two records
      • SSL in Alice would use the MAC in each record to verify the data integrity of the two records.
      • SSL would then pass the decrypted byte stream to the two records to the application layer; but the complete byte stream received by Alice would not be in the correct order due to reversal of the records!
    • The solution to the problem above is to use sequence numbers. SSL does this as follows:
      • Bob maintains a sequence number counter, which begins at 0 and is incremented for each SSL record he sends.
      • Bob doesn’t actually include a sequence number in the MAC calculation. This, the MAC is now a hash of the data plus the MAC key $$M_B$$ plus the correct sequence number.
      • Alice tracks Bob’s sequence number, allowing her to verify the data integrity of a record by including the appropriate sequence number in the MAC calculation.
      • This use of SSL sequence numbers prevents someone from carrying out a man-in-the-middle attack, such as reordering or replaying segments.
• SSL Record:
  • The record consists of:
    • A type field
    • Version field
    • Length field
    • Data field
    • Mac field
  • The 3 first fields are not encrypted.
  • The type field indicates whether the record is a handshake message or a message that contains application data. It is also used to close the SSL connection.
  • SSL at the receiving end uses the length field to extract the SSL records out the incoming TCP byte stream.

8.6.2 – A More Complete Picture

• SSL handshake:
  • SSL does not mandate you to use a specific symmetric key algorithm, a specific public-key algorithm, or a specific MAC.
  • SSL allows you to agree on the cryptography algorithms at the beginning of the SSL session, during the handshake phase.
  • During the handshake phase, the receiver and sender send nonces to each other, which are used in the creation of the session keys.
  • The steps of the real SSL handshake are as follows:
    • The client sends a list of cryptographic algorithms it supports, along with a client nonce.
    • From the list, the server chooses a symmetric algorithm, a public key algorithm, and a MAC algorithm. It sends back to the client its choices, as well as a certificate and a server nonce.
    • The client verifies the certificate, extracts the server’s public key, generates a Pre-Master secret (PMS), encrypts the PMS with the server’s public key, and sends the encrypted PMS to the server.
    • Using the same key derivation function, the client and server independently compute the Master Secret (MS) from the PMS and nonces. The MS is then sliced up to generate the two encryption and two MAC keys. Furthermore, when the chosen symmetric cipher employs CBC, then two Initialization Vectors (IVs) (one for each side of the connections) are also obtained from the MS. Henceforth, all messages sent between client and server are encrypted and authenticated.
    • The client sends a MAC of all the handshake messages.
    • The server sends a MAC of all the handshake messages.
  • The two last steps protect the handshake from tempering.
    • In step 5 the client sends a MAC of the concatenation of all the handshake messages it sent and received. The server can compare this MAC with the MAC of the handshake messages it received and sent.
    • If there is an inconsistency, the server can terminate the connection. Similarly, the server sends a MAC of the handshake messages it has seen, allowing the client to check for inconsistencies.
  • The reason we have nonces in step 1 and 2 is because sequence numbers alone doesn’t suffice to prevent “connection replay attack”.
    • Suppose a hacker sniffs all message between Alice and Bob. The next day, the hacker masquerades as Bob and sends Alice exactly the same sequence of messages that Bob sent to Alice on the previous day.
    • If Alice doesn’t use nonces, she will respond with exactly the same sequence of messages she sent the previous day. Alice will not suspect any funny business, as each message she receives will pass the integrity check.
    • If alice is an e-commerce server, she will think that Bob is placing a second order. On the other hand, by including a nonce in the protocol, Alice will send different nonces for each TCP session, causing the encryption keys to be different on the two days. Therefore, when Alice receives played-back SSL records from the hacker, the records will fail the integrity checks, and bogus e-commerce transaction will not succeed.
  • In summary nonces are used to defent against the “connection replay attack” and sequence numbers are used to defend against replaying individual packets during an ongoing session.
• Connection closure:
  • Simply terminating the underlying TCP connection (sending a TCP FIN segment) is naïve as it opens up for “truncation attack” as an hacker could come in the middle and end the session early with a TCP FIN, and the receiver would only receive a portion of the content while he/her thought he/her received all of the data.
  • The solution is to indicate in the type field whether the record serves to terminate the SSL session. By indicating such a field, if Alice were to receive a TCP FIN before receiving a closure SSL record, she would know that something funny was going on.