Transport Layer Security (TLS)
Download as PPTX, PDF10 likes13,579 views
Transport Layer Security (TLS) is a protocol that ensures privacy and security between communicating applications on the internet, succeeding the older Secure Sockets Layer (SSL). The TLS protocol consists of a handshake mechanism for authentication and key exchange, and a record protocol for securing application data. It allows for encrypted communication by negotiating cipher suites and generating session keys, thereby preventing eavesdropping and tampering.
Transport Layer Security (TLS)
- 2. Basics of TLS TLS stands for Transport Layer Security. It is an IETF standardization initiative whose goal is to come out with an Internet standard Version of SSL. IETF- Internet Engineering Task Force. There are subtle differences between SSL and TLS. However, the core idea and implementation are quite similar.
- 3. Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL). The TLS protocol is based on Netscape's SSL 3.0 protocol; however, TLS and SSL are not interoperable. The TLS protocol does contain a mechanism that allows TLS implementation to back down to SSL 3.0. The most recent browser versions support TLS.
- 4. TLS is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The TLS Record Protocol provides connection security with some encryption method such as the Data Encryption Standard (DES)- Symmentric key algorithm. The TLS Record Protocol can also be used without encryption. The TLS Handshake Protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before data is exchanged.
- 5. TLS HANDSHAKE PROTOCOL The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume secure sessions. When establishing a secure session, the Handshake Protocol manages the following: Cipher suite negotiation. Authentication of the server and optionally, the client. Session key information exchange.
- 6. Cipher Suite Negotiation The client and server make contact and choose the cipher suite that will be used throughout their message exchange. (Authentication & Encryption combination) Authentication In TLS, a server proves its identity to the client. The client might also need to prove its identity to the server. PKI, the use of public/private key pairs, is the basis of this authentication. The exact method used for authentication is determined by the cipher suite negotiated. Key Exchange The client and server exchange random numbers and a special number called the Pre-Master Secret. These numbers are combined with additional data permitting client and server to create their shared secret, called the Master Secret. The Master Secret is used by client and server to generate the write MAC secret, which is the session key used for hashing, and the write key, which is the session key used for encryption.
- 7. The TLS Handshake Protocol involves the following steps: The client sends a "Client hello" message to the server, along with the client's random value and supported cipher suites. The server responds by sending a "Server hello" message to the client, along with the server's random value. The server sends its certificate to the client for authentication and may request a certificate from the client. The server sends the "Server hello done" message. If the server has requested a certificate from the client, the client sends it. The client creates a random Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server. The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret. The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends "Client finished" message. Server receives "Change cipher spec" and switches its record layer security state to symmetric encryption using the session keys. Server sends "Server finished" message to the client. Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.
- 8. Resuming a Secure Session by Using TLS The client sends a "Client hello" message using the Session ID of the session to be resumed. The server checks its session cache for a matching Session ID. If a match is found, and the server is able to resume the session, it sends a "Server hello" message with the Session ID. Note If a session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake. Client and server must exchange "Change cipher spec" messages and send "Client finished" and "Server finished" messages. Client and server can now resume application data exchange over the secure channel.
- 9. TLS RECORD Protocol The Transport Layer Security (TLS) Record protocol secures application data using the keys created during the Handshake. The Record Protocol is responsible for securing application data and verifying its integrity and origin. It manages the following: 1. Dividing outgoing messages into manageable blocks, and reassembling incoming messages. 2. Compressing outgoing blocks and decompressing incoming blocks (optional). 3. Applying a Message Authentication Code (MAC) to outgoing messages, and verifying incoming messages using the MAC. 4. Encrypting outgoing messages and decrypting incoming messages.
- 10. When the Record Protocol & Handshake protocols are completed, the outgoing encrypted data is passed down to the Transmission Control Protocol (TCP) layer for transport.
- 11. Thank you all ! Arun Shukla [email protected]