What is Transport Layer Security?
Paul Andre de Vera
•
Aug 12, 2022
Transport Layer Security protects data passing over the public internet. Its most recognizable use is securing web traffic. Many other internet and network applications — from video conferencing to remote access — use TLS to enhance security and privacy. This article will explain the origins of TLS, how it works, and how it can be part of a modern secure access solution.
What is the Transport Layer Security protocol?
Transport Layer Security is a cryptographic protocol that creates secure, private network connections. Anyone browsing the web uses TLS whenever they visit an HTTPS-enabled website. Besides the web, TLS protects other forms of internet communications from email to messaging to video conferencing. Some virtual private network (VPN) services use TLS to secure traffic between their servers and users’ browsers. You can also see TLS in action in more modern Zero Trust secure access solutions.
SSL, TLS, and HTTPS - What’s the difference?
Although TLS and SSL get used interchangeably, they are not quite the same thing. SSL, or Secure Sockets Layer, was the first widely-adopted security protocol for web browsers. Scientists created the World Wide Web to share documentation and other reference material. Protecting passwords and credit card numbers was not top of mind.
HTTPS, which stands for Hypertext Transfer Protocol Secure, is a version of the web communication protocol enhanced with cryptographic security. SSL was the original cryptography protocol in HTTPS. As with SSL, Netscape developed HTTPS in the mid-90s before being taken over by the IETF. The IETF migrated HTTPS to TLS in 2000.
Any time you see “SSL‚ describing an application or service, you can count on it using one of the latest versions of TLS.
HTTPS, which stands for Hypertext Transfer Protocol Secure, is a version of the web communication protocol enhanced with cryptographic security. As with SSL, Netscape developed HTTPS in the mid-90s before being taken over by the IETF. SSL was the original cryptography protocol in HTTPS. The IETF migrated HTTPS to TLS in 2000.
Why is Transport Layer Security needed?
Neither the internet nor the web was designed for privacy and security. Without something like TLS, anyone could intercept your web traffic and see passwords, credit card numbers, and other personal data. Fake versions of popular websites could harvest personal data from thousands of people. Criminals could hijack your connection to hack into a company network. Transport Layer Security addresses these security risks with three core features:
Authentication: Servers must prove they are legitimate by supplying a certificate before making the TLS connection. In some cases, the client must also provide a certificate.
Data privacy: Encryption algorithms secure the data transported between a client and server.
Data integrity: TLS inspects each record it receives to confirm its data has not been modified in transit.Combining these three features helps secure internet communications against rogue websites, internet eavesdroppers, and other dangers on the public internet.
How does TLS work?
Transport layer security works in two stages: setting up a secure connection between a client and a server and then using cryptography to protect the exchanged records. A quick recap of TLS concepts will set the table for an explanation of how transport layer security works.
Asymmetric and symmetric keys
TLS uses two types of cryptographic algorithms. In asymmetric, or public-key, cryptography, the server generates a private key that stays on the server and a public key that goes to the client. Anyone with the server public key can encrypt a message but decrypting the message requires the private key, which only the server has.
Symmetric, or secret-key, cryptography uses a shared key that lets both sides encrypt and decrypt data. This approach is more efficient than asymmetric cryptography but could be compromised if a third party got hold of the shared key.
Asymmetric algorithms let TLS secure the initial exchange of symmetric keys. Encrypting the shared key ensures nobody can intercept it. Once the exchange is complete, symmetric cryptography protects all data flowing between the client and the server.
Certificates and Certificate Authorities
TLS uses digital certificates to confirm the server’s and sometimes the client’s identities. A web server’s owner receives this digital certificate from a third party, such as IdenTrust or DigiCert. Browser makers recognize these Certificate Authorities (CAs) as trusted sources. Receiving a CA-issued certificate indicates that the web server is legitimate.
What does TLS mean by layers?
Internet Protocol groups its communication methods into layers. An application layer sits at the top, followed by the transport, internet, and link layers. As you descend through the stack, you get closer to the network’s physical hardware. TLS is an application-layer protocol. Sitting between higher-level application protocols such as HTTPS and transport protocols such as TCP, it intercepts data passing between the two layers.
Inside TLS are two more layers. The handshake protocol handles the initial contact between a client and server. It authenticates the two sides, sets up the protocols they will use, and creates the secure TLS tunnel. The record protocol divides traffic into records, encrypts each one with the symmetric key, validates and decrypts incoming records, and reassembles these records into messages for the application layer.
TLS handshake protocol
When you point your web browser to an HTTPS-enabled website, it triggers a series of exchanges between your system (the client) and the web server. The exact steps will vary depending on which cryptography algorithms and certification processes the client-server relationship requires. A simplified process would look something like this:
Client: Sends the TLS versions, hash functions, and cryptography algorithms it supports.
Server: Replies with the TLS version, hash function, and cryptography algorithm the session will use along with its digital certificate and public key.
Client: Verifies the certificate with the Certificate Authority and sends a symmetric key encrypted with the server’s public key.
Client: Sends a “finished‚ message encrypted with the shared symmetric key.
Server: Sends a “finished‚ message encrypted with the shared symmetric key.
The successful exchange of finished messages completes the handshake, and the secure session begins.
TLS record protocol
The TLS record layer takes data from the system application layer and chunks it into records, passing them to the system transport layer for routing to the network. When the transport layer hands over incoming records, the TLS record layer decrypts the records and assembles them into a message for the system application layer.
Another service the record layer provides is verifying the integrity of incoming records. How the integrity check works depends on which TLS protocol the session uses. In TLS 1.2, the handshake protocol agrees on a shared hash function the client and server will use to verify data integrity.
Once connected, the record protocol verifies each record’s integrity. The sending endpoint’s TLS record protocol:
Receives message from the client application layer.
Divides message into records.
Encrypts record.
Hashes encrypted record to generate message authentication code (MAC).
Signs encrypted record with MAC.
Hands signed encrypted record to the transport layer for distribution.
Once the record arrives at the receiving endpoint, its TLS record protocol:
Hashes the encrypted record.
Compares the result to the encrypted record’s MAC.
If the MAC and the hash do not match, then TLS 1.2 terminates the connection because something tampered with the data in transit. Otherwise, the record is secure and safe for decryption.
TLS 1.3 does away with hash functions and message authentication codes. This version only uses Authenticated Encryption with Associated Data (AEAD) cryptography algorithms which have built-in integrity checks. If the decryption fails, something is wrong, and TLS 1.3 terminates the session.
How is TLS used?
We have used web browsing to discuss TLS in action because it’s how most people protect their browsing experience. When people see the closed padlock in the address bar, they know their data is protected. Google’s Chrome browser takes this a step further by flagging HTTP-only websites as not secure. These nudges in consumer behavior forced most websites to implement HTTPS and, by extension, TLS.
Other internet applications use TLS. Even though Zoom and other video apps do not use the same transport layer protocols as web browsers — UDP rather than TCP — they encrypt their data with TLS.
SSL VPNs using TLS
Browser-based virtual private networks use TLS to create secure tunnels between their servers and a browser. These services are easy to use since they do not need a dedicated app.However, the TLS protection only applies to the connection between the browser and the VPN server. Other apps cannot use the VPN connection. Some SSL VPN providers solve that issue by offering plug-ins or client apps that extend the VPN beyond the browser.
This limitation may not matter when businesses use an SSL VPN as a remote access solution — as long as their business apps use web technologies. With an SSL VPN, users get encrypted access through the company’s VPN gateway to internally-hosted or cloud-hosted web apps. This approach offers several advantages over VPNs using IPsec or OpenVPN:
Users only need a browser to access company resources.
Less configuration and support are needed.
Simpler to implement with contractor-owned or personal devices.
User access is easier to limit to specific applications.
However, traditional VPN protocols may be more appropriate when users need to access legacy systems or when administrators need features that are only available in more capable VPN protocols.
Are any VPNs secure?
SSL VPNs may be more convenient and easier to manage than traditional VPN protocols, but they still suffer the weaknesses inherent to VPN technologies.
Consolidating all remote traffic through VPN gateways creates bottlenecks in protected networks that negatively affect bandwidth and latency. Network performance suffers even more when remote users’ access to cloud resources must round trip through the private network.VPN technologies, no matter what protocol you use, will expand your company’s attack surface. Gateways broadcast their presence on the public internet, making it easy for hackers to discover and exploit any unpatched vulnerabilities. Once compromised, the VPN gateway gives hackers full access to the network it was supposed to protect.
Twingate Zero Trust solutions and TLS
Twingate uses TLS to encrypt data exchanged by your users and protected resources within a complete Zero Trust Network Access (ZTNA) solution. Zero Trust is a modern secure access framework that significantly reduces attack surfaces while simplifying granular access control policies.
Based on the assumption that any network, resource, or device can be compromised at any time. Zero Trust shifts the focus of information security from defending network perimeters to protecting resources. Any attempt to access a resource is rejected unless explicitly verified by user identity and device posture. Policies based on the principle of least privilege limit user access to only the resources they need for their work. Zero Trust constrains hackers’ ability to leverage a breach and prevents them from moving laterally through a network.
Twingate’s Zero Trust solution creates direct, encrypted TLS connections between users and their authorized resources. The users could be in the office or at home. The resources could be on-premises or hosted in the cloud. Twingate creates a unified system that manages access across your organization.
TLS 1.2 protects connections from browsers and other applications that use the TCP transport protocol. Twingate can also deliver fast, low-latency connections using the QUIC transport layer protocol. Built upon UDP, QUIC’s multiplexed streams improve connection performance and handle network changes better than TCP. QUIC uses TLS 1.3 to keep data secure and private.
In both cases, these TLS tunnels are certificate-pinned to the protected resource’s Twingate proxy app, called the Controller.
Experience Twingate’s performance, simplicity, and security by joining our free Standard plan for individuals and small teams. Contact Twingate today to learn how easy migrating to Zero Trust Network Access can be.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
What is Transport Layer Security?
Paul Andre de Vera
•
Aug 12, 2022
Transport Layer Security protects data passing over the public internet. Its most recognizable use is securing web traffic. Many other internet and network applications — from video conferencing to remote access — use TLS to enhance security and privacy. This article will explain the origins of TLS, how it works, and how it can be part of a modern secure access solution.
What is the Transport Layer Security protocol?
Transport Layer Security is a cryptographic protocol that creates secure, private network connections. Anyone browsing the web uses TLS whenever they visit an HTTPS-enabled website. Besides the web, TLS protects other forms of internet communications from email to messaging to video conferencing. Some virtual private network (VPN) services use TLS to secure traffic between their servers and users’ browsers. You can also see TLS in action in more modern Zero Trust secure access solutions.
SSL, TLS, and HTTPS - What’s the difference?
Although TLS and SSL get used interchangeably, they are not quite the same thing. SSL, or Secure Sockets Layer, was the first widely-adopted security protocol for web browsers. Scientists created the World Wide Web to share documentation and other reference material. Protecting passwords and credit card numbers was not top of mind.
HTTPS, which stands for Hypertext Transfer Protocol Secure, is a version of the web communication protocol enhanced with cryptographic security. SSL was the original cryptography protocol in HTTPS. As with SSL, Netscape developed HTTPS in the mid-90s before being taken over by the IETF. The IETF migrated HTTPS to TLS in 2000.
Any time you see “SSL‚ describing an application or service, you can count on it using one of the latest versions of TLS.
HTTPS, which stands for Hypertext Transfer Protocol Secure, is a version of the web communication protocol enhanced with cryptographic security. As with SSL, Netscape developed HTTPS in the mid-90s before being taken over by the IETF. SSL was the original cryptography protocol in HTTPS. The IETF migrated HTTPS to TLS in 2000.
Why is Transport Layer Security needed?
Neither the internet nor the web was designed for privacy and security. Without something like TLS, anyone could intercept your web traffic and see passwords, credit card numbers, and other personal data. Fake versions of popular websites could harvest personal data from thousands of people. Criminals could hijack your connection to hack into a company network. Transport Layer Security addresses these security risks with three core features:
Authentication: Servers must prove they are legitimate by supplying a certificate before making the TLS connection. In some cases, the client must also provide a certificate.
Data privacy: Encryption algorithms secure the data transported between a client and server.
Data integrity: TLS inspects each record it receives to confirm its data has not been modified in transit.Combining these three features helps secure internet communications against rogue websites, internet eavesdroppers, and other dangers on the public internet.
How does TLS work?
Transport layer security works in two stages: setting up a secure connection between a client and a server and then using cryptography to protect the exchanged records. A quick recap of TLS concepts will set the table for an explanation of how transport layer security works.
Asymmetric and symmetric keys
TLS uses two types of cryptographic algorithms. In asymmetric, or public-key, cryptography, the server generates a private key that stays on the server and a public key that goes to the client. Anyone with the server public key can encrypt a message but decrypting the message requires the private key, which only the server has.
Symmetric, or secret-key, cryptography uses a shared key that lets both sides encrypt and decrypt data. This approach is more efficient than asymmetric cryptography but could be compromised if a third party got hold of the shared key.
Asymmetric algorithms let TLS secure the initial exchange of symmetric keys. Encrypting the shared key ensures nobody can intercept it. Once the exchange is complete, symmetric cryptography protects all data flowing between the client and the server.
Certificates and Certificate Authorities
TLS uses digital certificates to confirm the server’s and sometimes the client’s identities. A web server’s owner receives this digital certificate from a third party, such as IdenTrust or DigiCert. Browser makers recognize these Certificate Authorities (CAs) as trusted sources. Receiving a CA-issued certificate indicates that the web server is legitimate.
What does TLS mean by layers?
Internet Protocol groups its communication methods into layers. An application layer sits at the top, followed by the transport, internet, and link layers. As you descend through the stack, you get closer to the network’s physical hardware. TLS is an application-layer protocol. Sitting between higher-level application protocols such as HTTPS and transport protocols such as TCP, it intercepts data passing between the two layers.
Inside TLS are two more layers. The handshake protocol handles the initial contact between a client and server. It authenticates the two sides, sets up the protocols they will use, and creates the secure TLS tunnel. The record protocol divides traffic into records, encrypts each one with the symmetric key, validates and decrypts incoming records, and reassembles these records into messages for the application layer.
TLS handshake protocol
When you point your web browser to an HTTPS-enabled website, it triggers a series of exchanges between your system (the client) and the web server. The exact steps will vary depending on which cryptography algorithms and certification processes the client-server relationship requires. A simplified process would look something like this:
Client: Sends the TLS versions, hash functions, and cryptography algorithms it supports.
Server: Replies with the TLS version, hash function, and cryptography algorithm the session will use along with its digital certificate and public key.
Client: Verifies the certificate with the Certificate Authority and sends a symmetric key encrypted with the server’s public key.
Client: Sends a “finished‚ message encrypted with the shared symmetric key.
Server: Sends a “finished‚ message encrypted with the shared symmetric key.
The successful exchange of finished messages completes the handshake, and the secure session begins.
TLS record protocol
The TLS record layer takes data from the system application layer and chunks it into records, passing them to the system transport layer for routing to the network. When the transport layer hands over incoming records, the TLS record layer decrypts the records and assembles them into a message for the system application layer.
Another service the record layer provides is verifying the integrity of incoming records. How the integrity check works depends on which TLS protocol the session uses. In TLS 1.2, the handshake protocol agrees on a shared hash function the client and server will use to verify data integrity.
Once connected, the record protocol verifies each record’s integrity. The sending endpoint’s TLS record protocol:
Receives message from the client application layer.
Divides message into records.
Encrypts record.
Hashes encrypted record to generate message authentication code (MAC).
Signs encrypted record with MAC.
Hands signed encrypted record to the transport layer for distribution.
Once the record arrives at the receiving endpoint, its TLS record protocol:
Hashes the encrypted record.
Compares the result to the encrypted record’s MAC.
If the MAC and the hash do not match, then TLS 1.2 terminates the connection because something tampered with the data in transit. Otherwise, the record is secure and safe for decryption.
TLS 1.3 does away with hash functions and message authentication codes. This version only uses Authenticated Encryption with Associated Data (AEAD) cryptography algorithms which have built-in integrity checks. If the decryption fails, something is wrong, and TLS 1.3 terminates the session.
How is TLS used?
We have used web browsing to discuss TLS in action because it’s how most people protect their browsing experience. When people see the closed padlock in the address bar, they know their data is protected. Google’s Chrome browser takes this a step further by flagging HTTP-only websites as not secure. These nudges in consumer behavior forced most websites to implement HTTPS and, by extension, TLS.
Other internet applications use TLS. Even though Zoom and other video apps do not use the same transport layer protocols as web browsers — UDP rather than TCP — they encrypt their data with TLS.
SSL VPNs using TLS
Browser-based virtual private networks use TLS to create secure tunnels between their servers and a browser. These services are easy to use since they do not need a dedicated app.However, the TLS protection only applies to the connection between the browser and the VPN server. Other apps cannot use the VPN connection. Some SSL VPN providers solve that issue by offering plug-ins or client apps that extend the VPN beyond the browser.
This limitation may not matter when businesses use an SSL VPN as a remote access solution — as long as their business apps use web technologies. With an SSL VPN, users get encrypted access through the company’s VPN gateway to internally-hosted or cloud-hosted web apps. This approach offers several advantages over VPNs using IPsec or OpenVPN:
Users only need a browser to access company resources.
Less configuration and support are needed.
Simpler to implement with contractor-owned or personal devices.
User access is easier to limit to specific applications.
However, traditional VPN protocols may be more appropriate when users need to access legacy systems or when administrators need features that are only available in more capable VPN protocols.
Are any VPNs secure?
SSL VPNs may be more convenient and easier to manage than traditional VPN protocols, but they still suffer the weaknesses inherent to VPN technologies.
Consolidating all remote traffic through VPN gateways creates bottlenecks in protected networks that negatively affect bandwidth and latency. Network performance suffers even more when remote users’ access to cloud resources must round trip through the private network.VPN technologies, no matter what protocol you use, will expand your company’s attack surface. Gateways broadcast their presence on the public internet, making it easy for hackers to discover and exploit any unpatched vulnerabilities. Once compromised, the VPN gateway gives hackers full access to the network it was supposed to protect.
Twingate Zero Trust solutions and TLS
Twingate uses TLS to encrypt data exchanged by your users and protected resources within a complete Zero Trust Network Access (ZTNA) solution. Zero Trust is a modern secure access framework that significantly reduces attack surfaces while simplifying granular access control policies.
Based on the assumption that any network, resource, or device can be compromised at any time. Zero Trust shifts the focus of information security from defending network perimeters to protecting resources. Any attempt to access a resource is rejected unless explicitly verified by user identity and device posture. Policies based on the principle of least privilege limit user access to only the resources they need for their work. Zero Trust constrains hackers’ ability to leverage a breach and prevents them from moving laterally through a network.
Twingate’s Zero Trust solution creates direct, encrypted TLS connections between users and their authorized resources. The users could be in the office or at home. The resources could be on-premises or hosted in the cloud. Twingate creates a unified system that manages access across your organization.
TLS 1.2 protects connections from browsers and other applications that use the TCP transport protocol. Twingate can also deliver fast, low-latency connections using the QUIC transport layer protocol. Built upon UDP, QUIC’s multiplexed streams improve connection performance and handle network changes better than TCP. QUIC uses TLS 1.3 to keep data secure and private.
In both cases, these TLS tunnels are certificate-pinned to the protected resource’s Twingate proxy app, called the Controller.
Experience Twingate’s performance, simplicity, and security by joining our free Standard plan for individuals and small teams. Contact Twingate today to learn how easy migrating to Zero Trust Network Access can be.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
What is Transport Layer Security?
Paul Andre de Vera
•
Aug 12, 2022
Transport Layer Security protects data passing over the public internet. Its most recognizable use is securing web traffic. Many other internet and network applications — from video conferencing to remote access — use TLS to enhance security and privacy. This article will explain the origins of TLS, how it works, and how it can be part of a modern secure access solution.
What is the Transport Layer Security protocol?
Transport Layer Security is a cryptographic protocol that creates secure, private network connections. Anyone browsing the web uses TLS whenever they visit an HTTPS-enabled website. Besides the web, TLS protects other forms of internet communications from email to messaging to video conferencing. Some virtual private network (VPN) services use TLS to secure traffic between their servers and users’ browsers. You can also see TLS in action in more modern Zero Trust secure access solutions.
SSL, TLS, and HTTPS - What’s the difference?
Although TLS and SSL get used interchangeably, they are not quite the same thing. SSL, or Secure Sockets Layer, was the first widely-adopted security protocol for web browsers. Scientists created the World Wide Web to share documentation and other reference material. Protecting passwords and credit card numbers was not top of mind.
HTTPS, which stands for Hypertext Transfer Protocol Secure, is a version of the web communication protocol enhanced with cryptographic security. SSL was the original cryptography protocol in HTTPS. As with SSL, Netscape developed HTTPS in the mid-90s before being taken over by the IETF. The IETF migrated HTTPS to TLS in 2000.
Any time you see “SSL‚ describing an application or service, you can count on it using one of the latest versions of TLS.
HTTPS, which stands for Hypertext Transfer Protocol Secure, is a version of the web communication protocol enhanced with cryptographic security. As with SSL, Netscape developed HTTPS in the mid-90s before being taken over by the IETF. SSL was the original cryptography protocol in HTTPS. The IETF migrated HTTPS to TLS in 2000.
Why is Transport Layer Security needed?
Neither the internet nor the web was designed for privacy and security. Without something like TLS, anyone could intercept your web traffic and see passwords, credit card numbers, and other personal data. Fake versions of popular websites could harvest personal data from thousands of people. Criminals could hijack your connection to hack into a company network. Transport Layer Security addresses these security risks with three core features:
Authentication: Servers must prove they are legitimate by supplying a certificate before making the TLS connection. In some cases, the client must also provide a certificate.
Data privacy: Encryption algorithms secure the data transported between a client and server.
Data integrity: TLS inspects each record it receives to confirm its data has not been modified in transit.Combining these three features helps secure internet communications against rogue websites, internet eavesdroppers, and other dangers on the public internet.
How does TLS work?
Transport layer security works in two stages: setting up a secure connection between a client and a server and then using cryptography to protect the exchanged records. A quick recap of TLS concepts will set the table for an explanation of how transport layer security works.
Asymmetric and symmetric keys
TLS uses two types of cryptographic algorithms. In asymmetric, or public-key, cryptography, the server generates a private key that stays on the server and a public key that goes to the client. Anyone with the server public key can encrypt a message but decrypting the message requires the private key, which only the server has.
Symmetric, or secret-key, cryptography uses a shared key that lets both sides encrypt and decrypt data. This approach is more efficient than asymmetric cryptography but could be compromised if a third party got hold of the shared key.
Asymmetric algorithms let TLS secure the initial exchange of symmetric keys. Encrypting the shared key ensures nobody can intercept it. Once the exchange is complete, symmetric cryptography protects all data flowing between the client and the server.
Certificates and Certificate Authorities
TLS uses digital certificates to confirm the server’s and sometimes the client’s identities. A web server’s owner receives this digital certificate from a third party, such as IdenTrust or DigiCert. Browser makers recognize these Certificate Authorities (CAs) as trusted sources. Receiving a CA-issued certificate indicates that the web server is legitimate.
What does TLS mean by layers?
Internet Protocol groups its communication methods into layers. An application layer sits at the top, followed by the transport, internet, and link layers. As you descend through the stack, you get closer to the network’s physical hardware. TLS is an application-layer protocol. Sitting between higher-level application protocols such as HTTPS and transport protocols such as TCP, it intercepts data passing between the two layers.
Inside TLS are two more layers. The handshake protocol handles the initial contact between a client and server. It authenticates the two sides, sets up the protocols they will use, and creates the secure TLS tunnel. The record protocol divides traffic into records, encrypts each one with the symmetric key, validates and decrypts incoming records, and reassembles these records into messages for the application layer.
TLS handshake protocol
When you point your web browser to an HTTPS-enabled website, it triggers a series of exchanges between your system (the client) and the web server. The exact steps will vary depending on which cryptography algorithms and certification processes the client-server relationship requires. A simplified process would look something like this:
Client: Sends the TLS versions, hash functions, and cryptography algorithms it supports.
Server: Replies with the TLS version, hash function, and cryptography algorithm the session will use along with its digital certificate and public key.
Client: Verifies the certificate with the Certificate Authority and sends a symmetric key encrypted with the server’s public key.
Client: Sends a “finished‚ message encrypted with the shared symmetric key.
Server: Sends a “finished‚ message encrypted with the shared symmetric key.
The successful exchange of finished messages completes the handshake, and the secure session begins.
TLS record protocol
The TLS record layer takes data from the system application layer and chunks it into records, passing them to the system transport layer for routing to the network. When the transport layer hands over incoming records, the TLS record layer decrypts the records and assembles them into a message for the system application layer.
Another service the record layer provides is verifying the integrity of incoming records. How the integrity check works depends on which TLS protocol the session uses. In TLS 1.2, the handshake protocol agrees on a shared hash function the client and server will use to verify data integrity.
Once connected, the record protocol verifies each record’s integrity. The sending endpoint’s TLS record protocol:
Receives message from the client application layer.
Divides message into records.
Encrypts record.
Hashes encrypted record to generate message authentication code (MAC).
Signs encrypted record with MAC.
Hands signed encrypted record to the transport layer for distribution.
Once the record arrives at the receiving endpoint, its TLS record protocol:
Hashes the encrypted record.
Compares the result to the encrypted record’s MAC.
If the MAC and the hash do not match, then TLS 1.2 terminates the connection because something tampered with the data in transit. Otherwise, the record is secure and safe for decryption.
TLS 1.3 does away with hash functions and message authentication codes. This version only uses Authenticated Encryption with Associated Data (AEAD) cryptography algorithms which have built-in integrity checks. If the decryption fails, something is wrong, and TLS 1.3 terminates the session.
How is TLS used?
We have used web browsing to discuss TLS in action because it’s how most people protect their browsing experience. When people see the closed padlock in the address bar, they know their data is protected. Google’s Chrome browser takes this a step further by flagging HTTP-only websites as not secure. These nudges in consumer behavior forced most websites to implement HTTPS and, by extension, TLS.
Other internet applications use TLS. Even though Zoom and other video apps do not use the same transport layer protocols as web browsers — UDP rather than TCP — they encrypt their data with TLS.
SSL VPNs using TLS
Browser-based virtual private networks use TLS to create secure tunnels between their servers and a browser. These services are easy to use since they do not need a dedicated app.However, the TLS protection only applies to the connection between the browser and the VPN server. Other apps cannot use the VPN connection. Some SSL VPN providers solve that issue by offering plug-ins or client apps that extend the VPN beyond the browser.
This limitation may not matter when businesses use an SSL VPN as a remote access solution — as long as their business apps use web technologies. With an SSL VPN, users get encrypted access through the company’s VPN gateway to internally-hosted or cloud-hosted web apps. This approach offers several advantages over VPNs using IPsec or OpenVPN:
Users only need a browser to access company resources.
Less configuration and support are needed.
Simpler to implement with contractor-owned or personal devices.
User access is easier to limit to specific applications.
However, traditional VPN protocols may be more appropriate when users need to access legacy systems or when administrators need features that are only available in more capable VPN protocols.
Are any VPNs secure?
SSL VPNs may be more convenient and easier to manage than traditional VPN protocols, but they still suffer the weaknesses inherent to VPN technologies.
Consolidating all remote traffic through VPN gateways creates bottlenecks in protected networks that negatively affect bandwidth and latency. Network performance suffers even more when remote users’ access to cloud resources must round trip through the private network.VPN technologies, no matter what protocol you use, will expand your company’s attack surface. Gateways broadcast their presence on the public internet, making it easy for hackers to discover and exploit any unpatched vulnerabilities. Once compromised, the VPN gateway gives hackers full access to the network it was supposed to protect.
Twingate Zero Trust solutions and TLS
Twingate uses TLS to encrypt data exchanged by your users and protected resources within a complete Zero Trust Network Access (ZTNA) solution. Zero Trust is a modern secure access framework that significantly reduces attack surfaces while simplifying granular access control policies.
Based on the assumption that any network, resource, or device can be compromised at any time. Zero Trust shifts the focus of information security from defending network perimeters to protecting resources. Any attempt to access a resource is rejected unless explicitly verified by user identity and device posture. Policies based on the principle of least privilege limit user access to only the resources they need for their work. Zero Trust constrains hackers’ ability to leverage a breach and prevents them from moving laterally through a network.
Twingate’s Zero Trust solution creates direct, encrypted TLS connections between users and their authorized resources. The users could be in the office or at home. The resources could be on-premises or hosted in the cloud. Twingate creates a unified system that manages access across your organization.
TLS 1.2 protects connections from browsers and other applications that use the TCP transport protocol. Twingate can also deliver fast, low-latency connections using the QUIC transport layer protocol. Built upon UDP, QUIC’s multiplexed streams improve connection performance and handle network changes better than TCP. QUIC uses TLS 1.3 to keep data secure and private.
In both cases, these TLS tunnels are certificate-pinned to the protected resource’s Twingate proxy app, called the Controller.
Experience Twingate’s performance, simplicity, and security by joining our free Standard plan for individuals and small teams. Contact Twingate today to learn how easy migrating to Zero Trust Network Access can be.