Transport Layer Security
|
|
Transport Layer Security (TLS) was designed to provide security at the transport layer. |
|
TLS was derived from a security protocol called Secure Sockets Layer (SSL), designed by Netscape to provide security on the WWW. |
|
TLS is a nonproprietary version of SSL designed by IETF. For, transactions on the Internet, a browser need the following: |
|
1. The customer needs to be sure that the server belongs to the actual vendor, not an imposter. |
|
. For example, ; |
|
a customer does not want to give an imposter her credit card number. In other words, the server must be authenticated. |
|
2. The customer needs to be sure that the contents of the message are not modified during the transition. |
|
A bill for $100 must not be changed to $1000. The integrity of the message must be preserved. |
|
3. The customer needs to be sure that an imposter does not intercept sensitive information such as a credit card number. There is a need for privacy. |
|
There are other optional security aspects that can be added to the above list. |
|
For example, |
|
the vendor may need to authenticate the customer. TLS can provide additional features to cover these aspects of security. |
|
Position of TLS |
|
TLS lies between the application layer and the transport layer (TCP), as shown in Figure |
|
 |
|
The application layer protocol, in this case HTTP, uses the services of TLS, and TLS uses the services of the transport layer. |
|
Two Protocols |
|
TLS is actually two protocols: the handshake protocol and the data exchange (sometimes called the record) protocol. |
|
Handshake Protocol |
|
The handshake protocol is responsible for negotiating security, authenticating the server to the browser, and (optionally) defining other communication parameters. |
|
The handshake protocol defines the exchange of a series of messages between the browser and server. |
|
We discuss a simplified version, as shown in Figure |
|
 |
|
1. The browser sends a hello message that includes the TLS version and some preferences. |
|
2. The server sends a certificate message that includes the public key of the server. |
|
The public key is certified by some certification authority, which means that the public key is encrypted by a CA private key. |
|
The browser has a list of CAs and their public keys. It uses the corresponding key to decrypt the certificate and finds the server public key. |
|
This also authenticates the server because the public key is certified by the CA. |
|
3. The browser generates a secret key, encrypts it with the server public key, and sends it to the server. |
|
4. The browser sends a message, encrypted by the secret key, to inform the server that handshaking is terminating from the browser side. |
|
5. The server decrypts the secret key using its private key and decrypts the message using the secret key. |
|
It then sends a message, encrypted by the secret key, to inform the browser that handshaking is terminating from the server side. |
|
Note that handshaking uses the public key for two purposes: to authenticate the server and to encrypt the secret key, which is used in the data exchange protocol. |
|
Data Exchange Protocol |
|
The data exchange (record) protocol uses the secret key to encrypt the data for secrecy and to e:1crypt the message digest for integrity. |
|
The details and specification of algorithms are agreed upon during the handshake phase. |