Interview: HTTPS Interception, TLS Fingerprinting, and the Browser

Use HTTPS, they said. Make sure your browsers shows that green padlock, they said. You’ll be safe, nobody can eavesdrop, they said.

IT security teams and threat hunters, who are familiar with the inherent security weakness of the web’s underlying protocols, know better.

The problem with HTTPS internet connections is similar to the problem with VPN. Or, as Larry Loeb put it in his post HTTPS: Beware the False Sense of Security on this blog: “[U]sers think that it does more than it actually does.”

For starters, a basic HTTPS connection gets established when the browser (client) connects directly to an origin server to send requests and download content protected by TLS-based  encryption. Still, this communication is vulnerable to interception.

The reason is simple. Often, the browser doesn’t connect directly with the web server serving the website. Instead, data gets routed through a proxy or middlebox, a.k.a. "monster-in-the-middle" (MITM). HTTPS interception, for benign or malign reasons, is prevalent on the internet. Compromised TLS connections put the integrity and confidentiality of data between browsers and websites at risk.

Two systems engineers with web performance and website security company Cloudflare, Luke Valenta and Gabriele “Gabbi” Fisher, have set out to battle the “Monsters in the Middleboxes” to prevent malicious intercepting of HTTPS traffic and MITM attacks.

At the Black Hat USA 2019 conference in Las Vegas, they discussed “Building Tools for Detecting HTTPS Interception” (slides here), specifically the MITMEngine they developed at Cloudflare (tool review and GitHub link here), and the accompanying public MALCOLM dashboard.

In this interview for the Authentic8 Silo Sessions podcast, Amir Mohammadi also spoke with Luke and Gabbi about the use of “TLS fingerprinting” to detect HTTPS interceptions affecting SSL/TLS connections established with Google Chrome and Mozilla Firefox browsers.

Listen to their conversation here.