> ## 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.

# What is SafeSquid SWG

> SafeSquid is a high-performance, multi-threaded Content Security Gateway engineered to deliver Zero-Trust Web Security at the Application Layer through deep content inspection and granular policy enforcement on encrypted web traffic.

# SafeSquid: Zero-Trust Web Security at the Application Layer

SafeSquid is a high-performance, multi-threaded Content Security Gateway that enforces Zero-Trust Web Security at the Application Layer. The gateway operates as an inline HTTP(S) proxy, terminates and evaluates every web session at Layer 7, and applies user-aware and content-aware policy to requests, responses, uploads, downloads, and payloads. The software-only architecture eliminates proprietary hardware lock-in and deploys on any standard Intel-based server, virtual machine, or cloud platform.

## Encrypted traffic leaves the network blind

The majority of enterprise web traffic is encrypted. Traditional firewalls stop at IP address, port, and domain reputation — the Layer 7 transaction, authenticated user context, POST body, and file payload remain invisible. This inspection gap is the entry point for modern attacks.

Attackers deliver zero-day malware, ransomware, and phishing through HTTPS connections that legacy perimeter controls treat as trusted. Sensitive data leaves through SaaS storage, browser uploads, and personal webmail without triggering any firewall alert. Unsanctioned remote-access tools such as **AnyDesk** and **TeamViewer** operate over standard HTTPS ports. Employees consume streaming media, personal social networks, and non-work applications during business hours — a pattern known as cyber-slacking — reducing productivity and consuming bandwidth. When an incident occurs, investigation stalls because request-level logs, user attribution, and enforcement evidence do not exist.

The operational, financial, and regulatory impact is compounded:

* Malware reaches endpoints through encrypted downloads without triggering network-layer detection.
* Sensitive documents, customer records, and intellectual property leave through browser-mediated uploads and SaaS sync.
* Unauthorized remote-access tools create unmonitored egress paths that bypass identity and access controls.
* Cyber-slacking consumes bandwidth and exposes the enterprise to liability from prohibited content.
* Compliance audits fail when policy decisions, timestamps, user attribution, and enforcement evidence cannot be produced.
* Breach response costs rise when security teams cannot demonstrate control effectiveness, scope, or user-level activity.

The teams accountable for reducing and proving web risk are the primary beneficiaries of a solution at this layer:

* CISOs and security leaders who must demonstrate Layer 7 control coverage to auditors and boards.
* Security operations teams that need enforceable policy and forensic-grade logs for incident investigation.
* Network and system administrators who deploy, tune, and operate the gateway.
* Compliance, audit, and risk teams that require exportable evidence mapped to SOC 2, ISO 27001, PCI-DSS, HIPAA, and GDPR controls.
* Lean IT teams in enterprises, SMBs, and educational institutions that need enterprise-grade security without dedicated appliance hardware.

## What a Content Security Gateway must deliver

An enterprise Secure Web Gateway must convert opaque outbound web traffic into a controlled, observable, and auditable enforcement plane. Meeting the minimum bar requires measurable security function, not feature naming.

A production-ready Content Security Gateway must:

* Inspect encrypted HTTPS sessions so policy applies to URLs, HTTP headers, methods, request bodies, file downloads, and authenticated identity — not only network metadata.
* Enforce identity-aware policy by user, group, application, destination category, time profile, and content class.
* Block malicious destinations, prohibited categories, disallowed applications, and unsafe content transfers before the transaction completes.
* Reduce data exfiltration risk by evaluating uploads, POST bodies, browser-mediated file transfers, and SaaS sync paths.
* Generate audit-grade logs that record user identity, source IP, destination, action, timestamp, policy rule, and enforcement result.
* Consume real-time intelligence for URL classification, threat feeds, application signatures, malware scanning, and SSL trust — because static rules cannot match dynamic attack patterns.
* Support governance by providing exportable reports, policy audit trails, and compliance-mapped evidence for framework reviews.
* Deploy without proprietary hardware on standard Linux infrastructure, virtual machines, and cloud environments to avoid vendor lock-in.

## How SafeSquid enforces Layer 7 security

SafeSquid operates as an inline HTTP(S) proxy with a multi-threaded, SMP-aware processing engine. Unlike traditional multi-process proxies — where security processors communicate over inter-process channels, introducing latency at scale — SafeSquid threads share memory directly. All security processors access a common memory space, enabling instantaneous parallel inspection across thousands of concurrent connections.

### On-The-Wire Security Neural Network

SafeSquid's enforcement engine implements what the platform calls the **On-The-Wire Security Neural Network**: a real-time intelligence cache that accumulates behavioral patterns, threat indicators, and content context from active connections and applies that intelligence to subsequent sessions on the same gateway instance. This means that inspection decisions for session N benefit from the context of sessions already in flight — not only from static feed data. The cache updates continuously, so threat correlation occurs without batch processing delays.

This architecture eliminates two bottlenecks found in legacy gateways:

* **Inter-process communication overhead:** multi-process proxies fork separate security worker processes per connection, requiring context serialization and IPC calls. SafeSquid threads share memory directly, eliminating serialization.
* **Feed-only intelligence:** static feed lookups treat every session in isolation. The On-The-Wire cache propagates live behavioral context across concurrent connections.

### Deep content inspection pipeline

The inspection pipeline operates on every HTTP and HTTPS transaction:

1. **TLS termination** — SSL/TLS sessions are terminated at the gateway, decrypted, inspected, and re-encrypted toward the destination. This gives the policy engine access to the full Layer 7 payload.
2. **Identity and context resolution** — user identity is resolved against Active Directory, LDAP, Kerberos, NTLM, or RADIUS before policy evaluation. Every enforcement decision carries an authenticated identity context.
3. **Policy evaluation** — each transaction is evaluated against URL category, application signature, content type, file type, destination reputation, time profile, and user/group rule sets. Rules are evaluated in order; the first matching rule determines the enforcement action.
4. **Content scanning** — downloads and uploads are inspected by ClamAV malware scanning, image analysis AI, and keyword-based content filtering before the payload reaches the endpoint or destination.
5. **Logging and evidence** — every transaction produces a structured log entry: user identity, source, destination, HTTP method, URL, rule matched, action taken, bytes transferred, and timestamp. Logs are written to `/var/log/safesquid/` and accessible through the Reporting Service for export and SIEM forwarding.

### Platform components

SafeSquid is broader than a proxy executable. The production platform combines:

| Component                           | Role                                                                                          |
| ----------------------------------- | --------------------------------------------------------------------------------------------- |
| SWG proxy enforcement engine        | HTTP(S) inspection, TLS termination, policy enforcement                                       |
| Configuration Portal                | Policy authoring, rule management, system administration                                      |
| Self-Service Portal                 | License activation, key management, subscription                                              |
| Reporting Service                   | Analytics, forensic logs, compliance report export                                            |
| Active Directory / LDAP integration | User and group identity resolution                                                            |
| Cloud intelligence feeds            | URL categories, threat intelligence, application signatures, malware signatures, geo-location |
| BIND DNS                            | Internal DNS resolution and DNS security                                                      |
| Monit                               | Service monitoring and automatic restart                                                      |
| SafeSquid Appliance Builder (SAB)   | Automated ISO-based deployment on standard hardware                                           |
| Cluster management                  | Scale-out across multiple proxy nodes                                                         |

Deployment success depends on planning for identity integration, TLS trust distribution, reporting feed reachability, licensing activation, and operational resilience — not only proxy installation.

## Layer 7 control: with and without SafeSquid

| Scenario                                  | Without SafeSquid                                                               | With SafeSquid                                                                                  |
| ----------------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Ransomware delivered via HTTPS download   | ❌ Payload passes through encrypted; endpoint AV is last line of defense         | ✅ Payload scanned by ClamAV before delivery; transaction blocked and logged                     |
| Phishing site over HTTPS                  | ❌ Domain may pass firewall reputation check; URL and page content not inspected | ✅ URL category and threat intelligence evaluated at Layer 7; session blocked with user redirect |
| Data exfiltration via personal webmail    | ❌ Upload POST body not visible; no policy applied                               | ✅ Upload body inspected; DLP keyword rules applied; transfer blocked if policy matches          |
| Cyber-slacking (streaming, social media)  | ❌ HTTPS traffic categorized only by domain; blocking is coarse                  | ✅ URL category, time profile, and user identity combined; per-user or per-group enforcement     |
| Unsanctioned remote-access tool (AnyDesk) | ❌ Application uses port 443; firewall cannot distinguish from legitimate HTTPS  | ✅ Application signature matches AnyDesk behavioral pattern; session blocked and logged          |
| Compliance audit for web access controls  | ❌ Logs show IP-to-IP connections; no user attribution or enforcement evidence   | ✅ Per-user logs with URL, action, rule, and timestamp exported from Reporting Service           |

## When to deploy SafeSquid

✅ **Deploy SafeSquid when:**

* The network carries HTTPS traffic that must be inspected at Layer 7 for policy enforcement, malware scanning, or DLP.
* User identity must be attributed to web transactions for forensic investigation or compliance reporting.
* The organization needs to enforce acceptable-use policy across application categories, content types, and time profiles.
* Hardware appliance costs or vendor lock-in constraints require a software-deployable alternative.
* The deployment environment is Linux-based, virtualized, or cloud-hosted on standard Intel infrastructure.
* The security team requires exportable, audit-grade evidence for SOC 2, ISO 27001, PCI-DSS, HIPAA, or GDPR reviews.

❌ **Do not deploy SafeSquid as a substitute for:**

* A next-generation firewall handling east-west lateral movement — SafeSquid inspects outbound HTTP(S) web traffic, not all TCP/UDP flows.
* An email security gateway — SafeSquid does not process SMTP, IMAP, or POP3 traffic.
* An endpoint detection and response (EDR) agent — SafeSquid enforces web-layer policy at the network perimeter, not on-device behavioral monitoring.
* A DNS-only sinkhole — SafeSquid requires traffic to traverse the proxy path; DNS-only controls bypass the inspection pipeline.

## Acquire, deploy, and configure SafeSquid

### Step 1 — Register and obtain an activation key

Create an account on the [SafeSquid Self-Service Portal](https://key.safesquid.com) to obtain a free activation key. The activation key is required before the proxy engine accepts connections. Registration takes under five minutes and does not require hardware procurement.

### Step 2 — Deploy the gateway

The fastest deployment path uses the **SafeSquid Appliance Builder (SAB) ISO**, which automates the installation of SafeSquid and all supporting services on any standard Intel-based Linux system in under 15 minutes. The SAB ISO handles OS preparation, service configuration, and dependency resolution without manual package management.

Alternative deployment paths:

* **Cloud deployment** — deploy on AWS, Azure, GCP, or any cloud instance running a supported Linux distribution.
* **Virtual machine** — deploy on VMware, KVM, Hyper-V, or XenServer using the SAB ISO or a manual Linux installation.
* **Existing Linux server** — install SafeSquid on a supported Ubuntu or CentOS host if the SAB ISO path is not available.

See [SafeSquid Appliance Builder](/SafeSquid_Appliance_Builder) or [Cloud Deployment](/Cloud_Deployment) for step-by-step installation instructions.

### Step 3 — Route client traffic through the gateway

After deployment, route outbound web traffic through SafeSquid using the client onboarding method that matches endpoint governance:

* **Explicit proxy** — configure browser or OS proxy settings to point to the SafeSquid IP and port.
* **PAC file** — distribute a proxy auto-configuration file for managed endpoints.
* **Transparent proxy** — redirect HTTP and HTTPS traffic at the network layer without client configuration.
* **Enterprise deployment** — use Group Policy Objects or MDM to push proxy settings to all managed endpoints.

See [Onboard Client Traffic](/Explicit_Proxy) for setup instructions per method.

### Step 4 — Activate the license and configure policy

Log in to the **Configuration Portal** at `http://safesquid.cfg` (accessible from the proxy host or a routed management network). Activate the license under **Configuration → Activate**, then enable SSL inspection, configure URL categories, set up user identity integration, and define acceptable-use policies.

See [Configuration Portal](/Configuration_Portal) for the full administration reference.

## ⚠️ Common deployment pitfalls

**⚠️ SSL inspection not enabled at deployment:** HTTPS traffic bypasses content inspection if SSL inspection is not configured. The gateway logs a connection but cannot evaluate URL, payload, or application signature. Enable SSL inspection under **Configuration → SSL Inspection** and distribute the SafeSquid Root CA to all managed endpoints before routing production traffic.

**⚠️ Activation key not applied before traffic routing:** The SafeSquid proxy engine operates in restricted mode without a valid activation key. Apply the key from the Self-Service Portal under **Configuration → Activate** before directing live traffic through the gateway.

**⚠️ Client traffic bypasses the proxy:** Transparent proxy mode requires a network-layer redirect rule on the firewall or router. If endpoints can reach the internet directly, policy enforcement and logging do not occur. Verify that all outbound HTTP and HTTPS traffic traverses the SafeSquid listener ports.

**⚠️ Intelligence feeds blocked by egress firewall:** SafeSquid requires outbound HTTPS access to cloud intelligence feed endpoints for URL classification, threat data, and application signatures. Block these feeds and the policy engine falls back to cached or empty category data. Review feed connectivity requirements in the [Architecture](/safesquid_swg/architecture/safesquid_swg) reference before deploying in restricted-egress environments.

## Next steps

* [SafeSquid SWG Architecture](/safesquid_swg/architecture/safesquid_swg) — platform components, data flow, and cluster topology.
* [Register and Get Your Key](/Register) — activation key acquisition and Self-Service Portal setup.
* [Configure SSL Inspection](/Configure_HTTPS_Inspection) — TLS termination setup, Root CA distribution, and bypass policy.


## Related topics

- [DNS Security](/use_cases/dns_security/dns_security.md)
- [Authentication](/use_cases/authentication/authentication.md)
- [SSL Inspection](/use_cases/ssl_inspection/ssl_inspection.md)
- [FAQs](/faqs/faqs.md)
- [Welcome to SafeSquid](/getting_started/welcome.md)