SSL/TLS Inspection and Man-in-the-Browser Attacks

HTTPS now accounts for more than 90% of web traffic — including malware downloads, C2 channels, and data exfiltration. Perimeter security tools that cannot inspect TLS see only encrypted blobs, creating a blind spot that attackers actively exploit. SSL/TLS inspection (also called SSL interception, SSL bumping, or deep packet inspection for HTTPS) allows security gateways to decrypt, inspect, and re-encrypt HTTPS traffic before it reaches the endpoint. This visibility is essential for web content filtering, DLP, and anti-malware scanning in environments where most traffic is HTTPS.

SSL inspection is technically a controlled man-in-the-middle performed by the organization's own security infrastructure. The process: Step 1: Client establishes TLS to the proxy (using the proxy's certificate signed by the corporate CA). Step 2: Proxy establishes a separate TLS session to the actual server using the server's real certificate. Step 3: Proxy decrypts traffic from the client, inspects it, then re-encrypts and forwards it to the server (and vice versa). The client trusts the proxy's certificate because the corporate CA certificate is pre-installed on all managed endpoints via MDM or Group Policy.

Not all traffic should be inspected. Organizations typically exempt categories that carry legally or ethically sensitive data: banking and financial sites, healthcare portals, legal research databases, certificate transparency and OCSP URLs (to avoid breaking certificate validation), and sites that use certificate pinning (which will reject re-signed certificates and break the application). Exemptions are maintained as a bypass list in the inspection policy. In some jurisdictions, employee monitoring laws may restrict inspection of personal web browsing, requiring clear disclosure in acceptable use policies.

Certificate pinning is a technique where an application hardcodes the expected certificate or public key for a specific server and refuses to connect if the certificate does not match — even if the certificate is valid and trusted by the OS CA store. This breaks SSL inspection because the proxy's re-signed certificate does not match the pinned value. Mobile apps (banking apps, payment apps) frequently use certificate pinning as an anti-MitM measure. Enterprises must bypass inspection for pinned apps or they will break. This also means attackers who want to evade SSL inspection from their malware can implement pinning.

SSL stripping is a man-in-the-middle attack where an attacker intercepts HTTPS traffic and downgrades it to HTTP, allowing them to read and modify the content in plaintext. The attack works on connections that start as HTTP before redirecting to HTTPS: the attacker intercepts the initial HTTP request, maintains an HTTP connection to the victim while establishing HTTPS with the legitimate server, and transparently relays traffic. From the victim's perspective, the site appears to be HTTP. HTTP Strict Transport Security (HSTS) defends against SSL stripping by telling browsers to always use HTTPS for a domain, even if the user types HTTP.

A Man-in-the-Browser (MitB) attack is a form of banking Trojan that inserts itself inside the web browser — as a malicious extension or browser process injection — and modifies web pages and transactions without the user noticing. Unlike a network MitM, MitB operates inside the encrypted session at the browser layer, so TLS provides no protection. MitB malware (Zeus, SpyEye) can: change payment amounts, alter recipient account numbers, capture one-time passwords, and silently modify forms after the user fills them in. The modifications happen after TLS decryption and before the user sees the rendered page.

MitB malware hooks browser APIs at the application layer. On Windows, it injects code into browser processes (Chrome, Firefox, IE) using DLL injection or COM hijacking, then hooks JavaScript functions and DOM manipulation APIs. When a user visits their bank, the malware intercepts the JavaScript that renders the page and transaction confirmation, altering the recipient account to the attacker's account. The server sees the correct transaction; the server-side HTTPS logs show nothing unusual. The user sees the correct confirmation — with their intended amount — while the actual transfer goes to the attacker's account.

Defending against MitB requires layered controls. Browser isolation (Menlo Security, Zscaler Browser Isolation) executes browser rendering in a remote cloud VM and streams only pixels to the user's screen — malware cannot inject into a browser process running in a remote environment. Transaction verification: banks confirm transaction details (amount + recipient) through an out-of-band channel (SMS OTP that includes the transaction details) so the user must verify what the server actually received. Endpoint EDR that detects DLL injection into browser processes can identify MitB infections. Browser extension allowlisting prevents malicious extensions.

Malicious browser extensions are a significant endpoint threat. Extensions have broad permissions — they can read page content, modify requests, intercept form submissions, and access cookies. An extension masquerading as a useful tool (ad blocker, dark mode) may harvest credentials, inject ads, redirect traffic, or act as a MitB agent. Enterprise controls: use Group Policy or MDM to restrict extension installation to an approved allowlist. Block extension installation from sources other than the Chrome Web Store or Firefox Add-ons. Audit installed extensions on managed endpoints regularly for policy violations.

Organizations that implement SSL inspection must address the privacy implications for employees. Many jurisdictions and employment laws require clear notice before monitoring encrypted traffic. Best practices: publish an Acceptable Use Policy (AUP) that explicitly states that network traffic including HTTPS may be inspected; have employees acknowledge the AUP during onboarding; implement bypass categories for personal banking and medical sites; and store decrypted traffic logs only as long as necessary (typically 30-90 days). Legal counsel should review the inspection program before deployment, particularly in EU countries where GDPR places stricter limits on employee monitoring.

Certificate Transparency is a framework (RFC 6962) that requires all publicly trusted TLS certificates to be logged in publicly auditable, append-only CT logs before browsers will trust them. CT enables domain owners to monitor for mis-issued certificates: if an attacker somehow convinces a CA to issue a certificate for your domain (as happened with DigiNotar in 2011), CT logs allow near-real-time detection. Tools like crt.sh let security teams search CT logs for all certificates issued for their domain. Browsers enforce CT by requiring proof of log inclusion (Signed Certificate Timestamps, SCTs) embedded in the TLS handshake.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: SSL/TLS inspection decrypts, inspects, and re-encrypts HTTPS traffic at a proxy using a corporate CA certificate trusted by managed endpoints, SSL stripping downgrades HTTPS to HTTP and is defeated by HSTS, and man-in-the-browser attacks inject into the browser process above the TLS layer to modify transactions invisibly, requiring browser isolation or out-of-band transaction verification as defenses. Next up we explore replacing insecure protocols with their secure equivalents.