HTTPS INTERCEPTION & DECRYPTION

How HTTPS Man-in-the-Middle Works

HTTPS is designed to prevent interception — TLS encryption means only the client and server can read the traffic. HTTPS interception breaks this by inserting a proxy into the path that acts as the "server" to the client and as the "client" to the real server.

The fundamental requirement: the client must trust the proxy's certificate authority (CA). If your browser trusts Proxy-CA, then any certificate signed by Proxy-CA will be accepted as legitimate — even one the proxy just generated on-the-fly for gmail.com.

The Three-Phase Attack

1. Intercept: Position the proxy between client and server via ARP spoofing, DNS hijacking, gateway configuration, or transparent proxy rules
2. Terminate: Proxy receives the client's TLS ClientHello, completes the TLS handshake using a generated certificate signed by the proxy's CA
3. Forward: Proxy makes its own TLS connection to the real server, decrypts/inspects/modifies traffic, re-encrypts to client

SSL Bumping: The Corporate Proxy Method

SSL bumping is the controlled deployment of HTTPS interception in enterprise environments. Security teams use it to inspect encrypted traffic for malware, data exfiltration, and policy compliance.

How Corporate SSL Bumping Works

The enterprise deploys a Secure Web Gateway (SWG) like Zscaler, Netskope, or Cisco Umbrella. The SWG runs as a transparent proxy — all HTTPS traffic routes through it automatically via network routing or endpoint agent. A CA certificate (the SWG's root CA) is pushed to all corporate devices via MDM (Jamf for macOS, Microsoft Intune for Windows). Employees never know their HTTPS traffic is being inspected.

The SWG can then: block malicious downloads, prevent DLP (data loss prevention) violations, enforce acceptable use policies, inspect for credential harvesting, and log all HTTPS destinations for compliance.

Squid SSL Bump (Open Source)

Squid proxy supports SSL bumping for teams who want to self-host:

# squid.conf SSL bump configuration
ssl_bump server-first all
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/ssl_db -M 4MB
sslproxy_cert_error allow all
ssl_bump peek step1
ssl_bump bump all

Squid generates certificates on-the-fly using OpenSSL. Each visited domain gets a certificate signed by Squid's CA. Performance cost: ~10-20ms per new domain (certificate generation + TLS handshake).

Certificate Generation On-the-Fly

The proxy must generate a valid-looking certificate for every HTTPS domain the client visits. The certificate must: match the domain name, be signed by a CA the client trusts, have valid validity dates, and include correct extensions (SAN, key usage).

# Generate intercepting cert for target.com (Python + cryptography)
from cryptography import x509
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa
import datetime

# Load proxy CA
with open('proxy-ca.key', 'rb') as f:
    ca_key = serialization.load_pem_private_key(f.read(), None)
with open('proxy-ca.crt', 'rb') as f:
    ca_cert = x509.load_pem_x509_certificate(f.read())

# Generate key for fake cert
key = rsa.generate_private_key(65537, 2048)

# Build certificate matching target domain
cert = (x509.CertificateBuilder()
    .subject_name(x509.Name([x509.NameAttribute(x509.oid.NameOID.COMMON_NAME, "target.com")]))
    .issuer_name(ca_cert.subject)
    .public_key(key.public_key())
    .serial_number(x509.random_serial_number())
    .not_valid_before(datetime.datetime.utcnow())
    .not_valid_after(datetime.datetime.utcnow() + datetime.timedelta(days=365))
    .add_extension(x509.SubjectAlternativeName([x509.DNSName("target.com")]), False)
    .sign(ca_key, hashes.SHA256()))

Corporate HTTPS Inspection in Practice

When working behind a corporate proxy that performs SSL inspection, your browser or tool needs the corporate CA in its trust store. Without it, every HTTPS connection fails with a certificate error.

Detection & Prevention

Certificate Pinning

The strongest defense against HTTPS interception. Apps hardcode the expected certificate public key hash (pin). When connecting, they compare the received certificate's hash against the pinned value. A proxy-generated certificate has a different public key — connection fails even if the CA is trusted.

Limitation: pins must be updated when the legitimate certificate changes. Applications must be updated to change pins. Mobile browsers (Chrome, Firefox) don't support pinning for arbitrary sites — only apps implement it for their own APIs.

Certificate Transparency (CT)

All publicly-trusted CAs must log certificates to CT logs (monitored by browsers). A proxy-generated certificate signed by a private CA won't be in CT logs. Browsers can check: if an HTTPS site's certificate isn't in CT logs, show a warning. CT checking requires browser support and is not universal.

CAA DNS Records

Certification Authority Authorization records specify which CAs are allowed to issue certificates for a domain. proxifypro.com. CAA 0 issue "letsencrypt.org" means only Let's Encrypt can issue certs for this domain. A proxy CA isn't on the list — technically a policy violation, but CAs don't check CAA in real-time during interception.

Implications for Proxy Operations

If you're running ProxifyPRO behind a corporate network with SSL inspection, you need to configure your system to trust the corporate CA or route proxy traffic outside the inspection perimeter. The proxy traffic itself (your scraping requests) may be logged if the corporate SWG inspects it.

For security-conscious operations, use a ProxifyPRO server outside the corporate network and connect via encrypted tunnel (Cloudflare Tunnel, WireGuard) — the SWG sees encrypted tunnel traffic, not your proxy requests.