Security and TLS

Where TLS terminates

• *.cruma.io hostnames: TLS is terminated on the Cruma ingress using Cruma-managed certificates.
• Custom CNAME hostnames: TLS is intended to terminate on your agent; keep issuance under your control (CAA/pinning/mTLS) to enforce that. You are responsible for serving a valid certificate for those hostnames on the agent/backend.

What we can see

• For *.cruma.io hostnames, TLS terminates on Cruma ingress. Payloads are technically accessible to Cruma infrastructure. Today we only handle what’s needed for routing/telemetry (e.g., counts/health) and do not run MITM features; if we ever add a feature that needs payload inspection, it would be explicitly opt-in.
• For custom CNAME hostnames, TLS is intended to terminate on your agent. Cruma sees control-plane metadata (tunnel ID, target types, health/connection status) plus request/byte counts for abuse prevention. Payloads remain with your agent as long as you keep issuance/pinning under your control (see below).

Inspection and opt-in

• Ingress-terminated traffic (*.cruma.io) can be inspected in principle because TLS ends on Cruma. No payload inspection is performed today beyond what’s required to operate the service; any future feature needing payload visibility would be opt-in.
• For custom CNAME hostnames, Cruma infrastructure could technically obtain and present a certificate if allowed by your DNS/CAA settings. Use CAA and pinning/mTLS to prevent that; with those controls in place, only your agent can present an acceptable certificate to clients, so Cruma cannot inspect payloads.

Hardening options (custom domains)

• If you want to be certain that traffic is not intercepted, pin the certificate that your agent presents for your custom hostnames. Clients will reject any different cert, preventing a silent MITM. Pinning is advanced and makes rotation more complex; use it only if your security model requires it.

CAA and issuance control (custom domains)

• If you use your own domain with a CNAME, set CAA records on that domain to restrict which CA can issue certificates for your custom hostnames. This prevents Cruma (or anyone else) from obtaining a cert for your domain if not authorized. See Let’s Encrypt CAA docs and Cloudflare’s take on CAA/pinning (CAA records to restrict which CAs can issue certificates for a domain) for details.
• Example (permit only your chosen CA for a hostname):

app.yourdomain.com.  CAA 0 issue "letsencrypt.org"

• For tighter control, use accounturi with Let’s Encrypt to limit issuance to your own ACME account:

app.yourdomain.com.  CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/<your-acct-id>"

Combine CAA with pinning (or mTLS) on your custom hostnames to ensure clients will not accept certificates issued anywhere other than your agent. Even though Cruma infrastructure could technically obtain and present a certificate for a hostname you CNAME to us, these controls prevent your clients from accepting it.

How this compares

• Terminating TLS at the provider edge for default hostnames (e.g., *.cruma.io) is the same model used by Cloudflare/ngrok for their default domains.
• If you want payload privacy end-to-end, use a custom hostname that terminates TLS on your agent and enforce it with CAA + pinning/mTLS so only your cert is accepted. We do not inspect payloads today; any future feature that would require payload inspection would be explicitly opt-in.