Skip to main content
CID222 Docs

Deploy the inline proxy

Turn on CID222's own forward proxy, distribute its certificate authority, point browsers at it with a proxy auto-configuration file, and prove a detection fires.

  • Version: 0.4
  • Feature: icap
  • Role: admin_user
  • Type: task

Make CID222 the secure web gateway for browser traffic to model providers. You start the forward-proxy container, distribute the certificate authority it generates, point managed browsers at it, and confirm that a prompt containing personal data is masked or refused before it leaves the network.

What do I need?

Licence
Any
Role
admin_user

Prerequisites

  • The appliance has completed the first-boot setup wizard and you can sign in to the dashboard.
  • You can run compose commands on the appliance host, or your operator can.
  • The customer has no secure web gateway of their own — if they do, connect it instead, see ICAP and third-party gateways.
  • Endpoints are centrally managed, so a certificate authority and a proxy setting can be pushed to them.
  • TCP 8443 on the appliance is reachable from the client subnets, and free on the appliance host.
  • Saving the appliance-wide inspection policy requires the superadmin account.

The proxy decrypts the session with a certificate authority it generates on first start. Every client whose traffic it intercepts must trust that authority, or the browser refuses the connection with a certificate error. Distributing it is not an optional hardening step; it is the deployment.

Warning

Inspect a given hostname at one point only. If the customer also runs a gateway that sends the same hostnames to CID222, turn that off before you turn this on — a doubly inspected image upload is refused.

Start the proxy and publish its certificate authority

Start the inline-proxy profile

On the appliance host, start the opt-in profile:

docker compose --profile inline-proxy up -d cid-inline-proxy

The container starts, and its first log lines report the certificate authority and the listen modes:

[cid-inline-proxy] CA generated at /root/.mitmproxy/mitmproxy-ca-cert.pem
[cid-inline-proxy] HTTPS explicit proxy: regular/direct (listen :8443)
[cid-inline-proxy] starting mitmdump regular@8443 + transparent@8084

The authority is generated once and kept in a volume, so a restart reuses it and reports reusing existing CA instead.

Confirm the appliance sees it

Select Detection & Filtering → Browser Inspection and read the Root CA certificate & PAC panel.

The panel shows CA fingerprint (SHA-256) with the authority's fingerprint. While the container is not running it shows Inline proxy is not running on this appliance instead, and the download buttons stay disabled.

Download the certificate authority

Select the format your endpoint management wants: cid222-root.crt, cid222-root.pem or cid222-root.cer.

The file downloads. The .cer form is binary DER, which is what Windows expects; the other two are PEM text.

Check the fingerprint out of band

Compare the CA fingerprint (SHA-256) shown in the panel with the fingerprint your appliance operator gives you by another channel.

They match. If they do not, stop — you are about to make every managed endpoint trust a certificate authority that is not the appliance's.

Distribute the certificate authority to clients

Push it as a trusted root

On a domain controller, edit or create a Group Policy object linked to the organisational unit holding your managed endpoints, and import the downloaded file under Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.

On the next policy refresh, the authority appears in each endpoint's trusted root store. Refresh one machine immediately with gpupdate /force to test.

Cover browsers that keep their own trust store

Chrome, Edge and Internet Explorer read the Windows root store. Firefox does not: set its security.enterprise_roots.enabled policy so it honours the system store.

A Firefox left unconfigured shows a certificate warning on every intercepted site, which is how you notice this step was skipped.

Route traffic through the proxy

The appliance serves a proxy auto-configuration script at https://<appliance-fqdn>/proxy.pac. /wpad.dat serves the identical script for clients that discover a proxy automatically. Both are unauthenticated, because a client fetches them before it has any credential, and both are cached by the client for five minutes.

The script is generated from the live inspection policy. Every enabled hostname returns PROXY <appliance>:8443; DIRECT for that host and its subdomains; every bypass hostname and everything else returns DIRECT. The appliance name in the script is the host the client used to fetch it, so the same URL works by name or by address.

Push the URL to managed browsers with the Internet Settings policy preference, under User Configuration → Preferences → Control Panel Settings → Internet Settings: enable Use automatic configuration script and set Address to the URL. Chrome and Edge follow the Windows proxy setting.

Set the inspection policy

Open the policy

On Browser Inspection, read the Policy configuration panel.

The fields are Enabled hostnames, Bypass hostnames, Allowed ICAP peer IPs / CIDRs, Inspection timeout (ms), mTLS client subject DN, Fail closed (BLOCK) on timeout and Policy active.

List the hostnames to inspect

Put one hostname per line in Enabled hostnames.

Saving replaces the built-in default list, so carry forward every host you still want covered. The default list is the conversation endpoints — chat.openai.com, chatgpt.com, claude.ai, gemini.google.com, chat.deepseek.com, chat.qwen.ai, poe.com, character.ai — and the separate hosts that carry uploaded file bytes: oaiusercontent.com, push.clients6.google.com and a-cdn.claude.ai.

Exclude what must never be read

Put banking, payroll, human-resources and legal hostnames in Bypass hostnames.

A bypassed host returns DIRECT in the auto-configuration script, so those sessions are never decrypted.

Choose what happens when inspection is slow

Set Inspection timeout (ms), and decide Fail closed (BLOCK) on timeout.

Closed refuses a request the pipeline could not finish in time; open forwards it uninspected. There is no third option and no background retry — inspection is synchronous.

Save

Turn on Policy active and select Save policy.

The panel reports Inspection policy updated. The auto-configuration script picks the new hostnames up within the five-minute client cache.

Note

Allowed ICAP peer IPs / CIDRs does not apply to this deployment. It gates peers dialling the ICAP listener on port 1344; the inline proxy calls the gateway's HTTP inspection endpoint from the appliance itself.

What is actually inspected

The proxy does not inspect everything from an enabled hostname. It matches a strict allowlist of conversation and upload endpoints — fifteen rules covering ChatGPT, the OpenAI API, GitHub Copilot chat, Claude, Gemini, DeepSeek, Qwen, Poe and Character.ai — and forwards everything else from those hosts untouched. A single page load fires dozens of requests for scripts, fonts and telemetry; none of them carries a prompt, and inspecting them produced both latency and false positives.

Three consequences are worth stating before the first support call:

  • A provider not on the list is not inspected, even if its hostname is routed through the proxy. New frontends need a rule.
  • Large bodies are skipped, not blocked. Text bodies over 512 KB and binary bodies over 25 MB are forwarded without inspection.
  • Fragmented uploads are refused. A chunked or resumable upload cannot be inspected one fragment at a time, so CID_RESUMABLE_UPLOAD_POLICY defaults to block and the browser sees a failed upload. Setting it to passthrough restores the old behaviour, in which the file reaches the provider unredacted.

Verify

  1. From a managed workstation, open one of the enabled hostnames. The page loads with no certificate warning, and the certificate the browser reports is issued by the CID222 proxy authority rather than the provider's own.
  2. Browse to a hostname that is not in the policy. Its certificate is the real one, proving that site is not being decrypted.
  3. In the same session, send a prompt containing a recognisable test value — a fake card number such as 4111 1111 1111 1111. Depending on the rule's action, the provider receives the value masked, or the browser shows the Request blocked page carrying the header X-Blocked-By: cid-core.
  4. Select Detection & Filtering → All Detections and filter the source to browser traffic. The attempt appears within seconds as MESSAGE_MASKED or MESSAGE_BLOCKED, with the hostname, the source address and the reasons.
  5. Upload an image containing readable personal data to an enabled provider. The event FILE_UPLOAD_REDACTED appears, and the model describes the fields as blacked out. What the model says is the ground truth here — the thumbnail in the browser is always your local original.

If it fails

  • The browser shows a certificate-authority error on every intercepted site → the authority is not in that machine's trust store. Confirm with certutil -store Root | findstr cid222, then force a policy refresh.
  • The authority is installed and warnings continue → the appliance was reset and regenerated the authority. The fingerprint in the panel no longer matches the one deployed; re-download and re-distribute.
  • The auto-configuration URL is reachable but nothing is proxied → the proxy setting did not reach the browser. Check the policy preference applied, and that INLINE_PROXY_PUBLIC_PORT — the port the script advertises — matches INLINE_PROXY_HTTPS_PORT, the port the proxy listens on. When they disagree, browsers connect somewhere else and no error appears anywhere.
  • Events arrive but the panel shows the container as not running → A service is unhealthy.
  • Uploads fail with no redaction event → the host carrying the file bytes is missing from Enabled hostnames. Upload hosts are separate from conversation hosts.

Next steps

Last updated on

On this page

Download PDF