Skip to content
  • There are no suggestions because the search field is empty.

SSL and TLS

Besides IPsec, SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols are common alternatives for protecting data in VPNs. SSL and TLS are versatile protocols widely used for securing data transmission in VPNs, offering compatibility and protection for various network configurations and applications, but most importantly, establishing secure communication channels over the Internet. The details on SSL and TLS are:

  • SSL: This protocol was initially developed by Netscape in the mid-1990s and was one of the first protocols to secure Internet communication. It ensures data encryption and authentication between a client and a server, typically in web-based applications and VPN software applications such as Cisco AnyConnect VPN Client. SSL is well-suited for remote access VPNs where users connect to corporate networks over the internet.
  • TLS: TLS is a standard protocol that replaces SSL due to security vulnerabilities and flaws in SSL and provides similar security features. TLS is widely used to secure various types of VPNs, including client-based and clientless remote access. Like SSL, it offers encryption, authentication, and data integrity, ensuring secure communication across different applications and services.

Public Key Infrastructure

SSL and TLS depend on Public Key Infrastructure (PKI) for secure communication. PKI relies on a trusted third party, the Certificate Authority (CA), to validate the identity of remote peers. This trust enables secure data exchange. 

The CA issues identity certificates, binding an entity's personal information and public key. Entities enroll with a PKI and obtain CA-signed identity certificates. These certificates are accepted as legitimate, and their public keys are used to establish session keys for data protection.

CA examples include internal enterprise servers or public CA vendors like DigiCert, GlobalSign, or Entrust. To illustrate, consider an ID card issued by a government agency (representing the CA). When you use it at the bank, they trust the issuer (like PKI's CA) and allow transactions. PKI operates similarly, emphasizing CA and certificate roles.

For instance, when a client connects to a server, the server presents a digital certificate containing its public key, signed by a trusted CA. The client uses this certificate to establish a secure connection and exchange a session key for symmetric encryption. 

This session key is used exclusively for that session's encryption, ensuring data privacy. PKI plays a pivotal role by providing a trusted framework for verifying the authenticity of digital certificates, allowing SSL/TLS to establish secure channels without prior knowledge of the server's identity.

Note: Keep in mind that you can also use a local CA. Using a local CA instead of a public CA offers cost-effectiveness, greater control, and  customization of certificates to meet specific needs. While not as common as public CAs, it's favored for internal networks and organizations with stringent security requirements.