Scribd
Upload
37 views

Transport Layer Security

The document summarizes the Transport Layer Security (TLS) protocol. It describes the TLS record protocol format which includes fields for content type, version numbers, and length. It also describes the TLS alert and handshake protocols. The TLS handshake protocol allows the server and client to authenticate each other, negotiate encryption algorithms, and exchange cryptographic keys in four phases - establishment of security capabilities, server authentication and key exchange, client authentication and key exchange, and finish.

Uploaded by

M. Thirumala Reddy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
37 views

Transport Layer Security

The document summarizes the Transport Layer Security (TLS) protocol. It describes the TLS record protocol format which includes fields for content type, version numbers, and length. It also describes the TLS alert and handshake protocols. The TLS handshake protocol allows the server and client to authenticate each other, negotiate encryption algorithms, and exchange cryptographic keys in four phases - establishment of security capabilities, server authentication and key exchange, client authentication and key exchange, and finish.

Uploaded by

M. Thirumala Reddy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 45

Module 2

Transport Layer security


SSL/TLS RECORD PROTOCOL
TLS RECORD FORMAT

• Content Type (8bits): The higher layer protocol used

to process the enclosed fragment.

• Major version (8bits): For TLS v2, the value is 3.

• Minor version (8bits): For TLS v2, the value is 1.

• Compressed Length (16bit): Maximum value is

2^14+2048.
Figure: TLS Record Protocol Payload
TLS Alert Protocol
Conveys TLS-related alerts to peer entity
severity
warning or fatal

specific alert
fatal: unexpected message, bad record mac, decompression failure, handshake failure,
illegal parameter
warning: close notify, no certificate, bad certificate, unsupported certificate, certificate
revoked, certificate expired, certificate unknown

compressed & encrypted like all SSL data


HANDSHAKE PROTOCOL
TLS Handshake Protocol

SSL Handshake Protocol


• allows server & client to:
– authenticate each other
– to negotiate encryption & MAC algorithms
– to negotiate cryptographic keys to be used
• comprises a series of messages in phases
– Establish Security Capabilities
– Server Authentication and Key Exchange
– Client Authentication and Key Exchange
– Finish
Handshake Protocol- step 1
Initialization  : Client_hello: client to server
– Version = highest SSL version used by client – 32-bit timestamp + 28 bytes random (a pseudo number generator is
required)
– sessionID: = 0 new connection in new session; ≠0 update previous connection
– Cipher suite: list that contains the combinations of cryptographic algorithms supported by the client, in decreasing
order of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm and a
CipherSpec.
– Compression algorithms: ordered sequence of acceptable algorithms
 : Server_hello: server to client – ack all above (if sessionID of client = 0 generates new sessionID)
Fixed Diffie-Hellman
• Diffie-Hellman key exchange in which server's certificate contains Diffie-Hellman public
parameters signed by the certificate authority (CA).
• Client provides its Diffie-Hellman public key parameters either in a certificate, if client
authentication is required, or in a key exchange message.
• This method results in a fixed secret key between two peers, based on the Diffie Hellman
calculation using the fixed public keys.
Handshake Protocol - step 2
Server authentication and key exchange Server to client Certificate: X.509 certificate chain (optional)
Server_key_exchange (optional) a signature is created by taking the hash of a message and encrypting it with the
sender's private key.
In this case the hash is defined as hash(ClientHello.random || ServerHello.random || ServerParams) So the hash
covers also the two nonces from the initial hello messages. Certificate_request: (optional) Server_hello_done: I am
done and I wait for answers.
The server begins this phase by sending its certificate, if it needs to be authenticated; the message contains one or a
chain of X.509 certificates. • The certificate message is required for any agreed-on key exchange method except
anonymous

Diffie-Hellman. – If fixed Diffie-Hellman is used, this certificate message functions as the server's key exchange
message because it contains the server's public Diffie- Hellman parameters.
Handshake Protocol - step 3

Client authentication

• Client verifies server certificates and parameters

• Client to server Client Certificate and info to verify it: (if asked) Message for key

exchange (Client_key_exchange)
Handshake Protocol - step 4
End: go to next phase, cipher_spec
Client to server
• Message: Change_cipher_spec
• Finished message under new algorithms, keys (new cipher_spec)
Server sends back
• Message: Change_cipher_spec
• Finished message under new algorithms, keys (new cipher_spec)

You might also like