SBN

Inspecting TLS Web Traffic – Part 1

In this series of blogs I’m going to talk about how the continued move towards all web traffic being encrypted has impacted enterprise security. In this blog I’m going to focus on the basics – what is encrypted web traffic and how can you proactively control this.

TLS encryption is the de-facto encryption technology for delivering secure web browsing, and the benefits it provides are driving the levels of HTTPS traffic to new heights. Every day, more HTTPS web traffic traverses the internet in a form that provides security and trust for users. This traffic is encrypted with TLS, a transport layer encryption protocol that protects data against unauthorized access and eavesdropping. Current estimates indicate that over 90% of all web traffic is now encrypted.

However, not all HTTPS traffic is benign; attackers and malware writers also leverage encryption to hide their activities. In a recent report, it was stated that 60% of malicious traffic is encrypted. Without the proper security controls, encrypted web traffic can be a blind spot in securing your network and users.

TLS Primer

Secure Sockets Layer (SSL) was originally developed by Netscape Communications in 1995 to provide security for internet communications. However, in 1999, Netcscape handed over the protocol to the Internet Engineering Task Force (IETF). Later that year, the IETF released TLS 1.0, which was, in reality, SSL 3.1. Recently, TLS 1.3 was released, but most web sites still use TLS 1.2.

For clarity, in these blogs, I exclusively use TLS, but this has exactly the same meaning as SSL or SSL/TLS.

TLS provides a secure channel between two endpoints, typically a client browser and a web server, to provide protection against eavesdropping, forgery of, or tampering with the traffic. To provide this security, SSL uses X.509 digital certificates for authentication and encryption to ensure privacy and digital signatures to ensure integrity.

Essentially, SSL/TLS creates a secure tunnel between the two endpoints, and the web traffic is transmitted inside the tunnel. The encrypted traffic is called HTTPS and uses TCP port 443 to communicate between the client browser and the Web server; unencrypted HTTP traffic uses TCP port 80.

It is worth noting that, although SSL/TLS is primarily used to secure HTTP traffic, SSL/TLS was designed so that it could provide security for many other application protocols that run over TCP.

HTTPS Web Traffic: An Overview
To allow proactive inspection and control of HTTPS web traffic, it is necessary to look inside the secure tunnel and examine the encrypted traffic. One effective way to deliver this capability is to deploy a Secure Internet Gateway (SIG) or Secure Web Gateway (SWG) that is able to intercept and decrypt the HTTPS traffic. This technique of intercepting and decrypting traffic is known as Man-in-The-Middle (MITM).

To achieve MITM, a secure connection is created between the client browser and the Secure Internet Gateway (SIG) or Secure Web Gateway (SWG), which decrypt the HTTPS traffic into plain text. Then, after being analyzed, the traffic is re-encrypted, and another secure connection is created between the SIG or SWG and the web server. This means that the SIG or SWG is effectively acting as a SSL/TLS proxy server and can both intercept the SSL/TLS connection and inspect the requested content.

This capability is available in Akamai’s Enterprise Threat Protector service, and it allows inspection of the requested URL to determine if the requested URL is safe or malicious. Payloads received from the web servers are also decrypted and inspected by the ETP Payload Analysis functions to determine if the content is safe or malicious.


*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Jim Black. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/SmvM3N8ShWc/inspecting-tls-web-traffic---part-1.html