> ## Documentation Index
> Fetch the complete documentation index at: https://docs.safesquid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SSL Inspection

## Problems addressed

HTTPS hides URLs, payloads, and uploads from a proxy that only sees tunnel metadata. Malware delivery, phishing pages, and data exfiltration over TLS evade policy without deliberate inspection and trust deployment.

## Outcomes operators expect

* Policy on full HTTPS URLs and content where inspection runs.
* Malware and DLP controls on encrypted flows when licensed and configured.
* Selective bypass for pinned apps, regulated sites, and privacy policy carve-outs.

## Technical scope

SafeSquid's documented TLS support covers **TLS 1.0 through TLS 1.3**. This matters because modern threats overwhelmingly use encrypted web sessions, and a proxy that cannot inspect current TLS traffic leaves the main enterprise web path opaque.

## Advantages vs “TLS blind proxying”

Inspection restores Layer 7 visibility on the proxy path at the cost of **client trust** in the SafeSquid root CA and operational work for bypass rules. **Comparative performance or legal suitability vs other vendors:** **Not SSOT-backed here**—see [What is SafeSquid SWG?](/safesquid_swg/what_is_safesquid_swg#architecture-and-positioning-claims-draft-vs-confirmed).

## Acquire, deploy, use

Follow [Configure HTTPS Inspection](/Configure_HTTPS_Inspection): Root CA, enable inspection, deploy trust to clients, define bypasses, verify.

HTTPS inspection (SSL/TLS interception) allows SafeSquid to decrypt, inspect, and re-encrypt HTTPS traffic. Without inspection, encrypted sessions remain a blind spot for content-level malware, phishing, and data-leakage policy.

## When to Use SSL Inspection

| Enable SSL Inspection When                        | Use Bypass Instead                               |
| ------------------------------------------------- | ------------------------------------------------ |
| Enforcing web security policies on HTTPS          | Banking and financial sites (compliance)         |
| Scanning encrypted downloads for malware          | Healthcare portals (HIPAA)                       |
| DLP on HTTPS uploads (file sharing, webmail)      | SSL-pinned mobile apps (cannot inspect)          |
| Application control (identify SaaS apps in HTTPS) | Government sites (security requirements)         |
| URL filtering on encrypted sites                  | Personal/sensitive user traffic (privacy policy) |

:::tip
**Selective inspection**
Bypass policies can exclude sensitive categories while inspection remains enabled for the rest of traffic.
:::

***

## Why HTTPS Inspection Matters

**The problem**

* **Draft:** Most enterprise web traffic is HTTPS; measure with local metrics if a percentage is required for a board narrative.
* Encrypted traffic hides malicious payloads, phishing attempts, and data exfiltration from content-aware policy.
* Without inspection, the proxy sees tunnel metadata (for example SNI), not full URLs or bodies.

**What HTTPS Inspection Enables:**

* URL filtering on HTTPS sites
* Malware scanning of encrypted downloads
* Data Loss Prevention (DLP) on HTTPS uploads
* Application control (detect Google Drive, Dropbox, etc. in HTTPS traffic)
* Content security (block ransomware downloads, malicious scripts)

**Operationally important SSL capabilities from product knowledge:**

* real-time SSL certificate validation against remote servers
* automatic certificate-chain repair through AIA fetching for broken chains
* continuous updates to the trusted root CA list

These capabilities matter because HTTPS inspection is not only about decryption. It also depends on accurate trust evaluation of remote servers.

***

## How It Works

1. **Client → SafeSquid:** Browser connects to SafeSquid using SafeSquid's certificate
2. **SafeSquid → Origin:** SafeSquid creates a separate TLS connection to the destination
3. **Inspection:** SafeSquid sees the decrypted content and applies policies
4. **Re-encryption:** SafeSquid re-encrypts and forwards to the destination

**Result:** Traffic remains encrypted end-to-end, but SafeSquid can inspect the content.

***

## Important considerations

### Bypass is Required For:

* **SSL-pinned applications** (mobile apps, some desktop software)
* **Banking and financial sites** (compliance/privacy)
* **Healthcare portals** (HIPAA compliance)
* **Government sites** (security requirements)

SafeSquid allows bypass rules to exclude specific domains from inspection.

### Client Trust Required:

All client browsers and applications must trust the SafeSquid Root CA certificate. Without trust, users see certificate warnings on every HTTPS site.

**Deploy the Root CA to:**

* Windows certificate store (for Chrome, Edge, IE)
* Firefox certificate store (separate)
* macOS Keychain (for Safari, system-wide)
* Mobile devices (via MDM)

### Production safety

* Do not enable broad inspection in production before planning certificate deployment and bypass scope.
* Test certificate-pinned applications, regulated destinations, and business-critical SaaS before rollout.
* If inspection is introduced without a pilot, certificate warnings and application failures can create a self-inflicted outage.

***

## Configuration Guides

### [Configure HTTPS Inspection](/Configure_HTTPS_Inspection)

**Complete setup guide covering:**

* Generate or import Root CA certificate (Self-Service Portal)
* Enable HTTPS inspection in SafeSquid
* Configure bypass policies for sensitive domains
* Deploy Root CA to clients (Windows, macOS, Firefox, mobile)
* Verify inspection is working

**Start here** for first-time SSL Inspection setup.

***

### [Import Certificate into Chrome/IE](/Import_Certificate_Chrome_IE)

**Step-by-step walkthrough** for importing the SafeSquid Root CA into the Windows Trusted Root Certification Authorities store (used by Chrome, Edge, and Internet Explorer).

**Use this** after enabling HTTPS inspection to eliminate browser certificate warnings on Windows clients.

***

## Quick Start Checklist

1. ✅ **[Generate Root CA](/Configure_HTTPS_Inspection#generating-ssl-certificates)** in Self-Service Portal
2. ✅ **[Enable HTTPS Inspection](/Configure_HTTPS_Inspection#enabling-ssl-inspection)** in SafeSquid Configuration Portal
3. ✅ **[Configure bypass policies](/Configure_HTTPS_Inspection#bypass-policies)** for banking/healthcare sites
4. ✅ **Deploy Root CA** to all clients:
   * [Windows (Chrome/IE)](/Import_Certificate_Chrome_IE)
   * [Firefox](/Configure_HTTPS_Inspection#import-certificate-into-firefox)
   * macOS via MDM or Keychain
   * Mobile via MDM
5. ✅ **[Verify](/Configure_HTTPS_Inspection#verification)** inspection is working (check padlock icon, test bypass)

## Verification and validation

After enabling SSL inspection, confirm all of the following:

* the client trusts the SafeSquid Root CA
* inspected sites show the expected SafeSquid-issued certificate path
* bypassed destinations remain uninspected
* blocked or scanned HTTPS transactions now trigger the intended policy outcomes
* logs show SSL-related decisions such as validation or decryption behavior where expected

Run both positive and negative tests:

* **Positive test:** browse to a site that should be inspected and confirm content-aware policy can now see it
* **Negative test:** browse to a bypassed site and confirm the original site certificate remains intact

## Troubleshooting

**Symptom:** Users see certificate warnings on normal HTTPS sites.\
**Likely cause:** The SafeSquid Root CA is not trusted on the client.\
**Isolation:** Inspect the presented certificate chain and confirm whether the SafeSquid CA is installed.\
**Remediation:** Deploy the CA correctly to the client trust store.\
**Retest:** Reload the same inspected site and confirm the warning disappears.

**Symptom:** A business-critical app breaks only when inspection is enabled.\
**Likely cause:** Certificate pinning, protocol sensitivity, or an application-specific trust expectation.\
**Isolation:** Compare behavior with a narrow bypass for the application domain.\
**Remediation:** Keep a tightly scoped bypass if inspection is not technically viable for that app.\
**Retest:** Confirm the application works and that unrelated traffic is still inspected.

**Symptom:** HTTPS traffic passes, but content-aware controls still do not trigger.\
**Likely cause:** Inspection is not actually active on that flow, or the destination is still bypassed.\
**Isolation:** Check the active SSL policy path, the certificate behavior, and the matching bypass rules.\
**Remediation:** Correct the inspection scope.\
**Retest:** Repeat the same policy-triggering transaction and confirm the control fires.

***

## Common Questions

**Q: Will users see certificate warnings?**\
A: Yes, until you deploy the SafeSquid Root CA to their devices. Once trusted, no warnings appear.

**Q: Can I inspect only some sites and not others?**\
A: Yes, use bypass policies to exclude specific domains (e.g., banking sites).

**Q: What about mobile apps that use certificate pinning?**\
A: Add those apps' domains to the bypass list. They cannot be inspected.

**Q: Does this slow down HTTPS traffic?**\
**A (Draft — pending engineering SSOT):** Inspection adds CPU-bound TLS work. [Deployment Planning](/deployment/deployment_planning) covers **AES-NI** and sizing. Do **not** treat fixed millisecond figures as verified product facts until CTO publishes benchmarks in-docs.

***

## Source register

| Topic                                                   | Status           | Source                                                               |
| ------------------------------------------------------- | ---------------- | -------------------------------------------------------------------- |
| HTTPS inspection workflow (client → SafeSquid → origin) | **Confirmed**    | [Configure HTTPS Inspection](/Configure_HTTPS_Inspection), this page |
| Client trust requirement for Root CA                    | **Confirmed**    | This page, certificate import guides                                 |
| PCI / SOC framing as compliance context                 | **Context only** | Helpful for risk framing, not a compliance guarantee                 |
| HTTPS traffic percentage                                | **Missing**      | No SSOT in this KB                                                   |
| Numeric inspection latency                              | **Missing**      | **CTO** to supply benchmark or remove figures                        |

## Next Steps

1. **[Configure HTTPS Inspection](/Configure_HTTPS_Inspection)** — Complete setup guide
2. **[Authentication](/Authentication)** — Enable user-aware policies after SSL Inspection
3. **[Access Restriction](/Access_Restriction)** — Configure URL filtering (now works on HTTPS)
4. **[Data Leakage Prevention](/Data_Leakage_Prevention)** — Scan HTTPS uploads for sensitive data


## Related topics

- [SSL Inspection](/use_cases/ssl_inspection/ssl_inspection.md)
- [Policy Management Console](/safesquid_swg/interface/configuration_portal.md)
- [Configure HTTPS Inspection](/use_cases/ssl_inspection/configure_https_inspection.md)
- [HTTPS Inspection Validation](/deployment/https_inspection_validation.md)
- [Import Certificate into Chrome or Internet Explorer](/use_cases/ssl_inspection/import_certificate_chrome_ie.md)