SSL Inspection Done Right: Deploying Proxy-Based URL Filtering Without Breaking Things

Mar 26, 2026

Hopbox team

Over 95% of web traffic is encrypted. That is good for user privacy, but it creates a blind spot for network security. A firewall that cannot inspect TLS traffic is making allow/deny decisions based on IP addresses and SNI headers alone. That is not enough for compliance, threat detection, or granular access control.

SSL inspection solves this, but most deployments are painful. Certificate errors break applications, banking sites stop working, and helpdesk tickets pile up. Charcoal is our answer to doing SSL inspection correctly — transparent proxying with smart exemptions, deployed on Hopbox appliances at the network edge.

Why SSL Inspection

Without SSL inspection, a network security appliance can see:

• Source and destination IP addresses
• The SNI field in the TLS ClientHello (the hostname, in plaintext)
• Packet sizes and timing

It cannot see:

• The full URL path (only the hostname, not /api/v2/exfiltrate-data)
• Request and response headers
• POST body content
• The actual HTTP method

This means a policy like “allow access to drive.google.com but block uploads” is impossible without breaking into the TLS session. SSL inspection gives the proxy visibility into the full HTTP transaction inside the encrypted tunnel.

How Transparent Proxying Works in Charcoal

Charcoal operates as a transparent intercepting proxy. Clients do not need to configure proxy settings or install agents. The network handles everything.

Traffic Interception

All HTTP and HTTPS traffic from LAN clients is redirected to the Charcoal proxy process using nftables rules:

chain prerouting {
    type nat hook prerouting priority -100;

    # Redirect HTTP
    iifname "br-lan" tcp dport 80 redirect to :3128

    # Redirect HTTPS
    iifname "br-lan" tcp dport 443 redirect to :3129
}

Port 3128 handles plaintext HTTP. Port 3129 handles TLS interception — Charcoal terminates the client TLS session, inspects the HTTP request, applies policy, and then initiates a new TLS session to the origin server.

The TLS Interception Flow

1. Client initiates a TLS connection to example.com:443.
2. nftables redirects the connection to Charcoal on port 3129.
3. Charcoal reads the SNI from the ClientHello.
4. Charcoal checks the exemption list. If the domain is exempt, it passes the connection through without interception (TCP splice).
5. If not exempt, Charcoal generates a certificate for example.com signed by the local CA.
6. Charcoal completes the TLS handshake with the client using the generated certificate.
7. Charcoal initiates a separate TLS connection to the real example.com.
8. HTTP requests and responses flow through Charcoal, where URL filtering and content policy are applied.
9. Charcoal logs the full URL, category, and action taken.

CA Certificate Deployment

For SSL inspection to work without certificate errors, clients must trust the Charcoal CA certificate. This is the single biggest deployment hurdle, and there are several paths depending on the environment.

Active Directory / Group Policy (Windows)

For domain-joined Windows machines, deploy the CA certificate via GPO:

1. Open Group Policy Management Console.
2. Create or edit a GPO linked to the target OU.
3. Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
4. Import the Charcoal CA certificate (.crt file).
5. Run gpupdate /force or wait for the next policy refresh.

MDM (macOS, iOS, Android)

For managed mobile devices and Macs, push the CA certificate as a configuration profile:

• macOS/iOS: Create a .mobileconfig profile containing the CA certificate, set it as trusted. Deploy via Jamf, Mosyle, or any MDM.
• Android: Use Android Enterprise managed configurations to push the CA as a trusted credential.

Manual Installation (BYOD / Unmanaged)

For unmanaged devices, Charcoal serves a captive portal at http://charcoal.local where users can download and install the CA certificate with step-by-step instructions for their OS and browser.

Certificate Pinning and Exemptions

Some applications use certificate pinning (HPKP, built-in pin sets, or custom trust stores) and will refuse connections when they see a certificate signed by an unexpected CA. These applications break under SSL inspection.

Common examples:

• Banking and financial applications
• Government portals
• Healthcare systems (EMR/EHR)
• Mobile apps with embedded pins (Dropbox, Slack desktop, some Microsoft services)
• Software update mechanisms (Windows Update, macOS Software Update)

Charcoal handles this with a domain exemption list. Exempted domains are spliced through at the TCP level — Charcoal never terminates TLS, so the original server certificate reaches the client untouched.

{
  "exemptions": [
    {
      "category": "banking",
      "domains": [
        "*.bankofamerica.com",
        "*.chase.com",
        "*.wellsfargo.com",
        "online.citi.com"
      ]
    },
    {
      "category": "system-updates",
      "domains": [
        "*.windowsupdate.com",
        "*.apple.com/swu",
        "swcdn.apple.com"
      ]
    },
    {
      "category": "healthcare",
      "domains": [
        "*.epic.com",
        "*.cerner.com"
      ]
    }
  ]
}

Charcoal ships with a default exemption list covering known pinned domains. Administrators can add custom exemptions through the management interface.

Charcoal Architecture

Charcoal runs as a service on the Hopbox appliance. The architecture has three main components:

Proxy Engine

The core proxy is built on a high-performance event-driven architecture. It handles connection interception, TLS termination, certificate generation, and HTTP parsing. Certificates are generated on-demand and cached in memory to avoid repeated key generation for frequently accessed domains.

URL Categorization

Every inspected URL is classified against a category database. Categories include:

• Social media
• Streaming/entertainment
• Gambling
• Adult content
• Malware/phishing (threat intelligence feeds)
• SaaS applications (per-app granularity)

Policy is applied per category, per user group (mapped from LDAP/AD), and per time schedule. For example: “Allow social media for the marketing team during business hours, block for everyone else.”

Reporting and Compliance

Charcoal generates detailed access logs:

2026-03-25T14:32:01Z src=10.0.1.45 user=jsmith url="https://docs.google.com/document/d/1abc..." category=cloud-storage action=ALLOW policy="corp-standard"
2026-03-25T14:32:03Z src=10.0.1.62 user=guest url="https://www.gambling-site.example.com/" category=gambling action=BLOCK policy="guest-restrict"

Logs are exported to the central Hopbox controller for aggregation, and can be forwarded to external SIEM systems via syslog or direct API integration. Built-in reports cover:

• Top blocked categories and domains
• Per-user browsing summaries (for compliance, not surveillance)
• Bandwidth consumption by category
• Exemption hit rates (to identify candidates for removal)

Performance Impact

SSL inspection adds latency. Every TLS connection requires an additional handshake and certificate generation. In practice, the overhead on Hopbox appliances is:

• Connection setup: Approximately 2-5ms additional latency per new TLS connection.
• Throughput: Negligible impact on sustained transfers once the connection is established.
• Certificate caching: After the first connection to a domain, subsequent connections reuse the cached certificate, reducing overhead to near zero.

The proxy engine is designed to handle the connection rates typical of a branch office (50-500 concurrent users) without becoming a bottleneck.

Deployment Checklist

For teams deploying Charcoal, here is the recommended sequence:

1. Deploy CA certificate to all managed devices before enabling interception.
2. Enable in monitor-only mode — log all traffic but do not block. Review logs for a week.
3. Review exemption list — identify applications that break and add exemptions.
4. Enable blocking — start with a permissive policy and tighten over time.
5. Communicate with users — explain what is being filtered and why. Transparency reduces friction.
6. Monitor exemption hit rates — if an exemption is never triggered, the pinned app may have updated. Test removal periodically.

Conclusion

SSL inspection does not have to be a source of outages and user complaints. The key is transparent proxying (no client configuration), a well-maintained exemption list (so pinned applications keep working), and a phased rollout (monitor before you block). Charcoal packages all of this into a single service running on the Hopbox appliance, giving branch offices the same encrypted traffic visibility that cloud proxies provide for remote users.

Tags:

• security
• ssl
• proxy
• charcoal

Running PowerDNS at Scale: Serving 240k Queries/Hour Across 900+ Sites

WAN Optimization for Latency-Sensitive Applications (POS, VoIP, Video)