When a website begins with https://, the browser is using HTTP over Transport Layer Security. TLS protects the connection so data can travel between a client and server with confidentiality, integrity, and authentication rather than moving across the network as readable, easily modified plaintext.

That secure connection sits on top of the same networking stack BitcoinVersus.Tech has already broken down through DNS, TCP, routers, and network interface cards. HTTPS is not a separate Internet—it is a protected application-layer conversation carried across that infrastructure.

HTTP vs. HTTPS

HTTP defines how browsers and web servers request and return web content. HTTPS uses HTTP inside a TLS-protected connection. The web request is still HTTP, but TLS encrypts the traffic before it crosses the network.

This matters because plain HTTP can expose content to systems along the network path and can allow traffic to be modified in transit. Let’s Encrypt recommends HTTPS for all websites because encryption protects privacy while integrity checks help prevent third parties from silently changing traffic between the user and server.

TLS Replaced SSL

You will still hear people say “SSL certificate,” but modern secure web connections use TLS. SSL was the older family of protocols. TLS succeeded it and continued evolving as cryptographic design, browser security, and network performance improved.

Mozilla’s MDN documentation describes TLS as the protocol applications use to communicate securely across a network and notes that modern browsers expect servers to present valid digital certificates when establishing secure connections.

What a TLS Certificate Actually Does

A TLS certificate is a digitally signed document that binds a public key to an identity such as a domain name. When your browser connects to a website, the certificate helps the browser verify that the public key it received belongs to the site it intended to reach.

This is where certificate authorities become important. A browser or operating system carries a trust store containing root certificates for recognized CAs. A website certificate can be trusted when the browser can build a valid chain from that certificate through intermediate certificates to a trusted root and when the certificate is valid for the hostname and time period involved.

That trust system is why changes to the public CA ecosystem matter. BitcoinVersus.Tech recently covered Cloudflare’s work on a public certificate authority and post-quantum certificate designs, which targets the same web-of-trust infrastructure that browsers depend on today.

The Browser Still Needs DNS First

Before a browser can establish TLS with a website, it generally needs an IP address for the hostname. That makes DNS resolution one of the first steps in the chain.

The broader sequence is covered in BitcoinVersus.Tech’s explainer on what happens when you type a website into a browser: resolve the name, establish network connectivity, negotiate the secure session, send the web request, receive content, and render the page.

Then TCP Usually Establishes the Transport Connection

Traditional HTTPS commonly runs over TCP, usually using destination port 443. TCP provides an ordered, reliable byte stream underneath TLS. The TCP transport layer handles sequence numbers, acknowledgments, retransmission, and delivery ordering while TLS handles cryptographic security above it.

Routers, NAT/PAT devices, firewalls, and switches still forward the encrypted packets normally. They may be able to observe metadata such as source and destination addresses, timing, and traffic volume, but properly encrypted application data is not readable simply because a device forwards the packets.

What Happens During the TLS Handshake?

The TLS handshake is the setup phase in which the client and server agree on cryptographic parameters, authenticate the server, and establish shared secret material that can be used to protect the rest of the session.

In simplified form, the client announces supported protocol options, the server selects compatible parameters and presents its certificate, the client validates that certificate, both sides derive session keys, and the handshake is cryptographically confirmed. After that setup, bulk application traffic is protected with efficient symmetric encryption.

Public-Key Cryptography Does Not Encrypt Every Web Packet

A common misunderstanding is that the server’s public/private key pair directly encrypts every byte transferred during the session. Modern TLS instead uses asymmetric cryptography mainly for authentication and key establishment, then uses symmetric session keys for high-speed data protection.

That division makes practical sense. Public-key operations are powerful for establishing identity and secrets between systems that have never communicated before, while symmetric cryptography is far more efficient for protecting large streams of application traffic.

TLS Protects Three Big Things

Confidentiality means an observer should not be able to read protected application data. Integrity means tampering should be detectable. Authentication means the client can verify that it is communicating with the holder of the private key associated with the certificate for the intended hostname.

Those protections work together. Encryption without authentication could still leave a user talking securely to the wrong machine. Authentication without integrity would not stop undetected modification. TLS combines the pieces into one secure channel.

What the Padlock Does Not Mean

A valid HTTPS connection does not prove that a website is honest, safe, or free of malware. It means the browser established a cryptographically protected connection to a site presenting a certificate valid for that identity under the browser’s trust rules.

A phishing site can obtain its own valid certificate. TLS can securely connect you to a malicious site just as effectively as it can connect you to a legitimate one. Users still need to inspect the domain, application behavior, and security warnings.

Why Certificate Errors Matter

Browsers warn when certificates are expired, issued for the wrong hostname, signed by an untrusted authority, revoked under supported checking mechanisms, or otherwise invalid. Those errors matter because the browser can no longer establish the expected chain of trust.

Ignoring certificate warnings can defeat the authentication layer that makes HTTPS useful. In enterprise environments, administrators sometimes deploy their own trusted certificates for inspection or internal services, but those systems must be managed deliberately because adding a trusted root changes what the endpoint is willing to trust.

TLS 1.3 Simplified and Hardened the Protocol

RFC 8446 defines TLS 1.3. The version removed obsolete cryptographic options, simplified negotiation, and reduced handshake overhead compared with older generations of TLS.

That matters for both security and performance. A secure protocol is easier to operate when weak legacy choices are removed, and reducing setup work can lower connection latency—an issue that connects directly to network latency and user-perceived application responsiveness.

Can Packet Capture Still See HTTPS?

Yes. A packet capture can still record encrypted HTTPS traffic. The technician can inspect packet timing, IP addresses, transport behavior, handshake metadata, retransmissions, and many protocol-level details.

What the capture normally cannot do is simply display protected application payloads in readable form without access to the appropriate session secrets or a controlled inspection architecture. Encryption changes what troubleshooting tools can see, but it does not make the network invisible.

Firewalls Still Matter With HTTPS

TLS does not replace a firewall. A firewall controls which traffic is permitted between systems or networks; TLS protects the contents and identity of a connection. Those are different jobs.

That distinction is visible in systems such as FortiGate firewalls, where specialized hardware can accelerate inspection, policy enforcement, and cryptographic workloads while endpoints and servers still participate in their own TLS sessions.

The Simple Way to Remember HTTPS

HTTPS is HTTP carried through a TLS-protected connection. DNS helps find the server, the network stack carries the packets, the certificate helps authenticate the site, the handshake establishes shared secrets, and symmetric encryption protects the application data that follows.

That is why HTTPS is one of the most important pieces of everyday Internet infrastructure. It does not make a website trustworthy by itself, but it gives browsers and servers a standard way to communicate privately, detect tampering, and authenticate secure connections at global scale.

Editor’s Note

Featured photograph: Yuri Samoilov via Wikimedia Commons/Flickr, licensed CC BY 2.0; cropped to 1200×630. The image is used as a visual metaphor for secure computing and does not depict the TLS protocol itself.

Support and donation options are available through BitcoinVersus.Tech.

BitcoinVersus.tech is not a financial advisor. Content is provided for informational purposes.