Quartz 4

Transport Layer Security (TLS)

5 min read

TCP is not secure - neither are the TCP/IP headers nor the data are encrypted or authenticated.

Transport Layer Security is used to authenticate and encrypt data on a TCP connection.

Two parts to TLS connection:

Handshake Protocol

  • TCP connection established as usual

  • SYN → SYN+ACK → ACK

  • TLS handshake protocol immediately follows

    • TLS ClientHello sent with the ACK
    • TLS ServerHello sent in response
    • TLS Finished message concludes, and carries initial secure data record

  • Adds 1-RTT to connection establishment 1.3 connection estab:

  • First data sent 2x RTT after connection establishment starts

  • Earliest response received 3x RTT after connection establishment starts

Footnote:

Note: Signals v1.2 but has an extension that signifies it is actually v1.3, because too many things break if TLS versions changes - protocol ossification, this extra field for 1.3 is only checked for by non v1.2 systems

ClientHello

This message:

  • Indicates version number (note)
  • Provides the cryptographic algorithms the client supports (a set)
  • Provides server name of connection (Not Encrypted)
  • Contains no data

TLS does not encrypt the address of where you are connecting (www.facebook.com etc. )

ServerHello

This message:

  • Indicates version number (Footnote)
  • Provides cryptographic algorithms selected by the server, from the set the client suggested.
  • Provides the server’s public key and digital signature used to verify its identity
  • Does not contain any data

Finished

  • Provides the client’s public key
  • Optionally, provides the certificate needed to authenticate the client to the server
  • May contain data sent from client to server

Record Protocol

TLS v1.3 splits the data into records, each containing bytes

  • Each record is both encrypted and authenticated; it has a sequence number
  • Can renegotiate encryption keys between records
  • TCP does not preserve record boundaries; TLS adds framing so that it does reading from a TLS connection will block until a complete record is received

This means the client and server exchange records, then send and receive data, then close connection

Cryptographic Algorithms

Client and server use the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange algorithm

  • Client sends its public key to server in ClientHello
  • Server sends its public key to client in ServerHello

The public keys are ephemeral – the client and server both generate new, randomly chosen, private keys for each connection and derive the public keys from them

Client and server both combine the two public keys with their own private key to derive the key used for the symmetric cryptography – complex mathematics; will not describe

TLS v1.3 & Limitations

Overall v1.3 has been a great success, with significant security improvents as compared to v1.2. This is due to:

  • Removed support for older or less secure encryption and key exchange algorithms
  • Removed support for secure algorithms that have been deemed too difficult to implement correctly

Some performance improvements to the initial handshake and with 0-RTT mode

Despite this, TLS v1.3 has some limitations that are hard to fix:

  • Connection establishment is still relatively slow
  • Connection establishment leaks potentially sensitive metadata
  • The protocol is ossified due to middlebox interference

TLS LEAKS METADATA TLS leaks the DNS name of the destination, in exchange for masking the IP

Protocol Ossification

Protocol Ossification

Adapting to Ossification: To combat the problems encountered during the deployment of TLS 1.3, its designers included a workaround: - Version Masquerading: TLS 1.3 messages mimic TLS 1.2 in the version field but include a special extension header indicating the true version (TLS 1.3). This approach helps avoid triggering errors in older, non-compliant systems. - Server Response: A server that understands TLS 1.3 will recognize the extension and respond appropriately, while older servers will negotiate using TLS 1.2, oblivious to the actual capabilities of the client.

0-RTT mode

How to encrypt initial data?

  • Cannot negotiate ephemeral session key for initial data → relies on data exchanged in the handshake
  • Reuse a pre-shared key agreed in previous TLS session In a previous TLS connection:
  • Server sends a PreSharedKey with a SessionTicket to identify the key When reestablishing a connection:
  • Client sends SessionTicket, data encrypted using corresponding PreSharedKey, along with ClientHello
  • The server uses SessionTicket to find saved PreSharedKey, decrypt the data
  • ClientHello and ServerHello complete usual key exchange; data sent with ServerHello and later protected using ephemeral session key → no additional round-trips due to TLS
0-RTT Risks
  • 0-RTT data sent with ClientHello using a PreSharedKey is not forward secret
  • Use of PreSharedKey links TLS connections – if session where PreSharedKey is distributed is compromised, 0-RTT data sent using that key in future connections will also be compromised
  • 0-RTT data sent with ClientHello using a PreSharedKey is subject to replay attack
    • The 0-RTT data is accepted during TLS connection establishment
    • If on-path attacker captures and replays the TCP segment with the ClientHello ClientHello and data protected with the PreSharedKey, that data will be accepted by the server again
      • The server will respond to the replay, trying to complete the handshake – this might fail
      • But – by then, the data will have been accepted
    • Ensure 0-RTT data is idempotent to avoid this risk

Record Protocol

TLS turns the TCP (TCP-IP) byte steam to a series of record which therefore provides framing of messages

Graph View

Backlinks