HTTPS and Encryption in Transit: What the Browser Lock Protects

When a browser uses HTTPS, someone sharing the same Wi-Fi should not be able to read a submitted password simply by capturing packets. The browser can also detect if traffic is altered in transit and verify that the server presents credentials for the requested name.

HTTPS is HTTP carried through TLS, which provides encryption, integrity protection, and server authentication for the connection.

It secures the route to a domain. It does not prove that the people operating the site are honest.

The threats HTTPS addresses

Without TLS, an intermediary could:

• Read requests and responses
• Capture passwords or cookies
• Modify downloads
• Inject advertisements or malware
• Redirect links
• Impersonate the expected server

Intermediaries include:

• Wi-Fi operator
• Compromised router
• Internet provider
• Malicious network device

HTTPS protects application data after the TLS connection is established between endpoints.

The TLS handshake

Before ordinary HTTP messages, client and server perform a handshake.

A simplified TLS 1.3 flow:

1. Client offers supported versions, cryptographic options, and key material.
2. Server selects options and sends its certificate chain and key material.
3. Client validates the certificate for the requested hostname.
4. Both derive shared session keys.
5. Handshake messages are verified.
6. Encrypted application data begins.

Modern key exchange creates shared secrets without sending the final symmetric encryption key directly over the network.

Why two kinds of cryptography appear

Public-key cryptography helps authenticate and establish shared secrets.

Symmetric cryptography then protects bulk traffic because it is much faster.

The handshake answers:

• Is this server authorized for the hostname?
• Can both sides establish shared secret keys?
• Was the handshake altered?

The data phase uses those keys to encrypt and authenticate records.

Certificates

A TLS certificate binds a public key to names and other metadata.

It is signed by a certificate authority or an intermediate whose trust leads to a root certificate already trusted by the browser or operating system.

Validation checks include:

• Hostname match
• Valid time period
• Signature chain
• Permitted key use
• Revocation-related signals where supported

A certificate for example.com does not authorize example-bank.com.

A concrete public Wi-Fi example

Suppose you submit a password to a legitimate HTTPS site on public Wi-Fi.

An observer may see:

• Your device communicating with network addresses
• Timing and packet sizes
• Some connection metadata

They should not see:

• HTTP path in modern encrypted traffic
• Form password
• Response body
• Session cookie

If you ignore a certificate warning and proceed through an unsafe override, an active attacker may be impersonating the server.

Certificate warnings deserve investigation.

Encryption

TLS encryption transforms plaintext into ciphertext using session keys.

Only endpoints with the keys should recover the content.

Encryption protects confidentiality in transit, but plaintext exists:

• Inside the browser before sending
• Inside the server after receiving
• In application logs if recorded
• In databases unless separately protected

HTTPS is not end-to-end encryption through every internal service by itself. A reverse proxy may terminate TLS and forward traffic through another protected or unprotected link.

Integrity protection

TLS authenticates encrypted records.

If an attacker changes ciphertext, verification fails rather than producing silently modified HTTP.

This protects software downloads, page scripts, and data from in-path tampering.

Integrity does not protect against the legitimate server intentionally sending harmful content or being compromised.

Forward secrecy

Modern ephemeral key exchange provides forward secrecy.

If a server's long-term private certificate key is stolen later, previously recorded sessions should not become decryptable merely from that key.

Each connection derives temporary secrets that are not recoverable from the certificate key alone.

This limits the impact of future key compromise.

TLS termination and proxies

Large services commonly terminate TLS at:

• Load balancer
• Reverse proxy
• Content-delivery network

That endpoint presents the certificate and decrypts traffic.

It then sends requests to backend services, often using another TLS connection.

The user's encrypted connection ends at the terminating service. Trust includes that infrastructure and its operators.

Enterprise inspection systems may install a private trusted certificate authority on managed devices and create separate TLS connections. This allows inspection but means the intermediary can read traffic.

Mixed content

An HTTPS page that loads scripts or other active content over plain HTTP undermines its protection.

Browsers block much mixed content.

Passive resources can also leak information or be altered, so sites should load all dependencies through HTTPS.

Content Security Policy and secure resource URLs strengthen the page.

HTTPS and DNS

HTTPS does not normally hide every DNS lookup.

Encrypted DNS can protect queries between the client and resolver. Newer TLS features can reduce hostname metadata exposure, but deployment varies.

Network observers can still infer destinations through IP addresses, timing, and traffic patterns.

HTTPS provides strong content protection, not complete network anonymity.

Session resumption

TLS handshakes cost time and computation.

Session resumption lets returning clients establish new protected connections using previously issued state, reducing handshake work.

TLS 1.3 can support early data, but replay risks mean applications must be careful which operations are accepted before the full handshake completes.

Performance features must preserve security semantics.

Certificate expiration

Certificates have limited validity.

Automation can issue and renew them, but failures cause browser errors.

Shorter lifetimes reduce exposure if keys or validation state become stale, while increasing dependence on reliable renewal.

Monitoring should alert before expiry and verify the deployed certificate, not merely a file stored somewhere.

Common misunderstandings

"HTTPS means the website is safe"

It authenticates the domain connection and protects traffic. The site can still be fraudulent, vulnerable, or malicious.

"HTTPS hides which server I contact completely"

Observers can still see network endpoints and traffic patterns, and some naming metadata may remain visible.

"The certificate encrypts all data by itself"

The certificate authenticates public-key material. The handshake derives symmetric session keys used for bulk encryption.

"Data protected by HTTPS is encrypted forever"

TLS protects transit. Storage, logs, browser extensions, endpoints, and internal services require separate protection.

Knowledge check

1. What three main protections does TLS provide?

Confidentiality through encryption, integrity against tampering, and authentication of the server identity.

2. What does the certificate hostname check prevent?

It helps prevent a server authorized for one domain from impersonating another requested domain.

3. Can a phishing site use HTTPS?

Yes. It can obtain a valid certificate for a domain it controls.

4. What does forward secrecy accomplish?

Later theft of a server's long-term private key should not decrypt previously recorded sessions.

The one idea to remember

HTTPS secures HTTP while it travels by authenticating the named server, encrypting content, and detecting tampering.

It protects the connection, not the intentions, code quality, storage practices, or overall trustworthiness of the site.

Next, we will follow the browser as it resolves, requests, parses, executes, secures, and renders a web page.