# HTTPS and TLS

HTTPS is HTTP inside a TLS tunnel. It gives you three things: nobody between client and server can read the exchange, nobody can alter it undetected, and the client can verify the server is who the certificate says. It gives you nothing about what either end does with the data afterwards, and it stops protecting anything the moment a proxy terminates the tunnel.

- **Status:** Reference
- **Audience:** developer, both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/https/

## Three guarantees, precisely stated

**Confidentiality** — The request line, headers, cookies and body are unreadable to anything on the path. This is why a session cookie can cross the public internet at all.
**Integrity** — A modification in flight breaks the record and is detected. An attacker can drop your connection; they cannot quietly edit one field of a webhook.
**Server authentication** — The certificate chain proves the server owns the name you asked for. Note the direction: by default the server is proved to you, not you to the server.

Client authentication is a separate mechanism and a separate decision. On Connect, proving who the *caller* is happens above TLS — a session cookie established through Google OAuth for a person, an integration key for a machine — never by the fact that the connection was encrypted.

## What it does not cover

- **Which host you contacted.** The name is visible in DNS and, in the common case, in the TLS handshake. Encryption hides the conversation, not the fact that it happened.
- **Shape and timing.** Sizes and intervals leak. A long silence followed by one large upload is legible without a single decrypted byte.
- **Anything at rest.** Storage encryption is an unrelated control with unrelated failure modes. A perfectly configured tunnel delivers data into a database whose protection you have to arrange separately.
- **The endpoints themselves.** A valid certificate says nothing about whether the server is compromised, or whether the person holding the browser is who the session says. Prompt injection arrives over a flawless TLS connection.

## Where a proxy changes the picture

In almost every production deployment the tunnel does not reach the application. A load balancer or reverse proxy terminates TLS and speaks to the application behind it. From that point on, three things the application would like to know are no longer facts it can observe — they are claims it has been handed.

| Fact | Where it now comes from | The failure it causes |
|---|---|---|
| The client's IP address | A forwarded header the proxy adds | Rate limits and audit entries record the proxy, or trust a header a client set itself |
| Whether the request was encrypted | A forwarded protocol header | The app builds `http://` redirect and callback URLs, and an OAuth flow that requires HTTPS refuses them |
| The host the client asked for | The `Host` header, which anyone can set | Absolute URLs are generated for an attacker-chosen name unless allowed hosts are enforced |

> **Careful** A forwarded header is only as trustworthy as the hop that set it. If anything other than your own proxy can reach the application directly, those headers are attacker-controlled input and must be treated as such — including for anything that makes a security decision.

## Does Connect use HTTPS?

**Used, and required.** The public site and the application at `/app` are served over it, every inbound provider webhook arrives over it, and Google OAuth — the only sign-in Connect has — will not accept a redirect target that is not HTTPS. There is no password login to fall back to, so there is no configuration in which a person authenticates over plain HTTP.

One protocol-level requirement is worth naming because it is easy to miss when writing a client: the MCP revision Connect implements requires the server to validate the `Origin` header and answer **403** when one is present and invalid. That is an origin check, not a transport check — TLS being healthy does not exempt a request from it.

## Questions

### Does HTTPS mean a webhook is authentic?

No. It means the connection to your endpoint was not tampered with, and that you reached the host you asked for. It says nothing about whether the sender is the provider it claims to be — anyone can open an encrypted connection to a public URL. Authenticity comes from verifying the payload signature.

### Is a certificate warning ever safe to click through in an integration?

Disabling verification removes the only thing distinguishing the real server from anything that can answer on that address, and it disables integrity as well as identity. If a certificate fails in a test environment, fix the trust store rather than the client.

### Where does encryption at rest fit?

It is a different control for a different threat — someone reaching the storage rather than the wire. Connect's data sits in PostgreSQL with row-level security forced on every scoped table, which is an isolation control, not an encryption one. They are complementary and neither substitutes for the other.

## Related

- [HTTP](https://connectbyjbrh.com/docs/technology/http/)
- [OAuth 2.0](https://connectbyjbrh.com/docs/technology/oauth/)
- [Provider webhook signatures](https://connectbyjbrh.com/docs/technology/webhook-signature/)
- [Encryption at rest](https://connectbyjbrh.com/docs/technology/encryption-at-rest/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [Content Security Policy](https://connectbyjbrh.com/docs/technology/csp/)

## What this page is based on

- Connect source pack (docs-source/sources/GENERAL.md §10) — Google OAuth only, closed schema endpoints
- Connect capability registry (docs-source/facts.py) — PROTOCOLS.mcp security
- https://www.rfc-editor.org/rfc/rfc8446 — TLS 1.3
- https://www.rfc-editor.org/rfc/rfc9110 — HTTP Semantics