Channel property
HTTPS is HTTP sent over a TLS connection that authenticates the server name and protects data in transit. TLS provides channel confidentiality and integrity between its endpoints. It does not authorize the HTTP request, validate application data, or protect plaintext after termination.
Name and endpoint
The client connects to a host, negotiates TLS, validates the certificate chain and reference identity, and then sends HTTP within that channel. A reverse proxy can terminate the client channel and create a separate TLS channel to an upstream. Each termination is a trust boundary with its own name, certificate, keys, and policy.
Use current protocol
Prefer TLS 1.3 where supported. Configure protocol versions, cipher choices, certificate validation, name validation, and key lifecycle from current platform guidance. Treat DNS resolution as routing input, not proof of server identity.
Failure and residual risk
A valid certificate for the wrong name, skipped verification, stale trust anchor, compromised endpoint, plaintext upstream, or unsafe redirect defeats the intended channel. TLS cannot stop an authorized endpoint from disclosing data. Early data can be replayed and needs protocol-specific limits.
Pomerium boundary
Pomerium can terminate client HTTPS and establish a separate upstream connection. Operators must configure trusted names, certificates, and upstream transport. The application still owns HTTP semantics, object authorization, and data handling after TLS terminates.
Evaluation checklist
- What exact name does each TLS client validate?
- Where does TLS terminate and where does plaintext exist?
- Is every upstream hop authenticated and encrypted as required?
- Are legacy versions, disabled validation, redirects, and early data controlled?
- Do certificate issuance, rotation, revocation, and recovery have owners?
