109 Digital Life Security #13: HTTPS and TLS — What Really Happens When the Padlock Appears

Digital Life Security Series ...Practical ways to protect your devices, accounts, privacy, information and home

You type a website address into your browser.

DNS helps determine where the website can be reached.

Your computer sends network traffic through switches, routers, and firewalls.

Eventually it reaches the web server.

Then something extremely important happens before sensitive web communication begins.

Your browser and the server establish a secure connection.

We see:

https://

Perhaps the browser displays a security indicator near the address.

And we continue browsing.

But what actually happened?

How did your browser decide it was talking to the correct server?

How did two computers that had never communicated before create an encrypted connection?

And how did they do all of that in a fraction of a second?

Welcome to TLS.

HTTPS Is HTTP Protected by TLS

We have already encountered HTTP.

HTTP stands for Hypertext Transfer Protocol.

It is one of the fundamental protocols used for communication between web browsers and web servers.

Traditional HTTP by itself does not provide the encryption we expect from modern secure web browsing.

HTTPS means HTTP communication is being protected using TLS.

TLS stands for:

Transport Layer Security.

So a simplified way to think about HTTPS is:

HTTP + TLS protection = HTTPS

What Happened to SSL?

You may remember the term SSL.

SSL stands for Secure Sockets Layer.

SSL was an earlier technology used to protect Internet communication.

TLS evolved from that work and replaced SSL.

People still sometimes casually say “SSL certificate,” but modern secure web connections use TLS.

The older SSL protocols are obsolete.

What Is TLS Trying to Accomplish?

TLS helps provide several important security properties.

Confidentiality

Someone observing the network should not simply be able to read the protected communication.

Integrity

The communication should not be silently altered without detection.

Authentication

The browser needs a way to determine whether the server can authenticate itself for the hostname being requested.

There are our security concepts again.

Encryption Is Not Enough

Imagine creating a beautifully encrypted connection.

Everything traveling through it is unreadable to outsiders.

Wonderful.

But what if you created that encrypted connection with an attacker?

Your information would be securely encrypted all the way to the wrong person.

This is why authentication matters.

We need both:

Can outsiders read this conversation?

and:

Who am I having this conversation with?

Enter the Digital Certificate

When a web server establishes a normal public HTTPS connection, it presents a digital certificate.

The certificate contains information that helps the browser authenticate the server's identity for the requested hostname.

Among other things, certificates can include:

• The domain names for which the certificate is valid
• A public key or information associated with one
• The certificate's validity period
• The issuing Certificate Authority
• Cryptographic signatures
• Other technical information

The browser examines this information before deciding whether to trust the connection.

Public Keys and Private Keys

Now we encounter one of the most important ideas in modern cryptography.

A cryptographic system can use a pair of related keys:

Public key

and:

Private key

The public key can be distributed.

The private key must remain protected.

Mathematical relationships between the keys allow cryptographic operations that would not be possible if everything depended upon one shared secret.

This is called asymmetric cryptography or public-key cryptography.

We Have Already Seen Public-Key Cryptography

This idea should sound familiar.

DKIM uses public-key cryptography to help authenticate email.

Passkeys use public/private key pairs for authentication.

TLS uses public-key cryptography as part of establishing and authenticating secure connections.

The same fundamental mathematical idea appears throughout modern cybersecurity.

The Private Key Is Extremely Important

A web server's private key should remain secret.

The certificate can be public.

The public key can be public.

But the private key must be protected.

If an attacker obtains sensitive private-key material, the security assumptions around that identity may be undermined, depending on the circumstances.

This gives us another recurring security principle:

Some information is designed to be shared.

Some information must remain secret.

Good cryptographic systems are very deliberate about the difference.

But Who Says the Certificate Is Legitimate?

Suppose anyone could create a certificate saying:

I am example.com.

That would not prove very much.

Anyone could make the claim.

We therefore need a trust system.

This brings us to Certificate Authorities.

Certificate Authorities

A Certificate Authority, or CA, is an organization that issues and signs digital certificates after performing the validation required for that certificate.

Your browser and operating system contain or use a collection of trusted root certificates.

These establish trust anchors.

The website certificate can then be linked through cryptographic signatures to trusted certificate infrastructure.

This creates what is called a certificate chain.

The Certificate Chain

A simplified certificate chain might look like:

Website Certificate
↓
Intermediate Certificate Authority
↓
Trusted Root Certificate Authority

Your browser does not simply ask:

Does this website have a certificate?

It asks whether that certificate can be validated through an acceptable chain of trust and whether other certificate requirements are satisfied.

Why Intermediate Certificates?

Root CA keys are extremely valuable.

Rather than using a root key directly for every certificate issuance, certificate systems commonly use intermediate Certificate Authorities.

The root signs or authorizes an intermediate certificate.

The intermediate can then issue certificates beneath it.

This creates layers in the trust structure and helps protect the most sensitive root infrastructure.

What Does the Browser Check?

When validating a website certificate, the browser performs several checks.

The exact process is complex, but conceptually it asks questions such as:

• Is the certificate valid for the hostname I requested?
• Is the certificate within its validity period?
• Can its signatures be validated?
• Does it chain to a trusted root?
• Does the certificate meet applicable security requirements?
• Has certificate status information indicated a problem?

If important checks fail, the browser may refuse the connection or display a strong warning.

The Hostname Matters

Suppose you request:

www.example.com

The server presents a perfectly valid certificate for:

www.something-else.com

The certificate may be legitimate.

But it is not legitimate for the site you requested.

The browser should detect that mismatch.

This is why certificate validation is tied to the hostname.

Certificates Expire

Certificates have validity periods.

They are not intended to remain valid forever.

Expiration creates an opportunity to periodically replace certificates and cryptographic material and limits how long a particular certificate remains usable.

Website administrators therefore need reliable certificate-renewal processes.

Modern automation has made certificate renewal much easier than it once was.

Certificates Can Also Be Revoked

Sometimes a certificate should no longer be trusted before its normal expiration date.

Perhaps a private key is suspected of being compromised.

Perhaps the certificate was issued incorrectly.

Certificate ecosystems provide mechanisms for communicating revocation or certificate-status information.

Real-world browser handling of certificate status is complex, but the basic principle is simple:

Trust may need to be withdrawn before expiration.

Now the Browser Trusts the Server — How Do They Encrypt Everything?

This is where the story becomes especially interesting.

You might assume that public-key cryptography encrypts every image, paragraph, cookie, form submission, and video traveling between the browser and server.

That is not generally how modern TLS works.

Public-key cryptography is extremely useful.

But symmetric cryptography is much more efficient for encrypting large amounts of data.

Symmetric Encryption

With symmetric encryption, the same secret key, or closely related shared secret material, is used for encrypting and decrypting protected communication.

Symmetric algorithms are extremely fast.

That makes them well suited for protecting the actual data flowing through an HTTPS session.

But there is an obvious problem.

How do two computers that have never met agree on secret key material without simply sending the secret across the network?

That is one of the problems solved during the TLS handshake.

The TLS Handshake

Before normal encrypted application communication begins, the browser and server perform a process called the TLS handshake.

The details depend on the TLS version and cryptographic algorithms being used.

But conceptually, the handshake allows the two systems to:

• Agree on cryptographic parameters
• Authenticate the server
• Establish shared secret material
• Derive keys for protecting the session
• Verify that the handshake has not been improperly altered

Once that process succeeds, encrypted application communication can begin.

A Simplified TLS Conversation

Imagine the browser saying:

Browser: Hello. Here are the TLS capabilities I support.

Server: Hello. Here is what we will use, and here is my certificate.

Browser: Let me validate that certificate.

The browser checks the hostname, certificate chain, signatures, validity, and other requirements.

Then the browser and server perform cryptographic operations that allow them to establish shared secret material.

From that material they derive session keys.

Then both sides confirm that the handshake succeeded.

Now the protected conversation begins.

Modern TLS Uses Ephemeral Key Exchange

Modern TLS commonly uses an ephemeral key-exchange mechanism.

The word ephemeral means temporary.

Fresh key-exchange values can be created for individual connections.

This provides an extremely valuable security property.

Forward Secrecy

Suppose an attacker records encrypted network traffic today.

Years later, the attacker somehow obtains a server's long-term private key.

Would that automatically allow the attacker to decrypt all the old recorded sessions?

With appropriately configured modern ephemeral key exchange, the answer is generally no.

The long-term private key authenticates the server, but the temporary session secrets are not simply recoverable from that key.

This property is known as forward secrecy.

Compromise of a long-term key should not automatically compromise previously completed sessions.

This Is a Beautiful Example of Defense in Depth

Cryptographic design asks:

What happens if something fails later?

Instead of allowing one future key compromise to unlock years of previously captured traffic, ephemeral key exchange helps isolate sessions from one another.

Again:

Contain the failure.

That is the same security philosophy we used when discussing VLANs and network segmentation.

Asymmetric and Symmetric Cryptography Work Together

We can now make an important distinction.

Asymmetric cryptography helps with authentication and secure key establishment.

Symmetric cryptography efficiently protects the bulk data flowing through the session.

They are not competing technologies.

They work together.

One helps establish trust and shared secrets.

The other efficiently protects the ongoing conversation.

What About Hashing?

Hashing appears in cryptographic systems too.

Remember:

Encryption is designed so protected information can be recovered with the appropriate key.

Hashing produces a fixed-size output from input data and is designed for different purposes rather than normal reversible recovery.

Cryptographic hash functions are useful for detecting changes and are important building blocks in digital signatures and many security protocols.

We will give encryption, hashing, and digital signatures their own full topic because understanding the differences unlocks much of modern cybersecurity.

What Is a Digital Signature?

A digital signature uses public-key cryptography to provide evidence that data was signed using the corresponding private key and that the signed data has not been improperly altered.

Certificate Authorities digitally sign certificates.

Browsers verify those signatures.

This is part of how the certificate chain works.

Again we see the same cryptographic concept appearing in multiple places.

Encryption Does Not Mean the Website Is Honest

This is one of the most important lessons in the entire series.

A malicious website can use HTTPS.

A phishing website can have a valid TLS certificate.

A scammer can register a domain and correctly configure HTTPS.

The certificate may accurately prove:

You have an encrypted connection to this domain.

It does not necessarily prove:

The person operating this domain is honest.

The Padlock Was Easy to Misunderstand

Browsers historically emphasized padlock icons for HTTPS connections.

Many users interpreted the padlock as:

This website is safe.

That interpretation was too broad.

HTTPS tells us important things about the connection and server authentication for the requested hostname.

It does not evaluate the honesty of every statement on the website.

This is one reason modern browsers have changed how they visually communicate connection security.

Authentication Is Not Reputation

This deserves its own rule:

Authentication is not reputation.

A certificate can authenticate a domain.

DKIM can authenticate that an email was signed by a particular domain's key.

A password can authenticate access to an account.

None of those facts automatically tell us whether the authenticated party has good intentions.

Security requires us to ask the right question of each technology.

What Can Someone on the Network See?

With properly functioning HTTPS, an observer on the network should not simply be able to read the protected contents of your web session.

They should not be able to casually read:

• The password you submit inside the encrypted session
• The private message you send through the site
• The page contents returned inside the protected connection
• The protected application data exchanged within the TLS session

But HTTPS does not make all network metadata disappear.

Other information about network communication may still be observable depending on the protocols and technologies being used.

Again:

Encrypted does not mean invisible.

TLS and Public Wi-Fi

This is why HTTPS dramatically improved the safety of using the web over untrusted networks.

Years ago, much more web traffic traveled without transport encryption.

Someone positioned appropriately on the network could potentially observe sensitive application data far more easily.

Today, widespread HTTPS provides an important encrypted layer even when the underlying network itself is not trusted.

But we still should not ignore certificate warnings, fake Wi-Fi networks, phishing pages, malicious downloads, or other threats.

TLS solves particular problems.

It does not solve every problem.

What Happens If Someone Tries to Intercept the Connection?

Imagine an attacker positioned between you and the destination server.

This type of scenario is commonly called a man-in-the-middle or machine-in-the-middle attack.

The attacker wants your browser to communicate with the attacker while believing it is communicating securely with the real website.

TLS certificate validation makes this much harder.

The attacker needs to satisfy the browser's authentication requirements for the hostname being requested.

Simply intercepting the packets is not enough.

What If the Attacker Creates Their Own Certificate?

Anyone can create cryptographic keys and create a certificate-like structure.

But your browser will not automatically trust it.

The certificate needs to validate through a trust path the browser accepts, or otherwise be explicitly trusted in that environment.

This is why the trusted root store matters.

The browser is not asking whether the attacker can create a certificate.

It is asking whether the presented certificate satisfies the trust model.

Trust Stores Are Powerful

Operating systems and browsers maintain collections of trusted Certificate Authorities.

Adding a new trusted root certificate is therefore a powerful action.

A trusted root can influence what certificates the system accepts.

This is sometimes necessary in managed organizational environments.

But installing an unknown or untrusted root certificate casually can have serious security consequences.

Changing the trust store changes whom the computer is willing to trust.

TLS Inspection

Some organizations intentionally inspect encrypted traffic for security or policy reasons.

To do this, managed devices may be configured to trust an organizational certificate authority.

The security system can then establish separate protected connections and inspect traffic according to organizational policy.

This demonstrates an important concept:

Encryption protects communication between particular endpoints.

If a trusted system is intentionally inserted into that trust relationship, the architecture changes.

Again ask:

Encrypted between whom?

Your Server Has a TLS Configuration

Website administrators have another side of this story.

The server must be configured to support appropriate TLS protocols and cryptographic options.

Server administrators should consider:

• Supported TLS versions
• Certificate configuration
• Private-key protection
• Certificate renewal
• Intermediate certificates
• Secure cryptographic settings
• HTTP-to-HTTPS redirection
• Security headers
• Monitoring for certificate problems

HTTPS is not merely something the browser does.

It requires correct configuration on both sides of the connection.

Why Disable Old Protocols?

Security protocols evolve.

Weaknesses are discovered.

Cryptographic algorithms age.

Better designs replace older ones.

A server that supports obsolete protocols merely for compatibility may preserve attack surface that is no longer necessary.

This is another example of minimizing what we expose.

Support what is needed.

Retire what is obsolete.

HTTP Strict Transport Security

There is another useful web-security technology called HTTP Strict Transport Security, or HSTS.

HSTS allows a website to tell supporting browsers that the site should be accessed using HTTPS rather than falling back to ordinary HTTP.

This helps reduce opportunities for certain downgrade or redirection attacks involving insecure HTTP connections.

Again we are adding another layer.

From DNS to TLS

Let's connect our last two topics.

You type:

www.example.com

DNS asks:

Where can this name be reached?

Your computer establishes network communication with the destination.

TLS asks:

Can this server authenticate itself appropriately for the hostname I requested?

Can we establish protected session keys?

Can we protect the confidentiality and integrity of this conversation?

Then:

HTTP asks:

What web resource do you want, and what response should be returned?

Different layers.

Different questions.

Let's Follow the Entire Connection

You enter a website address.

1. DNS resolves the name.

2. Your device determines whether the destination is local or must go through its gateway.

3. Ethernet or Wi-Fi carries the local traffic.

4. Switches forward local frames.

5. Routers move packets between networks.

6. Firewalls apply communication policy.

7. The browser and server begin a TLS handshake.

8. The server presents its certificate.

9. The browser validates the certificate and trust chain.

10. Cryptographic key establishment creates shared session secrets.

11. Symmetric encryption protects the session.

12. HTTP requests and responses travel through the protected connection.

13. The browser processes and displays the website.

What looked like:

Click the website.

is actually an extraordinary chain of technologies cooperating in milliseconds.

And Every Layer Has a Security Job

DNS helps locate the destination.

Routing moves the traffic.

Firewalls enforce network policy.

Certificates help authenticate the server.

Public-key cryptography helps establish trust and secure key material.

Symmetric cryptography protects the ongoing communication efficiently.

Cryptographic integrity mechanisms detect improper modification.

The browser enforces web-security rules.

The application still has to securely authenticate the user and protect the account.

Security is not one technology.

Security is the cooperation of many layers.

Look at a Certificate Yourself

Here is our practical exercise.

Open a website you trust.

Use your browser's site-information or certificate-viewing tools.

Look for:

• The hostname or domain names
• The certificate issuer
• The validity dates
• The certificate chain
• The public-key information
• The signature information

You do not need to understand every field yet.

The goal is simply to recognize that the browser is not displaying a vague “secure” symbol.

There is an actual cryptographic identity system underneath it.

Then Ask the Right Question

Instead of asking:

Does this website have a padlock?

ask:

Is my connection encrypted?

Has the server authenticated itself for the hostname I requested?

Am I actually on the domain I intended to visit?

Do I have a reason to trust the organization or person operating that domain?

Those are different questions.

Good security thinking keeps them separate.

We Are Beginning to See the Cryptographic Foundation

Throughout this course we have encountered:

Password hashing.

DKIM signatures.

Passkeys.

DNSSEC.

TLS certificates.

Public keys.

Private keys.

Symmetric encryption.

Digital signatures.

Session keys.

These are not unrelated tricks.

They are applications of a relatively small collection of powerful cryptographic ideas.

And that means we are finally ready to pull those ideas apart and examine them directly.

Encryption.

Hashing.

Digital signatures.

They sound similar.

They are often discussed together.

But they solve very different problems.

Understanding those differences is one of the keys to understanding modern cybersecurity.