Skip to main content

Overview

HTTPS Inspection controls CONNECT handling and optional TLS man-in-the-middle (Deep Scan) for HTTP inside HTTPS. Requires a valid RCSC (root CA) loaded from activation; the policy engine returns no policy when the section is off or misconfigured. Enabled Master switch ( ssl_policy ). Off: no inspection policy applies. Inspection Policies Profile rows; first match wins. Sets Deep Scan, no-certificate, domain-mismatch, and max SSL error level for that CONNECT. Setup Stored server/ passphrase rows (see field help — not read by current runtime setup code). SSL Certs/Cache Download, upload, or refresh RCSC files and view SSL session/context cache. On CONNECT, deep_scan_check() loads the first matching Inspection By default, general web traffic should be fully verified and fully inspected. The realistic exception is internal or development infrastructure whose certificates are self-signed, whose issuing chain is incomplete, or that is simply expired. Rather than relaxing verification globally, scope the relaxation to the specific traffic that needs it — ideally via a Request Type built for those internal hosts — rather than opening it up for everyone.

Core Mechanics (C++ Source Validation)

  • Deep Scan (MITM): The connection evaluator determines if deepscan is enabled for the connection. If true, SafeSquid performs full Man-in-the-Middle interception by generating a forged, trusted certificate for the client using the defined Root CA, enabling inspection of the encrypted payload.
  • Upstream Validation: SafeSquid builds an OpenSSL certificate store and verification parameters to validate the upstream origin server’s certificate against known CA authorities.
  • Strict Error Handling: Handlers validate domain mismatches (block_domain_mismatch), missing certificates (block_no_cert), and maximum allowable OpenSSL error levels (max_error_level). Failures drop the connection to prevent MITM attacks from malicious servers.

Section fields

The console splits HTTPS Inspection into three tabs. There is no Setup tab — the Setup rows described under SSL Certs/Cache below are configuration the current build never reads.

Global field

  • Enabled (enabled): Master switch for HTTPS Inspection. Off: The policy engine returns NULL and the inspection engine never enables Deep Scan. On: policies apply only when RCSC setup succeeds.

Examples

Open Configure → Real time content security → HTTPS Inspection → Inspection Policies (sibling tabs: Global, SSL Certs/Cache). Row fields match the Inspection Policy fields listed above exactly.
SafeSquid console showing HTTPS Inspection policy rows with DeepScan and certificate-error fields, the Edit Policies icon on the first row circled

HTTPS Inspection — Inspection Policies rows

1 — Inspect general web browsing

  • Enabled: on, valid RCSC from activation
  • Inspection row: Profiles blank, DeepScan TRUE, strict certificate checks
  • Clients trust RCSC public cert
Result: HTTP inside HTTPS is decrypted and passed through the normal filter pipeline.

2 — Tunnel non-HTTP TLS (Drive, Git, RDP-over-TLS)

  • Row A (top): Profiles for known non-HTTP apps, DeepScan FALSE
  • Row B: Profiles blank, DeepScan TRUE
Result: matching non-HTTP CONNECT tunnels without decryption; general HTTPS still inspected via row B.

3 — Allow self-signed upstream with strict client trust

  • Acceptable Errors: relaxed level for internal sites
  • Block domain mismatch: TRUE for public sites, FALSE on a row matching internal host profiles
Result: internal servers with name mismatch may pass upstream validation while public sites remain strict.

4 — Scoped relaxation for internal development servers

  • Inspection row, above the default: Profiles set to a label for known internal/development hosts, DeepScan TRUE, Acceptable Errors relaxed enough to tolerate a self-signed certificate or an incomplete local chain, Block domain mismatch left TRUE
Result: internal staging servers with a self-signed or incomplete-chain certificate pass Deep Scan without a certificate block, while Block domain mismatch staying on still catches a genuine hostname mismatch even on this relaxed entry — every connection outside that Profile still gets the strict default.
Turning on Deep Scan before clients trust the RCSC breaks HTTPS browsing for everyone behind it, not just for one site. Test with one machine that already trusts the certificate before enabling Deep Scan network-wide.
  • Deploy RCSC to all managed clients before enabling Deep Scan broadly.
  • Use DeepScan FALSE rows for protocols that are not HTTP-over-TLS.
  • Use SSL Certs/Cache to upload corporate roots and refresh caches after certificate changes.
  • Do not rely on Setup Encrypted Password for RCSC unlock — use activation passphrase.

How to verify

  1. CONNECT to an HTTPS site; confirm filters (for example ClamAV) see decrypted content when DeepScan is TRUE.
  2. Enable SSL log level for SSLcertSection:: and certificate validation lines.
  3. Check Detailed logs for CONNECT handling and upstream certificate errors.
  4. SSL Certs/Cache → Cache Refresh after RCSC or trusted-CA changes.
  5. Confirm a destination with a genuinely broken certificate (expired, wrong hostname, self-signed) is blocked under the strict default entry, and only passes through when routed to an entry whose Acceptable Errors and Block domain mismatch settings were deliberately relaxed for it.