Why HTTPS Is Moving from RSA to ECC: Understanding Modern TLS

Every time you visit a website whose address starts with https, a tiny cryptographic handshake just happened in the background. Your browser and the website proved they were who they claimed to be, agreed on a secret code, and started talking privately — all in a fraction of a second.

For decades, the math behind that handshake was almost always the same: an algorithm called RSA. But over the last few years, a quieter, faster, more elegant approach has been taking over. It's called ECC — Elliptic Curve Cryptography — and if you run a website, manage servers, or are just curious about how the web stays secure, it's worth understanding.

This article is a beginner's guide on what ECC certificates are, why they're beating RSA, the TLS handshake, and what happens when quantum computers eventually enter the picture.

First, what's a certificate anyway?

An SSL/TLS certificate is basically a digital ID card for a website. It does two jobs:

Proves identity. It tells your browser, "Yes, this really is yourbank.com, verified by a trusted Certificate Authority" — not an impostor sitting in the middle.
Carries the server's public key. In older TLS connections, this public key was also used to encrypt the session secret. In modern TLS, its primary role is to prove the server's identity, while a separate mechanism establishes the encrypted session.

Every certificate is built on a pair of mathematical keys: a public key everyone can see, and a private key the server guards closely.

The security of the whole system rests on one idea — it should be easy to do the math in one direction (locking) but practically impossible to reverse it (unlocking) without the private key.

The interesting question is: what math do you use to make that one-way street? That's where RSA and ECC differ.

What ECC actually is (no scary equations, I promise)

RSA's security comes from the difficulty of factoring enormous numbers. If I multiply two huge prime numbers together, handing you the result and asking you to find the original primes is extremely hard. That's the mathematical puzzle RSA relies on.

ECC relies on a completely different puzzle called the elliptic curve discrete logarithm problem. Instead of giant numbers and factorization, it uses special mathematical structures known as elliptic curves.

RSA and ECC are solving two entirely different problems.

RSA's puzzle: "Can you figure out which two giant primes I multiplied?"
ECC's puzzle: "Can you solve this extremely difficult elliptic curve problem?"

The important takeaway isn't the mathematics — it's the efficiency. The elliptic curve problem provides much more security for each bit of key size, allowing ECC to achieve security comparable to RSA while using dramatically smaller keys.

A simple analogy

Imagine protecting a treasure.

RSA — Uses a 2-ton steel door. Very secure, but heavy and slow to open.

ECC — Uses a lightweight futuristic door. Much lighter, but just as difficult to break into.

Both protect the treasure, but ECC does it more efficiently.

ECC is the umbrella term for the whole approach. When ECC is used to sign a certificate and prove identity, the specific algorithm is called ECDSA (Elliptic Curve Digital Signature Algorithm). When it's used to agree on a session key, it's called **ECDHE (**Elliptic Curve Diffie-Hellman Ephemeral).

Why do smaller keys matter?

The surprising part is that smaller doesn't mean weaker. For roughly the same level of security, RSA needs keys that are thousands of bits long, while ECC can achieve it with just a few hundred bits. Smaller keys mean smaller certificates, faster TLS handshakes, and less CPU work for both servers and browsers — especially valuable on high-traffic services and mobile devices.

The Handshake: What actually happens during an HTTPS connection?

Every time you open an HTTPS website, your browser and the server have a very short conversation called the TLS handshake. Its job is to answer two questions:

Is this really the website I intended to visit?
How can we create a secret key that only the two of us know?

The certificate answers the first question by proving the server's identity. The second is handled by the key exchange mechanism — and this is where the difference between traditional RSA and modern ECDHE becomes important.

Now let's see how those two approaches differ.

A quick but important distinction: an ECC certificate doesn't automatically mean the connection uses ECC for everything. In modern TLS, the certificate usually uses ECDSA to prove the server's identity, while ECDHE is the separate mechanism that creates the shared session key. They're related, but they do different jobs.

Traditional RSA: the browser delivers the secret

In the classic RSA model, the browser is responsible for creating the session key. Let's take an example where a browser is communicating with a bank. The important idea here is simple: The browser creates the secret, encrypts it with the server's public key, and the server decrypts it with its private key.

The browser generates the session secret and sends it encrypted with the server's public key. Anyone intercepting the traffic sees only ciphertext.

Modern ECDHE: nobody sends the secret

This is where ECC becomes much more interesting. Instead of the browser creating and sending the session key, each side generates a temporary private value, exchanges only the corresponding public key value, and independently arrives at the exact same shared secret. The shared secret is never transmitted — only the public key values are — this is the magical part of ECDHE.

But wait… how do they both end up with the same secret 🤔?

Here is the step-by-step process of how they do it.

1. The Setup (Choosing the Curve)

Both the browser and the bank agree on the math rules.
They choose a specific Elliptic Curve (like X25519 or P-256) and a standard starting point on that curve, known as the Generator Point (G).

2. Key Generation

Both the browser and the bank generate their own temporary (ephemeral) keypairs:

The Browser picks a random secret number a (Browser Private Key) and calculates A = a × G (Browser Public Key).
The Bank picks a random secret number b (Server Private Key) and calculates B = b × G (Server Public Key).

3. The Public Exchange

The browser sends its ephemeral public key (A) to the bank.
The bank sends its ephemeral public key (B) to the browser.

Here anyone listening on the network can see A and B, but they cannot figure out the private secrets a or b.

4. The Secret Calculation

This is where the standard mathematical property of ECC comes into play. Because of the mathematical properties of elliptic curve scalar multiplication, both sides can independently calculate the exact same point on the curve:

The Browser takes the Server's Public Key (B) and multiplies it by its own Private Key (a)
The Server takes the Browser's Public Key (A) and multiplies it by its own Private Key (b):

Both calculations result in the exact same point on the curve (x, y) which is then used to derive the symmetric session key.

a×B=b×A=(x,y)

5. Creating the Session Key

The shared (x, y) point is not used directly as the encryption key.
Both the browser and server extract the x-coordinate from that shared point.
They independently pass that value through a Key Derivation Function (HKDF), which uses a cryptographic hash such as SHA-256.
The output is the final symmetric session key, which is used by encryption algorithms like AES-GCM or ChaCha20-Poly1305 to protect the rest of the HTTPS connection.

What if my browser supports RSA, but the bank uses an ECC certificate?

The good news is yes, they can still communicate.

Browsers don't carry RSA or ECC certificates — they support cryptographic algorithms. During the TLS handshake, the browser tells the server which signature and key exchange algorithms it understands. If it supports ECDSA and ECDHE, it can verify the bank's ECC certificate and complete the connection normally.

The connection only fails if the browser is so old that it doesn't support ECC at all. That's now extremely rare, which is why most modern websites can safely deploy ECC certificates.

Will quantum computers break HTTPS?

Everything we've discussed so far — RSA, ECDSA, and ECDHE — depends on mathematical problems that are considered infeasible for today's computers. Quantum computers change that assumption.

A sufficiently powerful quantum computer running Shor's algorithm could solve both of these hard problems efficiently:

RSA: Integer factorization
ECC: Elliptic curve discrete logarithms

That means both RSA and ECC would eventually become vulnerable. ECC isn't "quantum-safe" — it's simply more efficient than RSA on classical computers.

Does that mean HTTPS is doomed?

Fortunately, no.

The cryptography community has been preparing for this for years through Post-Quantum Cryptography (PQC). Rather than replacing HTTPS overnight, modern TLS is gradually adopting hybrid key exchanges that combine ECC with a quantum-resistant algorithm.

Instead of relying on one mathematical puzzle, the browser and server derive the session key from both mechanisms. An attacker would need to break both ECC and the post-quantum algorithm to recover the secret, making the transition much safer.

The bottom line: ECC is the present, not the future. It's the most efficient and widely deployed public-key cryptography for today's web, while post-quantum algorithms are being introduced alongside it — not as an overnight replacement.

The remarkable thing about HTTPS isn't that it became more complicated — it's that it became more elegant. Modern TLS quietly replaced heavier cryptography with smaller keys, faster handshakes, and stronger forward secrecy, all without changing the little padlock we click every day. The next evolution won't replace that experience either; it'll simply make it resilient against the quantum era.

Contents