Port 443: HTTPS — The Lock on Every Door

What Port 443 Does

Port 443 carries HTTPS traffic. Every time you see the lock icon in your browser, that is port 443. Every login form, every online purchase, every bank balance check, every medical record viewed through a web portal, every private message sent through a web app. All of it flows through this port, wrapped in encryption that makes it unreadable to anyone except the intended recipient.

HTTPS is HTTP (the protocol that powers the web) layered on top of TLS (Transport Layer Security). HTTP carries the content. TLS provides the envelope. Port 443 is where that sealed envelope arrives.

Today, 97% of web pages loaded in Chrome use HTTPS¹. Port 443 is not a special case. It is the default state of the web.

How TLS Works: The Handshake

The key insight of TLS is a piece of mathematical choreography called the handshake. Two machines that have never met need to agree on a shared secret, in public, without anyone listening being able to figure out what that secret is. This sounds impossible. It is not.

Here is what happens when your browser connects to a server on port 443:

Step 1: Client Hello. Your browser reaches out and says: here is my name, here are the encryption methods I support, and here is a random number I just generated.

Step 2: Server Hello. The server responds: I choose this encryption method, here is my certificate proving who I am, here is my own random number, and here are the parameters for key exchange.

Step 3: Key Exchange. Using Diffie-Hellman key exchange, both sides independently compute the same shared secret without ever transmitting it. An eavesdropper who captured every byte of this conversation still cannot derive the key. This is the mathematical miracle at the heart of every HTTPS connection.

Step 4: Encrypted Communication. Both sides now share a symmetric session key. Everything that follows is encrypted. Fast, private, and verified.

In TLS 1.3 (the current standard), this entire handshake completes in a single round trip². One message out, one message back, and the channel is secure. For returning visitors, TLS 1.3 supports 0-RTT resumption, where the client sends encrypted data immediately, no round trip required. The handshake that took two full round trips in TLS 1.2 was cut in half, then cut to zero.

Every page load on the modern web begins with this invisible ceremony. It takes milliseconds. It happens billions of times per day. And it works.

The History

The Problem

In 1994, the web was a glass house. HTTP sent everything in plaintext. Every password, every form submission, every page request was readable by anyone with access to the network path between browser and server. There was no privacy. There was no authentication. You could not verify that the server you were talking to was who it claimed to be.

This was not an academic concern. The web was about to become commercial. Marc Andreessen and Jim Clark had founded Netscape Communications, and they understood something clearly: if people could not safely enter a credit card number into a browser, there would be no e-commerce. No online banking. No digital economy. The web would remain a curiosity for academics, not a platform for civilization.

The Engineers

Netscape's chief scientist was Taher Elgamal, an Egyptian cryptographer who has been called "the father of SSL."³ Working under his direction, engineer Kipp Hickman designed the first version of the Secure Sockets Layer (SSL) protocol. SSL 1.0 was completed in 1994 but never released publicly because it contained serious cryptographic flaws⁴.

In February 1995, SSL 2.0 shipped inside Netscape Navigator 1.1, the first browser to support encrypted connections⁵. It worked. For the first time, a person could type a credit card number into a web page and know that only the intended server could read it.

Kipp Hickman registered port 443 with IANA for HTTPS around 1994⁶. He gave the encrypted web its address.

SSL 2.0 to SSL 3.0

SSL 2.0 was a breakthrough, but it was also flawed. It used the same keys for authentication and encryption. Its MAC construction was vulnerable to length extension attacks. It had no protection for the handshake itself. These were not theoretical weaknesses. They were exploitable.

In 1996, Paul Kocher, working with Netscape engineers Phil Karlton and Alan Freier, redesigned the protocol from scratch as SSL 3.0⁷. This was not a patch. It was a complete rewrite. SSL 3.0 became the foundation that the modern web's security is built on.

SSL Becomes TLS

In 1996, the IETF took over stewardship of the protocol. Tim Dierks later admitted the renaming from "SSL" to "TLS" was partly diplomatic: "so it wouldn't look like the IETF was just rubberstamping Netscape's protocol."⁸

TLS 1.0 was published as RFC 2246 in January 1999⁹. The differences from SSL 3.0 were not dramatic, but they were significant enough to prevent interoperability between the two. Christopher Allen and Tim Dierks of Certicom authored the specification.

Eric Rescorla's Arc

In May 2000, Eric Rescorla of RTFM, Inc. published RFC 2818, "HTTP Over TLS," which documented the practice of running HTTP over TLS on port 443¹⁰. This was the formal definition of what HTTPS means.

Eighteen years later, in August 2018, the same Eric Rescorla, now CTO of Firefox at Mozilla, published RFC 8446, which defined TLS 1.3¹¹. The protocol was faster (one round trip instead of two), more secure (all legacy cipher suites removed), and more elegant (mandatory forward secrecy).

Between those two RFCs, Rescorla also co-founded Let's Encrypt¹², the nonprofit certificate authority that made TLS certificates free and automated for the entire web. One person wrote the specification that defined HTTPS, rewrote the protocol that secures it, and co-created the system that makes it free. His career is the story of port 443.

Let's Encrypt and the Encryption of Everything

Before 2015, deploying HTTPS required purchasing a certificate from a certificate authority. The average price for a single-domain certificate was $178 per year¹³. The cost was a barrier, but the complexity was worse. Installing certificates required technical knowledge that most website operators did not have.

Let's Encrypt launched its public beta on December 3, 2015. It was founded by Josh Aas and Eric Rescorla (Mozilla), Peter Eckersley (EFF), and J. Alex Halderman (University of Michigan), with backing from Mozilla, the Electronic Frontier Foundation, Cisco, Akamai, and IdenTrust¹⁴.

The idea was simple: make certificates free, automated, and open. The impact was not simple at all. In 2013, 27% of web pages loaded in Firefox used HTTPS. Today, it is over 97%¹⁵. Let's Encrypt now serves over 700 million websites and holds 63.4% of the certificate market¹⁶. It issues around three million certificates per day.

The EFF also created HTTPS Everywhere, a browser extension that automatically redirected HTTP connections to HTTPS where available. It was retired in January 2023 because it was no longer needed. All major browsers now offer HTTPS-only mode by default¹⁷. The extension succeeded so completely that it made itself obsolete.

Security: The Scars

Port 443 has been attacked relentlessly since its creation. Every vulnerability discovered in SSL/TLS is, in effect, an attack on port 443. The protocol has the scars to prove it.

Heartbleed (2014). A bug in OpenSSL's implementation of the TLS heartbeat extension allowed any attacker on the Internet to read the memory of servers running vulnerable versions. Private keys, passwords, user data, all exposed. The bug had been in the wild since March 2012. It was not a flaw in the TLS protocol itself but in OpenSSL's implementation, which made it both more surprising and more devastating¹⁸. After Heartbleed, Google forked OpenSSL to create BoringSSL, and OpenBSD created LibreSSL.

POODLE (2014). The Padding Oracle On Downgraded Legacy Encryption attack allowed a man-in-the-middle attacker to downgrade a TLS connection to SSL 3.0 and exploit a padding oracle vulnerability in CBC mode¹⁹. This attack led directly to the deprecation of SSL 3.0 in RFC 7568 (June 2015).

BEAST (2011). The Browser Exploit Against SSL/TLS targeted a flaw in CBC mode in TLS 1.0 that had been known since 2002 but not fixed in practice until TLS 1.1²⁰. The fix existed. The adoption did not.

CRIME (2012) and BREACH (2013). These attacks exploited TLS compression and HTTP compression respectively to leak information about encrypted traffic through the size of compressed responses²¹.

FREAK and Logjam (2015). Both attacks exploited export-grade cryptography, weak 512-bit keys that were required by U.S. government export regulations in the 1990s. Decades later, the ghost of that policy was still haunting production servers²².

Each of these attacks drove the industry toward TLS 1.3, which removed every vulnerable component: no more CBC mode, no more RSA key exchange, no more export ciphers, no more compression. TLS 1.3 is not just an improvement. It is the scar tissue of every attack that came before it.

The Protocol Versions

TLS 1.3 now powers approximately 76% of all web traffic. TLS 1.2 accounts for another 13-15%. Everything older is effectively dead²³.

Related Ports