Someone Is Watching the Network. What Can They Actually See?

First, what exactly is travelling across the network?

When you type a URL into a browser, your browser isn't communicating with a website in some abstract way.

Data has to move between your computer and another system.

That communication is broken into network packets and transported across multiple protocol layers.

Tools such as Wireshark allow engineers to inspect network traffic visible at a network interface.

That capability is incredibly useful.

Network engineers use packet captures to diagnose connectivity problems.

Developers use them to understand protocol behaviour.

Security teams use them during incident investigations.

Protocol engineers use them to understand exactly what systems are exchanging.

But the same visibility can obviously be useful to an attacker.

The important question therefore isn't:

Can someone capture packets?

The more useful question is:

What information do those packets reveal?

Go back to the web before HTTPS became universal

Suppose our application communicates using ordinary HTTP.

The user submits a login form.

At the application layer, the request might conceptually resemble this:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=arun
password=MyPassword123

There is nothing cryptographically protecting that HTTP payload.

If an attacker is in a position to observe the relevant network traffic, information sent in plaintext can potentially be read.

That might include usernames, passwords, session identifiers, form submissions, URLs, API data, personal information and application responses.

The problem isn't Wireshark.

Wireshark is simply showing us what the network is carrying.

The problem is that the application sent sensitive information across an untrusted network without protecting it.

What changes when we add one letter?

Consider these two URLs:

http://example.com

and:

https://example.com

The difference looks almost trivial.

One letter.

But architecturally, something significant has changed.

HTTPS essentially means:

HTTP communicated over a connection protected by TLS.

HTTP vs HTTPS — same network, different visibility

Where TLS actually sits

TLS is frequently described simply as "encryption."

That's true, but incomplete.

It is useful to understand where it sits in the communication stack.

Where TLS sits in the protocol stack

TLS protects the application data as it moves across the network.

Lower layers still move packets, route traffic and deliver bits.

That means an observer may still see network-level information while being unable to read the protected application payload.

What does TLS actually give us?

Properly implemented TLS provides three particularly important security properties.

Confidentiality

The application data exchanged between the client and server is encrypted.

Someone capturing packets should not simply be able to read:

username=arun
password=MyPassword123

The observer sees encrypted TLS records instead of the plaintext HTTP payload.

Integrity

Encryption alone isn't enough.

We also need assurance that someone sitting between the client and server hasn't silently modified the communication.

TLS provides integrity protection so tampering with protected traffic can be detected.

Authentication

The browser also needs to establish:

Am I actually talking to the server I intended to reach?

This is where certificates become important.

In normal HTTPS communication, the server presents a certificate that allows the client to validate the identity associated with the server.

So TLS isn't merely hiding information.

It is helping establish a trusted communication channel across an untrusted network.

But how does the browser establish trust with a server it has never met?

This is where the TLS handshake comes in.

Before normal protected application communication begins, the client and server establish the parameters required for the secure connection.

The details differ between protocol versions, especially with TLS 1.3, but the architectural objective remains the same:

negotiate supported cryptographic parameters
validate the server certificate
establish shared keys
confirm the handshake
begin protected application communication

TLS handshake and certificate trust

Certificate validation is critical.

The client needs to verify that the certificate is trusted, valid for the domain being accessed, and otherwise acceptable according to the platform's trust rules.

Without that, we could create a beautifully encrypted connection to the wrong system.

So what does someone running Wireshark see now?

This is where cybersecurity explanations often become misleading.

You will sometimes hear:

"With HTTPS, hackers can't see anything."

That's not accurate.

An observer can still see network traffic.

Packets don't disappear simply because encryption is being used.

Depending on the protocol, configuration and observation point, network-level information may still reveal source and destination IP addresses, port numbers, packet sizes, timing, connection duration, traffic volume, protocol characteristics, DNS information in some configurations, and some TLS handshake metadata.

What the observer should not be able to casually recover from correctly protected HTTPS traffic is the plaintext HTTP application content.

There is an important difference between:

I can see that two systems are communicating

and:

I can read what those systems are saying to each other.

TLS is primarily solving the second problem.

This changes how we should talk about public Wi-Fi

For years, one of the most common pieces of cybersecurity advice was:

Never use public Wi-Fi because someone can sniff your password.

There is historical truth behind that warning.

When websites commonly transmitted sensitive information using plaintext HTTP, hostile or compromised networks represented an obvious confidentiality risk.

The modern web is different.

Correctly implemented HTTPS/TLS makes passive packet sniffing substantially less useful for stealing application payloads.

Someone capturing properly protected traffic cannot simply open Wireshark, find your login request and read your password.

That's an important improvement.

But I wouldn't jump from that conclusion to:

Public Wi-Fi is safe.

That's too simplistic in the opposite direction.

The better statement is:

Modern TLS dramatically reduces what an untrusted network can learn about the contents of your communication.

The network itself still shouldn't automatically be trusted.

What about a Man-in-the-Middle attack?

Suppose an attacker can position themselves between the client and the destination.

Without cryptographic protection, that position is extremely powerful.

The attacker may potentially observe or manipulate traffic.

TLS changes the situation because the client doesn't simply establish encryption with whoever happens to answer.

The server has to prove its identity using its certificate.

Your browser validates things such as whether the certificate is trusted and whether it corresponds to the hostname being accessed.

If an attacker simply presents an arbitrary certificate for a banking domain, the browser should reject it.

That certificate validation is just as important as encryption.

Otherwise, we could create a perfectly encrypted connection to the attacker.

Those browser certificate warnings matter

Most people have encountered a browser warning similar to:

Your connection is not private.

Users often treat this as an inconvenience.

But from a security perspective, the browser may be telling you:

I cannot establish sufficient trust in the identity of the system at the other end of this connection.

That deserves attention.

Encryption without trustworthy endpoint authentication doesn't solve the problem we think it solves.

Can HTTPS traffic ever be decrypted by an intermediary?

Yes.

Some enterprises deliberately inspect encrypted traffic.

An organization may install its own trusted certificate authority on managed corporate devices.

A security proxy can then establish one TLS connection with the client and another with the external server.

Because the corporate device has been configured to trust the organization's certificate authority, the proxy can inspect traffic according to organizational security policy.

This is fundamentally different from a random attacker sitting in a coffee shop successfully decrypting modern HTTPS traffic.

The endpoint has explicitly been configured to trust the inspecting authority.

That trust relationship changes everything.

HTTPS protects the journey — not everything at either end

This may be the most important point in the entire discussion.

The communication channel can be cryptographically excellent.

But what happens if the laptop itself is compromised?

Malware may potentially access information before it enters the TLS tunnel.

What happens if the server is compromised?

The server naturally sees information after TLS has decrypted it.

TLS protects data in transit.

It doesn't automatically protect data before transmission or after arrival.

What HTTPS protects — and what it does not

HTTPS also doesn't fix application vulnerabilities

Consider an application vulnerable to SQL injection.

The attacker sends:

' OR '1'='1

over HTTPS.

TLS faithfully encrypts it.

The server faithfully decrypts it.

And the vulnerable application may faithfully execute something it shouldn't.

The TLS connection worked perfectly.

The application is still vulnerable.

The same principle applies to broken access control, insecure APIs, business-logic vulnerabilities, insecure file uploads, SSRF, authentication weaknesses, authorization failures and application misconfiguration.

Transport security and application security solve different problems.

Both matter.

And HTTPS doesn't make a malicious website trustworthy

People sometimes see the padlock and assume:

This website is safe.

That's not what HTTPS proves.

A phishing website can have a perfectly valid TLS certificate.

For example:

https://mybank-secure-login-example.com

might be completely malicious while still having correctly configured HTTPS.

TLS can establish:

You are securely communicating with mybank-secure-login-example.com.

It does not establish:

mybank-secure-login-example.com is actually your bank.

That's a human trust problem, not simply a transport-encryption problem.

What about DNS?

Before connecting to a website, the client typically has to resolve a domain name into an IP address.

Traditional DNS queries have historically been visible to networks handling them.

Modern mechanisms such as DNS over HTTPS and DNS over TLS can protect DNS queries in transit as well.

Again, this illustrates an important architectural principle:

Protecting one layer doesn't automatically protect every layer.

Why HSTS matters

Suppose a website supports HTTPS but the user initially requests an ordinary HTTP URL.

The server may redirect the browser to HTTPS.

But that initial HTTP request occurred before the protected TLS connection was established.

HTTP Strict Transport Security — HSTS — allows a site to tell supporting browsers:

For this domain, always use HTTPS.

Once the browser knows this policy, it can avoid making an insecure HTTP request in the first place.

TLS provides the protected channel.

HSTS helps ensure that the browser consistently uses it.

This is why we should use TLS everywhere

There was once a common application design where only the login page used HTTPS while the rest of the site used HTTP.

The thinking was:

The password is sensitive, so encrypt the login page.

But what happens immediately after authentication?

The browser receives a session identifier.

If subsequent requests expose that session over plaintext communication, an attacker may not need the password.

They may target the session instead.

So the correct architecture isn't:

Encrypt sensitive pages.

It is:

Protect the entire session.

Modern applications should use HTTPS consistently across pages, APIs and sensitive communication.

What should engineering teams actually do?

The answer isn't simply:

Install an SSL certificate.

Transport security needs to be treated as an engineering control.

Use modern TLS

Prefer modern TLS configurations and disable obsolete protocol versions.

Enforce HTTPS everywhere

Don't selectively protect login or payment pages.

Protect the complete application session.

Use HSTS

Tell browsers that the application should only be accessed using HTTPS.

Validate certificates correctly

Never disable certificate validation merely because it makes development or integration easier.

This is particularly important in mobile applications, backend services and IoT systems where developers sometimes implement custom HTTP clients.

Protect cookies

Sensitive session cookies should use appropriate controls such as:

Secure
HttpOnly
SameSite

Keep TLS libraries updated

Cryptographic protocols are only as trustworthy as their implementations.

Patch the underlying libraries and runtime environments.

Don't confuse transport security with application security

TLS belongs in a larger security architecture that also includes identity, authentication, authorization, session security, application security, API security, endpoint security, monitoring and data protection.

No single layer replaces the others.

The architectural view

It is useful to stop thinking about HTTPS as a padlock in the browser.

Instead, think about trust boundaries.

The network between a client and a server can be treated as hostile.

TLS allows us to establish protected communication across it.

But we still have to secure the client.

We still have to secure the server.

We still have to authenticate the user.

We still have to authorize actions.

We still have to protect sessions.

We still have to monitor abnormal behaviour.

And we still have to write secure software.

Coming back to Alex in the coffee shop

Remember Alex?

He opened Wireshark.

Packets appeared on his screen.

He may be able to observe that your laptop is communicating across the network.

He may see IP addresses, ports, packet sizes, timing and other network characteristics depending on where and how he is observing the traffic.

But if your application is correctly using modern HTTPS/TLS, he cannot simply search through the packet capture and read:

username=arun
password=MyPassword123

The application payload is protected.

That is exactly what TLS was designed to accomplish.

But if your endpoint is compromised, you ignore certificate warnings, the application falls back to insecure HTTP, the application itself is vulnerable, or you willingly enter credentials into a phishing site, then the presence of HTTPS doesn't magically rescue you.

And that is the larger security lesson.

Encryption protects the journey

When engineers see HTTPS, the right conclusion isn't:

This application is secure.

The right conclusion is much narrower:

The communication channel between these endpoints is being protected using TLS.

That's enormously important.

But it is one control in a much larger architecture.

Security comes from the chain.

Not from one link.

Encryption protects the journey.

It does not automatically make the traveller, the destination or the application trustworthy.

About the author

Mahesh Maney writes about cybersecurity, software architecture, cloud, IoT and the engineering decisions behind secure digital platforms at Nordstern Digital.

Nordstern Engineering Notes

We write about the engineering decisions behind secure software, cloud, IoT and modern digital platforms — not just the technologies used to build them.

Need help designing secure digital systems?
Talk to Nordstern Digital about your architecture, engineering or cybersecurity requirements.