How SSL and TLS secure network transactions

SSL and TLS are protocols that were developed primarily to protect Web transactions, but they can be used to protect any type of network traffic that utilizes TCP at the transport layer, including the popular SSL VPN. In this tip, learn how SSL and TLS were developed and how they work.

If you are evaluating or using a Secure Sockets Layer (SSL) VPN, you may want to know exactly how SSL works, and...

what types of attacks it protects against.

SSL, a protocol used to secure network transactions, was developed by Netscape in the mid-90s. Its successor, Transport Layer Security (TLS), was developed by the Internet Engineering Task Force as an enhancement to SSL. The basic operation of the two protocols is the same, but TLS incorporates improvements found as SSL became widely used. TLS 1.0 is documented in RFC 2246. TLS 1.1, defined in RFC 4346, corrects some vulnerabilities in the earlier version.

SSL and TLS were developed primarily to protect Web transactions, but they can be used to protect any type of network traffic that utilizes TCP at the transport layer. Both SSL and TLS are located above TCP in the protocol stack. Applications that interface with TCP when security is not required interface with SSL or TLS when security is required.

The position of the protocols above TCP means protocol data can traverse a firewall using Network Address Translation (NAT). But an application must be specifically designed for SSL or TLS, since internal logic in the application must determine when to utilize the protocols or when to make calls to TCP directly. All commonly used browsers support both SSL and TLS. SSL VPN vendors provide support for other applications.

The first step in creating a secure connection is making sure you are connecting to the intended endpoint. The process of verifying the identity of the other endpoint is called authentication. SSL and TLS use X.509 certificates along with public key encryption for authentication. Certificates are created by certificate authorities (CA). Client software maintains a list of approved CAs.

Software acting as an SSL or TLS client requests a connection with a server. The server responds by sending its certificate. The client verifies that it has connected with the desired party by examining the certificate. The certificate contains the server's domain name, the server's public key, the domain name of the issuing CA and the issuing CA's digital signature. The client:

  1. Checks that the CA issuing the certificate is on its list of approved CAs.
  2. If it is, the client uses the CA's public key, included in the approved CA list, along with the CA's digital signature to verify that the certificate has not been altered since it was created by the CA.
  3. Finally, the client checks that the server's domain name supplied in the certificate matches the domain name of the requested server.
  4. If authentication of the client is required, the server follows the same steps as those described above.

Once the identity of the endpoints is verified, data may begin to flow. Symmetric key encryption is employed instead of continuing to use public key encryption to reduce the high computation load required by public key. SSL and TLS also use message authentication codes (MACs) to protect against man-in-the-middle attacks, in which the data is intercepted and modified between the sender and receiver.

The development of SSL and TLS relied upon years of careful development of authentication, encryption and MAC techniques, but they have made e-commerce possible. The fact that the protocols are implemented in browsers has also made SSL VPNs easy to use.

About the author:
David B. Jacobs has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted for Fortune 500 companies as well as software startups.

Next Steps

SSL or IPsec VPNs: Considerations for comparison

Industry welcomes next-gen TLS VPN

VPNs for disaster recovery: IPsec vs. SSL

This was last published in October 2006

Dig Deeper on Remote access

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.