SSL (Secure Sockets Layer) and TLS (Transport Layer Security)

SSL (Secure Sockets Layer) and TLS (Transport Layer Security)

The SSL and TLS protocols enable two parties to identify and authenticate each other and communicate with confidentiality and data integrity. The TLS protocol evolved from the Netscape SSL 3.0 protocol but TLS and SSL do not interoperate.

Secure Sockets Layer (SSL) is a computer networking protocol for securing connections between network application clients and servers over an insecure network, such as the internet. Due to numerous protocol and implementation flaws and vulnerabilities, SSL was deprecated for use on the internet by the Internet Engineering Task Force (IETF) in 2015 and has been replaced by the Transport Layer Security (TLS) protocol. While TLS and SSL are not interoperable, TLS is backwards-compatible with SSL 3.0.

SSL/TLS is a collection of protocols. Weaknesses have been identified with earlier SSL protocols, including SSLv2 and SSLv3, hence SSL versions 1, 2, and 3 should not longer be used. The best practice for transport layer protection is to only provide support for the TLS protocols - TLS 1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations.

Nearly all modern browsers support at least TLS 1.0. As of February 2014, contemporary browsers (Chrome v20+, Firefox v27+, IE v8+, Opera v10+, and Safari v5+) support TLS 1.1 and TLS 1.2. You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients that support these protocols. The client and server (usually) negotiate the best protocol that is supported on both sides.

Refer to : https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet (TLS)

 

 

Basic steps in the messages exchanged during the SSL/TLS handshake, (Referred from NIST Guide) 

  • “The client sends the server the client’s SSL/TLS version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL/TLS.”
  • “The server sends the client the server’s SSL/TLS version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL/TLS. The server also sends its own certificate and, if the client is requesting a server resource that requires client  authentication, requests the client’s certificate.” 
  • “The client uses some of the information sent by the server to authenticate the server. If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client goes on to  Step 4.”
  • “Using all data generated in the handshake to this point, the client (with the cooperation of the server, depending on the cipher being used) creates the premaster secret for the session, encrypts it with the server’s public key (obtained from the server’s certificate, sent in Step 2), and sends the encrypted premaster secret to the server.”
  • “If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server, along with the encrypted premaster secret.”
  • “If the server has requested client authentication, the server attempts to authenticate the client. If the client cannot be authenticated, the session is terminated. If the client can be successfully authenticated, the server uses its private key to decrypt the premaster secret, then performs a series of steps (which the client also performs, starting from the same premaster secret) to generate the master secret.”
  • “Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL/TLS session and to verify its integrity—that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL/TLS connection.”
  • “The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.”
  • “The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.”
  • “The SSL/TLS handshake is now complete, and the SSL/TLS session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.” 

Guidelines on Securing Public Web Servers which is recommended by National Institute of Standards and Technology(NIST), 

Refer to : http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-44ver2.pdf

IETF – RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)

 

Refer to : https://tools.ietf.org/html/rfc5246https://www.owasp.org/index.php/SSL_TLS_Knowledge_Center

OWASP SSL TLS Knowledge Center

Refer to : https://www.owasp.org/index.php/SSL_TLS_Knowledge_Center

Leave a comment