Transport Layer Security (TLS): it relies on Reliable Transport Layer (e.g TCP), transparently supports any application protocols.
One advantage of TLS is that it is application protocol independent. Higher level protocols can layer on top of the TLS Protocol transparently. The TLS standard, however, does not specify how upper layer protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementers of protocols which run on top of TLS.
TLS consists of two components: TLS Record Protocol & TLS Handshake Protocol
TLS Record Protocol: At the lowest layer of TLS protocol architecture, and it relies on reliable transport protocol (TCP). It provide connection security parameters (symmetric encryption, DES 3DES RC4, MD5 or SHA) per session. TLS Record protocol is used to encapsulate various higher level protocols such as TLS Handshake protocols.
The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks (2 upper right 14=16384 bytes, upper limit for the length of Record protocol’s Payload Data), optionally compresses the data (encrypted size <= 1024 bytes), applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then delivered to higher level clients.
If a TLS implementation receives a record type it does not understand, it should just ignore it.
TLS Handshake protocol: it is responsible for negotiate a series of parameters used for each session as well as the security parameters used by TLS Record Layer, which consists of below items:
- session identifier: one byte sequence uniquely identify each active or resumable session.
- peer certificate:
- compress method: optionally compress the data prior to encryption.
- cipher suite: consists of four security parameters.
Key exchange algorithm: is used to determine if and how the client and server will authenticate each other during the handshake.
Options for Key Exchange are: RSA, Diffie-Hellman, ECDH, SRP, PSK
Options for Authentication are: RSA, DSA, ECDSA
Bulk encryption algorithm: It also includes the key size and the lengths of explicit and implicit initialization vectors.
Options are: RC4, DES, 3DES, IDEA, AES.
MAC algorithm: is used to create the message digest, a cryptographic hash of each block of the message stream.
Options are: MD5 based HAMC or SHA based HMAC
pseudorandom function (PRF): is used to create the master secret, a 48-byte secret shared between the two peers in the connection. The master secret is used as a source of entropy when creating session keys, such as the one used to create the MAC .
Reference URL: http://en.wikipedia.org/wiki/Cipher_suite
- master secret; 48 byte secret shared between the client and server.
- is resumable: a flag indicating whether the session can be used to initiate new connections.
TLS Handshake Phases
- Hello Message Exchange
- Certification and Key Exchange message
Server Certification is verified by Issuer Authority in the Certification Chain, while the Client Certification is verified by Client sending a digital signature using its private key through Client Certificate Verify message.
- Change Cipher Suite and Finished message
- Client Hello and Server Hello message: The client hello and server hello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random (32 bytes = 4 bytes timestamp + 28 bytes random).
Structure of this message:
This is the identity of the session corresponding to this connection. If the ClientHello.session_id was non-empty, the server will look in its session cache for a match. If a match is found and the server is willing to establish the new connection using the specified session state, the server will respond with the same value as was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the finished messages. Otherwise this field will contain a different value identifying the new session. The server may return an empty session_id to indicate that the session will not be cached and therefore cannot be resumed. If a session is resumed, it must be resumed using the same cipher suite it was originally negotiated with.
- Server Certificate: The server must send a certificate whenever the agreed-upon key exchange method is not an anonymous one. This message will always immediately follow the server hello message.
- Server Key Exchange message: The server key exchange message is sent by the server only when the server certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This message conveys cryptographic information to allow the client to communicate the premaster secret: either an RSA public key to encrypt the premaster secret with, or a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the premaster secret.)
As additional CipherSuites are defined for TLS which include new key exchange algorithms, the server key exchange message will be sent if and only if the certificate type associated with the key exchange algorithm does not provide enough information for the client to exchange a premaster secret.
The client and server then use the random numbers (in Client and Server Hello Message) and PreMasterSecret which is transmitted in an encrypted manner to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
- Certificate Request: A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will immediately follow the Server Key Exchange message (if it is sent; otherwise, the Server Certificate message).
Alert Protocol Format:
this message can be sent at any time during the handshake and up to the closure of the session, to notify a Fatal Error or Warning. If this is used to signal a fatal error, the session will be closed immediately after sending this record, so this record is used to give a reason for this closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that the session is not reliable enough for its needs.
Reference URL: http://www.uniroma2.it/didattica/iss/deposito/4_tls.pdf