Proxy HTTPS Interception: Certificate Control

TL;DR

A corporate proxy can intercept HTTPS traffic even if it doesn’t directly control the certificate store on every user’s device, but it requires a technique called Man-in-the-Middle (MitM) and relies on convincing users to trust its own Certificate Authority (CA). Without that trust, interception will fail. Modern browsers are increasingly resistant to this without explicit user consent.

How HTTPS Interception Works

1. The Problem: HTTPS uses certificates to verify the identity of a website. A proxy sitting between you and a website normally can’t read encrypted traffic because it doesn’t have the correct certificate.
2. MitM Setup: The proxy acts as an intermediary, terminating the HTTPS connection with the user and establishing a new HTTPS connection with the actual website. This is where things get tricky.
3. Dynamic Certificate Generation: The proxy generates its own certificates for each website the user visits. These certificates appear to be valid because they are signed by the proxy’s CA.
4. Certificate Installation (or Trust): This is the crucial step. The user’s device needs to trust the proxy’s CA certificate. There are a few ways this happens:
   • Pre-installed CA: Some corporate networks pre-install their root CA certificate on all devices.
   • Automatic Trust (deprecated): Older systems allowed proxies to automatically push certificates, but this is now largely blocked by browsers for security reasons.
   • User Installation: Users may be prompted to install the proxy’s CA certificate when they first visit a website. This requires user interaction and awareness.
   • Browser Configuration: Users might manually add the CA certificate to their trusted root store (less common).

Steps for Interception (from the Proxy’s Perspective)

1. Generate a CA Certificate: The proxy needs its own root CA. Tools like OpenSSL can be used:

   openssl genrsa -out ca.key 2048

   openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

2. Generate Certificates for Websites: When a user requests a website (e.g., example.com), the proxy creates a certificate specifically for that domain, signed by its own CA.

   openssl genrsa -out example.key 2048

   openssl req -new -key example.key -out example.csr

   openssl x509 -req -in example.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out example.crt -days 365

3. Present the Certificate: The proxy presents this generated certificate to the user’s browser during the TLS handshake.
4. Browser Check: The browser checks if it trusts the CA that signed the certificate. If the proxy’s CA is trusted (installed or pre-existing), the connection proceeds.

Why It Doesn’t Always Work

• Certificate Pinning: Some websites use “certificate pinning,” which hardcodes expected certificates in their apps or browsers. This prevents proxies from using their own certificates.
• HSTS (HTTP Strict Transport Security): HSTS forces browsers to only connect to a website over HTTPS, making MitM attacks harder.
• Modern Browser Protections: Browsers are increasingly vigilant about unexpected CA certificates and will warn users if they detect potential interception attempts. Chrome, Firefox, and Safari have implemented stronger security measures.
• User Awareness: Educated users are less likely to install untrusted certificates.

Detecting Interception

• Certificate Errors: Pay attention to any certificate warnings in your browser.
• Browser Extensions: Use extensions designed to detect MitM attacks (e.g., SSL Labs’ SSL Server Test).
• Network Monitoring Tools: Tools like Wireshark can help identify unexpected certificates or connections.