HTTPS, SSL & Security
What is a secure connection?
A secure connection is a network communication channel between a client, typically a browser, and a server that provides three fundamental security properties, encryption, authentication, and integrity. Encryption ensures that data transmitted between the two parties cannot be read by anyone intercepting the traffic. Authentication ensures the client is connecting to the genuine intended server rather than an impostor. Integrity ensures that data cannot be modified in transit without detection. A connection that provides all three properties is considered secure, a connection that lacks any of them has meaningful security gaps regardless of what other protections are in place.
On the web secure connections are implemented through HTTPS: HTTP layered over TLS. The TLS protocol provides the encryption, authentication, and integrity mechanisms that transform an ordinary HTTP connection into a secure one. When a browser’s address bar shows a padlock icon the connection is secured by TLS, the three security properties are in effect for the current session.
The concept of a secure connection is distinct from a secure website. A site can have a secure connection, all traffic encrypted and authenticated, while hosting insecure or malicious content. The padlock confirms the connection is secure, it does not certify the legitimacy or safety of the site’s content. A phishing site can have a valid SSL certificate and a secure connection while being entirely malicious. This distinction is important for understanding what HTTPS actually guarantees and what it does not.
The three properties of a secure connection
A genuinely secure connection requires all three security properties simultaneously, encryption, authentication, and integrity. Understanding each clarifies what is actually being protected and what failure modes exist when any property is missing.
Encryption: the transformation of plaintext data into ciphertext that is unreadable without the correct decryption key. On a TLS connection all data transmitted between browser and server, HTTP request headers, request bodies, response headers, response bodies, is encrypted with symmetric session keys derived during the TLS handshake. A network observer who intercepts the encrypted traffic sees only random-appearing bytes, the actual content is inaccessible without the session keys.
Encryption protects confidentiality, the content of communication is private between the parties who share the session keys. Without encryption all HTTP traffic is transmitted as readable plaintext, anyone on the network path between browser and server can read credentials, form submissions, cookies, page content, and any other transmitted data.
Authentication: verification that the server the browser connected to is genuinely the server it intended to connect to, not an impostor who intercepted the connection. TLS authentication is provided through SSL certificates: the server presents a certificate issued by a trusted certificate authority that proves the server’s identity is verified.
When a browser connects to https://bank.com and receives a certificate for bank.com issued by a trusted CA the browser can be confident it is connected to a server controlled by whoever the CA verified as the legitimate bank.com operator. Without authentication encryption alone provides no useful security, an encrypted connection to an attacker who has impersonated bank.com encrypts the victim’s credentials on their way to the attacker.
Integrity: verification that data has not been modified between transmission and receipt. TLS uses message authentication codes, MACs, to verify that each message was not altered in transit. The MAC is computed from the message content using a key derived during the handshake, an attacker who modifies the message cannot compute a valid MAC for the modified version, and the receiver detects the tampering.
Without integrity protection a man-in-the-middle attacker who cannot read encrypted traffic, because they lack the session keys, could still modify it blindly, flipping bits in encrypted data and hoping the modifications produce useful changes. TLS integrity protection detects any modification, the connection is terminated if tampering is detected.
What makes a connection not fully secure
Many connections appear secure but have specific weaknesses that undermine one or more of the three security properties.
Invalid or expired SSL certificate: a certificate that has expired, is not issued by a trusted CA, or does not cover the domain being connected to fails the authentication property. Browsers display certificate error warnings for invalid certificates, the connection may still be encrypted but the identity of the server has not been verified. An attacker using a self-signed certificate can provide encryption while completely failing to provide authentication, the encrypted channel is established with an unverified entity.
Weak TLS version or cipher suite: connections using deprecated TLS versions, SSL 3.0, TLS 1.0, TLS 1.1, or weak cipher suites, RC4, export-grade encryption, null encryption, are cryptographically weaker than modern TLS 1.3 connections. Known attacks against these versions, POODLE against SSL 3.0, BEAST against TLS 1.0 CBC ciphers, can potentially break the encryption property. Modern browsers refuse to connect over deprecated TLS versions.
Mixed content: an HTTPS page that loads resources, scripts, stylesheets, iframes, over HTTP has mixed content. The page itself was loaded securely but resources loaded over HTTP are transmitted without encryption or authentication. An attacker who can modify HTTP traffic, by intercepting a coffee shop Wi-Fi connection, can replace HTTP-loaded JavaScript with malicious code even though the page itself was delivered securely. Active mixed content is blocked by modern browsers, passive mixed content, images, audio, video, degrades the integrity of the page’s presentation.
HSTS not in effect: without HSTS a user’s first connection to an HTTPS site may go over HTTP, if they typed the domain without specifying HTTPS or followed an HTTP link. During the HTTP connection and before receiving the redirect to HTTPS the connection is insecure. HSTS and HSTS preloading eliminate this vulnerability window by ensuring browsers always connect over HTTPS.
Revoked certificate: a certificate whose private key was compromised should be revoked by the certificate authority, marked as no longer trustworthy. Browsers that check revocation status, through OCSP or CRL, detect revoked certificates and warn users. However revocation checking has historically been unreliable, OCSP checks add latency and often fail silently. A revoked certificate whose revocation is not checked by the browser appears valid, authentication is compromised even though the connection appears secure.
Secure connections and web indicators
Browsers communicate connection security status through visual indicators, helping users understand the security of their current connection at a glance. These indicators have evolved significantly as HTTPS has become the norm rather than the exception.
The padlock icon: the padlock icon in the browser address bar indicates that the current connection is secured by TLS with a valid certificate, encryption and authentication are in effect. Clicking the padlock reveals certificate details, the issuing CA, the certificate’s validity period, and the domain names covered.
The “Not Secure” warning: Chrome and other modern browsers display “Not Secure” in the address bar for HTTP connections, explicitly flagging the absence of encryption. This warning was introduced progressively, initially only on pages with forms, then on all HTTP pages. The warning makes the security absence visible rather than simply not showing the padlock.
Certificate error pages: when a certificate is invalid, expired, wrong domain, untrusted issuer, browsers display full-screen error pages rather than the padlock. Chrome shows NET::ERR_CERT_DATE_INVALID for expired certificates, NET::ERR_CERT_AUTHORITY_INVALID for untrusted issuers, and NET::ERR_CERT_COMMON_NAME_INVALID for domain mismatches. These errors block the connection by default, users must explicitly click through to proceed despite the warning.
The EV indicator, historical: extended validation certificates previously triggered a special browser indicator, the organisation name displayed in green in the address bar, providing a stronger visual signal that the certificate holder’s identity had been thoroughly verified. All major browsers removed prominent EV display between 2019 and 2020, EV certificates now appear identical to DV certificates in browser address bars. The rationale was that users did not reliably interpret the EV indicator correctly and that its security benefit did not justify the visual complexity.
Secure connections and redirect management
Secure connections are the infrastructure requirement that makes redirect management work correctly for HTTPS visitors, who represent the majority of modern web traffic.
HTTPS requirement for redirect sources: when a visitor follows an HTTPS link to a redirect source domain, https://old-domain.com: the browser must establish a secure TLS connection before receiving the redirect response. The TLS handshake requires the redirect source domain to present a valid SSL certificate. Without a valid certificate the TLS handshake fails, the browser displays a certificate error rather than following the redirect.
This requirement applies to every domain in a redirect portfolio. A brand protection domain with a perfectly configured redirect rule but an expired or missing SSL certificate is invisible to HTTPS visitors, they see a certificate error rather than being redirected. Ensuring every redirect source domain has a valid SSL certificate is a fundamental operational requirement for effective redirect management.
Secure connections through the complete redirect chain: security should be maintained throughout a complete redirect chain, from the initial request to the final destination. An HTTPS redirect source that redirects to an HTTP destination downgrades the connection, the visitor ends up on an insecure page despite starting from a secure URL. All redirects in a chain should point to HTTPS destinations, maintaining encryption, authentication, and integrity throughout.
SSL termination for redirect inspection: redirect management infrastructure must decrypt incoming HTTPS requests to read their content, the Host header, the URL path, and other request attributes needed to match redirect rules. SSL termination at the redirect management layer decrypts the TLS connection, reads the request, evaluates redirect rules, and returns a redirect response. Without SSL termination the redirect infrastructure cannot inspect the request content needed for redirect matching.
Secure connection verification in redirect testing: when testing redirect configurations verifying that the connection is secure is part of complete testing. A redirect that works over HTTP but fails over HTTPS, because the source domain lacks SSL, appears partially working when tested from an HTTP client but fails for the majority of real visitors who use HTTPS by default. Testing every redirect configuration over HTTPS, not just HTTP, confirms the complete visitor experience.
Verifying secure connections
Several tools and approaches verify that a connection is genuinely secure, checking all three security properties rather than just the presence of a padlock.
Browser developer tools security tab: Chrome, Firefox, and other browsers provide a Security tab in developer tools that shows the security status of the current connection, the certificate details, the TLS version negotiated, the cipher suite used, and any security issues detected. This provides a comprehensive view of connection security for any page.
SSL Labs SSL Test: ssllabs.com/ssltest performs comprehensive analysis of a domain’s TLS configuration, grading the certificate, checking supported TLS versions and cipher suites, testing for known vulnerabilities, verifying certificate chain validity, and checking HSTS status. The test provides an A+ through F grade with detailed findings, the industry standard tool for TLS security assessment.
Security headers check: securityheaders.com checks the security-related HTTP headers on a domain, HSTS, Content Security Policy, X-Frame-Options, and others. Security headers complement TLS in providing a complete security posture for a web property.
OpenSSL connection test: verifying the TLS handshake and certificate from the command line:
Shows the certificate chain, TLS version, cipher suite, and verification result, providing low-level details of the secure connection establishment.
Certificate expiry monitoring: automated monitoring that checks SSL certificate expiry dates and alerts before certificates expire. Essential for maintaining secure connections across a redirect domain portfolio, an expired certificate breaks the secure connection requirement for redirect sources.
Common secure connection issues
Certificate expired: the most common cause of secure connection failure. An SSL certificate past its expiry date triggers browser certificate errors, the connection cannot be authenticated. Automated certificate renewal and expiry monitoring prevent this.
Hostname mismatch: the certificate is valid but does not cover the domain being connected to. www.example.com connecting to a certificate valid only for example.com: or vice versa, produces a hostname mismatch error. Certificate coverage must include all accessed domain variants.
Incomplete certificate chain: the server presents the end-entity certificate but not the intermediate CA certificates needed for browsers to verify the trust chain. Some browsers can fetch missing intermediates, Chrome does, but others cannot. Servers should always present the complete chain.
Deprecated TLS version: attempting connections with TLS 1.0 or 1.1, deprecated and disabled in modern browsers. Servers must support TLS 1.2 as a minimum with TLS 1.3 preferred.
HTTP redirect destination: a redirect that sends visitors from an HTTPS source to an HTTP destination, downgrading the connection. All redirect destinations should be HTTPS URLs to maintain secure connections throughout the redirect chain.
Mixed content on destination pages: the redirect destination page loads resources over HTTP, creating mixed content that undermines the integrity property. Audit destination pages for mixed content after configuring redirects.