How does HTTPS work?

What HTTPS adds to plain HTTP

https is not a different application protocol so much as HTTP wrapped in TLS. That changes three things that matter in practice: the server proves its identity with a certificate, the session is encrypted in transit, and message integrity is protected so intermediaries cannot silently alter traffic without detection.

For the browser or app, the page request and response still look like HTTP semantics after the TLS layer is established. The practical difference is that the client no longer sends requests in cleartext, and the server must present a certificate chain the client can validate before the connection is trusted.

What happens during the TLS handshake

Before any HTTP data flows, the client and server negotiate TLS parameters and establish shared session keys. The client checks that the certificate is valid for the server name, chains to a trusted certificate authority, and has not expired or been revoked in ways the client can verify. If that validation fails, the secure channel should not be treated as trustworthy.

Once the handshake succeeds, TLS derives symmetric keys for efficient encryption of the HTTP session. That gives confidentiality and integrity for the transport path, but it does not inspect or cleanse the application content itself. If the application sends sensitive data, the protection applies only while that data is moving between endpoints.

Modern deployments should prefer current TLS versions and strong cipher suites, because the security of HTTPS depends on the negotiated protocol and the validation behavior on both ends. Legacy versions, weak ciphers and certificate handling shortcuts tend to be the real failure points, not the HTTP layer itself.

Where HTTPS still fails in real deployments

HTTPS can be perfectly configured and still deliver weak security if certificate management, redirect handling or endpoint trust is sloppy. A site that allows plain HTTP without forcing redirect to HTTPS can expose users to downgrade and session theft risks before the secure channel is established. Mixed content can also weaken a page even when the top-level document is served over TLS.

Operationally, the most common breakpoints are expired certificates, hostname mismatch, stale trust chains and infrastructure that terminates TLS in one place but then forwards traffic over an unprotected internal hop. The external connection may look secure while the internal path is not, which matters whenever sensitive data or authenticated sessions traverse that segment.

Teams also need to watch for weak key custody around certificates and private keys. If the private key is exposed, the server can still appear valid to clients while an attacker can impersonate it or decrypt traffic in some threat models, so certificate security is part of the HTTPS story, not a separate concern.

Risk and Threat Considerations

HTTPS reduces exposure, but it does not eliminate trust risk. Attackers often target certificate validation failures, downgrade opportunities, stolen private keys or endpoints that quietly fall back to HTTP, because any of those weaknesses can let them intercept sessions or impersonate a server.

Failure mechanism: If the client accepts an invalid certificate, the connection can be intercepted by a man-in-the-middle. If the application permits plain HTTP or mixed transport paths, attackers can exploit the weaker path to capture credentials, session cookies or sensitive content.

Impact: Loss of confidentiality, session compromise and undetected content tampering become possible even though the application is “using HTTPS.” The security outcome depends on correct validation and enforced transport behavior, not just on the presence of TLS.

Practitioner Guidance

What to verify: Confirm that certificate validation is strict, redirects from HTTP to HTTPS are enforced at the edge, and no authenticated workflow depends on an unencrypted fallback path. Check that certificate expiry, hostname mismatch and untrusted chain errors are treated as hard failures, not warnings that users can bypass.

What good looks like: The browser never needs to “trust anyway,” the site never serves sensitive content over cleartext, and the TLS configuration is standardized across every endpoint that handles real user traffic. If internal termination points exist, treat them as security boundaries and verify the hop behind them as well.

Practitioner takeaway: HTTPS is only as strong as the certificate validation and transport enforcement around it, so the real control objective is to make insecure fallback paths impossible or immediately visible.

Related resources from NHI Mgmt Group

• Guide: Encryption Guide
• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?