HTTPS and SSL/TLS are the protocols that make encrypted web connections possible. When you visit a website and see the padlock icon in your browser’s address bar, the underlying technology is TLS (Transport Layer Security, the successor to the older SSL). The combination of TLS plus HTTP gives you HTTPS, which is what every legitimate website now uses by default. Understanding these protocols at a high level matters for any business operator because they affect security, SEO, browser warnings, customer trust, and the cost of running a website. The good news is that the protocols are mature; the operational discipline is mostly about not breaking them.
This post walks through what HTTPS and TLS actually are, what they protect against, how the protocols work at a conceptual level, why HTTPS is now table stakes rather than a premium feature, and what business owners need to know operationally.
What HTTPS and TLS actually are
HTTPS stands for HyperText Transfer Protocol Secure. It’s the secure version of the standard HTTP protocol that browsers use to talk to web servers. The "secure" part comes from layering TLS (Transport Layer Security) underneath the HTTP traffic, so the data exchanged between the browser and the server is encrypted in transit.
TLS is the cryptographic protocol that does the actual security work. It does three things:
- Encrypts the connection, so anyone watching the network in between (the WiFi access point, the internet service provider, anyone intercepting at intermediate hops) can’t read the content.
- Authenticates the server to the browser, so the browser can verify it’s actually connecting to the legitimate server and not an attacker pretending to be that server.
- Protects data integrity, so an attacker can’t modify the data in transit without the modification being detected.
SSL is the older name. SSL (Secure Sockets Layer) was the original protocol, developed by Netscape in the mid-1990s. SSL went through versions 1.0 (never released), 2.0, and 3.0. In 1999 the protocol was renamed TLS and continued evolving (TLS 1.0, 1.1, 1.2, 1.3). The current version, TLS 1.3, was finalized in 2018. The "SSL" name persists in casual usage and in product names ("SSL certificate") even though the actual protocol in use is TLS.
In current usage, when someone says "SSL" they almost always mean TLS. The older SSL versions are deprecated and disabled in modern browsers because they have known vulnerabilities.
What HTTPS protects against
HTTPS defends against several categories of attack that were routine on the early HTTP-only web.
Eavesdropping. Anyone on the network path between your device and the server (the coffee-shop WiFi access point, your ISP, intermediate routers, anyone watching network traffic at any hop) cannot read the content of HTTPS traffic. They can see that you connected to a particular server, but they can’t see what page you loaded or what data you sent.
Man-in-the-middle attacks. An attacker who intercepts the connection can’t successfully impersonate the legitimate server because the TLS certificate authentication will fail. The browser will display a warning rather than silently connecting to the attacker.
Content modification. An attacker between you and the server cannot modify the data without breaking the TLS integrity checks. Ad injection, tracking-script insertion, and similar tampering that was common on HTTP-only public WiFi is blocked by HTTPS.
Session hijacking via passive observation. Login session cookies and authentication tokens are encrypted in transit, so a network observer can’t capture them and reuse them to impersonate the user.
What HTTPS doesn’t protect against
HTTPS is not a complete security control. The limitations:
- Server-side compromise. If the server itself is compromised, HTTPS doesn’t help; the attacker is already inside the system the encryption is protecting.
- Browser or device compromise. Malware on the user’s device sees data after decryption.
- Phishing. A phishing site can use HTTPS just as legitimately as a real site (it’s trivial to get a TLS certificate for any domain you control, including a typosquat domain). The padlock means “the connection is encrypted to this server,” not “this server is trustworthy.”
- DNS-level observation. The DNS lookup that translates a domain name to an IP address can still reveal which site you’re visiting, even though the content is encrypted. DNS over HTTPS (DoH) and DNS over TLS (DoT) address this gap separately.
- Traffic metadata. An observer can see the volume of traffic, the timing, and the rough endpoints, even if they can’t read the content. Traffic-analysis attacks use this metadata.
- Application-layer attacks. Cross-site scripting, SQL injection, and other web-application attacks pass through HTTPS the same way legitimate traffic does. HTTPS protects the channel; it doesn’t sanitize the content.
The mental model: HTTPS is necessary but not sufficient. It addresses a specific category of threats well; other security controls handle the categories HTTPS doesn’t cover.
How TLS works at a conceptual level
You don’t need to be a cryptographer to operate websites that use TLS correctly, but a sketch of how the protocol works helps demystify the operational pieces.
When a browser connects to a server over HTTPS, the first thing that happens is a TLS handshake:
- The browser tells the server which TLS versions and cipher suites it supports.
- The server picks the strongest mutually-supported option and sends back its **TLS certificate**.
- The certificate contains the server’s public key and is signed by a **Certificate Authority (CA)** that the browser trusts.
- The browser verifies the certificate’s signature against its list of trusted CAs, and verifies that the certificate is valid for the domain it’s connecting to.
- If verification succeeds, the browser and server perform a cryptographic key exchange that establishes a shared secret known only to the two of them.
- All subsequent traffic in the session is encrypted with that shared secret.
The certificate is the part that makes the system work. Anyone can offer encryption, but trust requires a third party (the Certificate Authority) to vouch for the server’s identity. The browser’s pre-installed list of trusted CAs is what closes that trust loop without requiring the user to verify each new site manually.
If something goes wrong (expired certificate, certificate doesn’t match the domain, the issuing CA isn’t trusted, the cipher suites don’t match, the certificate has been revoked), the browser shows a warning and may refuse to load the site at all. The browser warnings exist precisely because TLS failures often indicate either misconfiguration on the server side or an active attack.
Why HTTPS is now table stakes
HTTPS used to be optional, used primarily by sites that handled sensitive data (banking, login pages, e-commerce checkout). Several shifts over the past decade made HTTPS the default for every site, not just sensitive ones.
Browser warnings became aggressive. Modern browsers warn users when they visit HTTP-only sites, especially when those sites have any input fields. The warnings range from subtle ("Not secure" in the address bar) to disruptive (full-page warnings before the user can proceed). HTTP-only sites lose conversions because users back away from the warnings.
Search engines treat HTTPS as a ranking signal. Google has confirmed HTTPS as one of many ranking signals since 2014. The boost is small per signal but adds up at scale; HTTP-only sites are at a measurable disadvantage in organic search.
Modern web features require HTTPS. Service workers, geolocation, the Web Push API, the Notification API, modern camera and microphone access, HTTP/2 in most browsers, and a growing list of other web platform features only work over HTTPS. Sites stuck on HTTP can’t use these capabilities.
Free certificates removed the cost barrier. Let’s Encrypt, which launched in 2015, provides free automated TLS certificates that work in all modern browsers. The certificate cost that used to justify HTTP-only deployments is gone.
Operational tooling matured. Automatic certificate issuance and renewal (through Let’s Encrypt clients like Certbot, through hosting platforms that handle TLS automatically, through cloud providers’ managed certificate services) removed most of the operational burden.
The result: by 2025, HTTPS adoption is essentially universal among serious websites. Sites still operating on HTTP-only are signaling either deep technical debt or active disinterest in their users’ experience.
What business owners need to know operationally
You don’t need to manage TLS certificates manually if your hosting situation is set up reasonably. Modern managed-WordPress hosts (WP Engine, Pantheon, Kinsta, Cloudways, SiteGround), cloud platforms (AWS, Azure, GCP), and SaaS website builders (Squarespace, Wix, Shopify) all handle certificate provisioning and renewal automatically. The operational ask is "use a host that handles TLS for you," not "become a TLS expert."
A few specific things to confirm:
- Your site loads over HTTPS by default. Type your domain into a browser and confirm it loads with the padlock. If it loads as HTTP and you have to add “https://” manually, the host’s HTTPS configuration isn’t complete.
- HTTP requests redirect to HTTPS. A user (or a bot) that visits the HTTP version should automatically be redirected to the HTTPS version. Most hosts handle this; it’s worth verifying.
- The certificate is valid and current. Browsers tell you (in the certificate details panel) when the certificate expires. Automated renewal should handle this, but if certificates are about to expire and you don’t know why, something has broken.
- Mixed-content warnings are resolved. If your HTTPS pages reference HTTP-only assets (images, scripts, stylesheets), browsers either block the asset or show a warning. The fix is to update the references to HTTPS.
- The site doesn’t generate browser warnings. If users see “Not secure” or worse on your site, fix it before doing anything else. Browser warnings damage trust and conversions immediately.
If your site is on a host that handles TLS automatically (which is now the norm), these are check-once items rather than ongoing operational work. If your site is on infrastructure that requires manual TLS management, the operational discipline is more substantial, and migrating to a host that automates it is usually worth the effort.
Frequently Asked Questions
Is SSL the same as TLS?
In current usage, yes. SSL was the original protocol, developed in the 1990s. In 1999 it was renamed TLS and continued evolving. The current versions are TLS 1.2 and TLS 1.3; older SSL versions (1.0, 2.0, 3.0) are deprecated and disabled in modern browsers. When products mention “SSL certificates,” they actually mean TLS certificates. The naming is a holdover from the original protocol name.
How much does an SSL/TLS certificate cost?
For most websites: nothing. Let’s Encrypt provides free automated certificates that work in all modern browsers and are trusted by every operating system. Many hosting platforms automate Let’s Encrypt provisioning, so you get certificates without any direct action. Commercial certificates from vendors like DigiCert, Sectigo, and others are still sold for cases where additional validation (extended validation certificates for legal entities) or enterprise-grade support is required, with prices ranging from tens to thousands of dollars per year.
Does HTTPS slow down my website?
The performance impact of HTTPS is minimal on modern infrastructure. The TLS handshake adds a small amount of latency on the first connection, but modern protocols (TLS 1.3, HTTP/2, HTTP/3) minimize this, and connection reuse means the handshake cost is paid once per session. For most websites the difference is unnoticeable. Some web platform features (HTTP/2, service workers) actually require HTTPS, so the encrypted version can be faster overall once those features are in use.
Do I need HTTPS if my site doesn’t handle sensitive data?
Yes, in practical terms. Browser warnings, search ranking signals, and the increasing list of web platform features that require HTTPS all push every site toward encryption, regardless of whether it handles sensitive data. The marginal cost of HTTPS is near zero on modern hosting; the cost of being the rare HTTP-only site is increasingly noticeable.
What does the padlock icon in the browser actually mean?
The padlock indicates that the connection to the server is encrypted and the server’s identity has been verified against a trusted Certificate Authority. It does NOT mean the website itself is trustworthy. Phishing sites can and do use valid TLS certificates; the encryption protects the connection, not the legitimacy of the site you’re connecting to. The padlock is necessary but not sufficient as a trust signal.
