Basics
| Term | Description |
|---|---|
| Connection | Is a transport providing suitable type of service, connection is transient, associated with one session |
| Session | Association between client and server. Created by the handshake protocol. Contains security parameters that are shared between multiple connections. They are used to avoid expensive negotiation of new security parameters for each connection |
| Flight | Chunk of logically grouped data. Exchanged during handshake. Messages from the same flight may be placed in same Record |
| Record | DTLS message fragment that must fit within single IP packet. Contains sequence number and epoch. Conveyed by Record protocol |
TLS
Protocol directly above layer 4 ISO/OSI. Uses reliable transport only (TCP in general).
Main goal of TLS is to provide secure connection between parties.
Properties:
Identity exchange via use of public keys (certificates). They’re used to verify counterparts during initialization of communication. Then the session key (symmetric key) is agreed
* Privacy: data is encrypted via symmetric* cryptography (key is negotiated during TLS Handshake Protocol)
* Reliability, uses integrity checks via secure hash functions
All TLS messages are encrypted, even handshake (but with NULL protocol - so they are plain text).
Description
TLS is composed of two sub-protocols (layers), identified by Content Type field.
1. TLS Record Protocol (encapsulates handshake protocol)
2. TLS Handshake Protocol
Privacy and reliability is ensured by lower layer - TLS Record Protocol
Authentication and encryption algorithm negotiation is ensured by upper layer - TLS Handshake Protocol
Handshake protocol
Designed to authenticate peers with each other using asymmetric cryptography (one way authentication is required, mutual is optional)
Shared secret negotiation (for latter symmetric cryptography) - in general: session negotiation
Handshake protocol consists of three sub-protocols:
- Handshake Protocol
Creates the session (context of whole communication) ``` Client sends ClientHello ----------------------->
Server responds with ServerHello
<-----------------------
[or server responds with Alert if version or algorithms(ciphers) contained in ClientHello doesn't match with server's]
<-----------------------
```
There are buggy implementations of server's that close connections without sending any alert messages
At this point both sides have established following parameters:
* ProtocolVersion
* SessionID
* CipherSuite
* CompressionMethod
Server sends its Certificate and ServerKeyExchange
<-----------------------
Optional
Server may request client’s certificate (CertificateRequest)
<-----------------------
Optional
Server sends ServerHelloDone
<-----------------------
Client sends its Certificate and ClientKeyExchange
----------------------->
Client sends CertificateVerify
----------------------->
Optional, send if the certificate that client has sent “had the signing ability” (all certificates besides ones containing fixed DH parameters). CertificateVerify message contains signature of all sent/received handshake messages so far by the client. Hash and signature used in computation must be the one of those present in supported_signature_algorithms (from CertificateRequest). Client creates signature using its private key, server verifies it using client’s public key.
Client sends ChangeCipherSpec
----------------------->
With cipher it had set as pending. This cipher becomes current (explained in Change Cipher sub-section)
Client sends Finished
----------------------->
Uses new ciphers to send Finished
Server sends its own ChangeCipherSpec
<-----------------------
Server sends Finished message (using new ciphers)
<-----------------------
-
Alert Protocol
Indicates failures, associated session identifier must be invalidated. May be used to indicate connection end (via Alert(close_notify)). -
Change Cipher
Receiver of this message must instruct the Record Layer (Record Protocol) to immediately copy the read pending state into current state. Sender of this message must immediately instruct the record layer to copy pending write state to current write state.
Record Protocol
Compression/decompression, division into blocks, reassembly.
Used by Handshake Protocol.
Maintains connection state - encryption algorithm, compression algorithm and MAC algorithm.
Receiving unexpected record type results in Alert(UnexpectedMessage).
Contains information about compression, MAC and encryption for:
- current read/write states
- pending read/write states
Current are used for record processing.
To become current:
1. the pending is first agreed upon in Handshake Protocol
2. the change cipher spec message makes it current
DTLS
TLS over datagram protocols
TLS in its original form cannot be used on top of datagram transport like UDP as:
- Decrypting of individual records could be impossible. If record N is not received, then integrity check for record N+1 will fail as relies on previous sequence number
- Records depend on each other. Cryptographic context is retained between records (as stream ciphers are used).
- Handshake protocol could fail as requires all messages to be reliably delivered (no messages must be lost during handshake phase) in defined order.
Mechanisms for fitting TLS into UDP
Message loss protection: - Retransmission, if expected other-side message (for handshake phase) doesn't arrive within given time then the message is retransmitted. - Stream ciphers are prohibited as they are stateful and loosing packages breaks them (missing record disallows decryption of packets with next sequence number).
Message reordering protection: - Each message is assigned explicit sequence number. This way peer can determine if the message it receives is the next message it awaits. - Each message is also assigned epoch number. Epoch is incremented with every ChangeCipherSpec message. Usually message from previous epoch can be discarded.
DTLS record must fit in single datagram (in order to avoid IP fragmentation). As e.g. handshake messages are bigger than max record size they can be fragmented in multiple records.
Summary of TLS handshake changes for DTLS
- Stateless cookie exchange
- Message loss and reordering handling
- Retransmission timers added
Further considerations
As DTLS can use UDP the client-server relation is changed to more peer-to-peer like. Meaning that it should be possible for both parties to act like client and server simultaneously. This is useful feature. DTLS sessions can be long-lived thus e.g. when one side (that acted like server) has lost DTLS state it should be able to establish new one by sending ClientHello immediately after detecting failure
References
- RFC handshake flow
- RFC CertificateVerify details
- DTLS RFC. Mind that this RFC is presented as series of diffs from TLS RFC
- Stream cipher