KNOWLEDGE ARTICLE
What Is HTTPS?
HTTP over TLS
Transports HTTP requests and responses through a TLS-protected connection.
At a glance
HTTPS protects traffic between client and TLS endpoint and validates the requested domain through certificates. With a CDN or proxy, TLS may terminate at an edge; the origin connection needs separate protection.
The protection HTTPS adds to HTTP
HTTPS carries HTTP over TLS. The browser validates the requested hostname through a certificate and negotiates an encrypted channel before sending requests, cookies and page content. This reduces interception and tampering in transit and authenticates the certificate-covered endpoint.
Protection runs from client to TLS termination point. A CDN or reverse proxy may terminate the browser connection at an edge, requiring another protected link to the origin. A lock icon does not assess business identity, page claims or transaction reliability.
Stages of an HTTPS visit
- DNS supplies an entry address. The client establishes TCP or QUIC connectivity and sends negotiation information, including the intended hostname, through the TLS process.
- The server supplies a certificate chain. The client checks SAN names, validity, trust paths, algorithms and applicable revocation information.
- Key exchange derives session keys. After the handshake, HTTP requests and responses receive confidentiality and integrity protection.
- HTTP/2 commonly runs over TLS; HTTP/3 uses QUIC with TLS 1.3. Transport behavior differs, but the application semantics remain HTTP.
Mixed content, redirects and HSTS
An HTTPS page that loads HTTP scripts, images or APIs creates mixed content. Browsers may block active content or apply upgrading behavior. HTTPS migration therefore includes resource URLs, APIs, canonical links and sharing metadata.
HTTP-to-HTTPS 301 or 308 redirects guide visitors to encryption. HSTS makes known hosts use HTTPS before a network request begins. Stabilize certificates before broadening HSTS scope: an incorrect policy can prevent users from falling back during failures.
Practical use and interpretation
Accessibility over HTTPS, final URLs, certificate validation and negotiated protocols can be tested directly. Successful results support basic transport-protection conclusions. An HTTPS-shaped URL without a completed handshake leaves connection status unknown.
Valid certificates do not prove trustworthy content, and free certificates do not inherently provide weaker encryption. Specific risks need evidence such as hostname mismatch, expiry, weak protocols, mixed content or a confirmed chain error.
Points to consider
HTTPS is a baseline for modern sites, not a guarantee that content, operators or transactions are trustworthy.
Frequently asked questions
Is it safe to enter a password whenever HTTPS is present?
HTTPS protects transit and authenticates the connection domain. You must still verify the intended domain, operator, business and page security.
Why can an HTTPS page still show an insecure warning?
Possible causes include expiry, name mismatch, chain errors, mixed content, incorrect system time or a certificate substituted by network equipment.
Is an HTTP-to-HTTPS redirect enough?
It is a baseline. Update resource URLs, Secure cookies and canonical links, then consider HSTS after the site is reliably available over HTTPS.