An unencrypted connection is a conversation held out loud in a room full of people. It is not that somebody is necessarily listening — it is that anybody in the room could.
This post looks at what that means concretely across the three aspects by which the security of information is measured, and who is actually in that room.
It expands on the recommendation browsing only over HTTPS.
Who is in the room
Before the impacts, the perimeter: unencrypted connections are readable by whoever sits along the route, and the route is busier than people imagine.
| Who | What they see | How likely |
|---|---|---|
| Whoever runs the network you are connected to | All the traffic in the clear | Certain: it is their equipment |
| Whoever is connected to the same network | Everything, with trivial tools on open networks | Possible |
| Whoever provides the internet access | All the traffic in transit | Technically certain, regulated by law |
| Whoever runs the transit infrastructure | The traffic passing through their equipment | Technically possible |
| Whoever compromised the home router | All the household traffic | Rare but documented |
The first row is the one that concerns daily life: every network you connect to has an operator, and over an unencrypted connection that operator sees the content, not just the destination.
1. Confidentiality: what becomes readable
A practical example
A site asking you to sign in over http://. The credentials typed into the form travel in the clear.
What the incident looks like
What travels readably over an unencrypted connection is more than people expect:
- the credentials typed into forms;
- the content of the pages viewed, including already authenticated ones;
- the data entered into any form: addresses, numbers, messages;
- the session cookies, that is, the token proving to the site that it is you.
The last point deserves attention because it is the least intuitive: whoever captures a session cookie can use it to enter the account without knowing the password. They do not need your username and they do not need the second factor: the session is already authenticated.
It is one of the few routes that completely bypass the recommendations on passwords.
What to watch for
- the address starts with
http://; - the browser shows “not secure” beside the address;
- the site asks you to sign in showing no encryption indicator at all.
What to do
Type nothing sensitive. If the site is necessary, reach it from a network you control.
2. Integrity: the page that changes in transit
It is the least known impact and in many cases the most serious, because it does not require anybody to read: it requires somebody to modify.
A practical example
A page requested in the clear is delivered to the browser with content slightly different from what the site sent.
What the incident looks like
Whoever sits along an unencrypted route is not limited to listening. They can:
- insert content into the page: an extra form, a warning, a button;
- change the links, pointing elsewhere what should lead to the site;
- replace a file being downloaded with a different one;
- redirect the browsing to another address.
The third item is what links this unit to updates: a program downloaded over an unencrypted connection can be swapped along the route, and what gets installed is not what was chosen.
Encryption prevents all of that not because it hides, but because the browser notices if the content has been altered — and in that case refuses to show it.
What to watch for
- unexpected elements in the page: warnings, forms, requests to install something;
- advertising unrelated to the site;
- redirects you did not ask for;
- a downloaded file with a different size or name from the one expected.
What to do
Download programs only over encrypted connections and from official sources.
3. Availability: the least relevant case
A practical example
Whoever controls the network blocks access to a site or slows the traffic.
What the incident looks like
Availability is the aspect this recommendation touches least, and it is right to say so rather than force a symmetry. Whoever controls the network can block or slow, but they can do that with encrypted traffic too: blocking only requires knowing the destination, which stays partly visible.
The only effect specific to the lack of encryption is that it becomes possible to degrade selectively individual pieces of content inside a page, rather than blocking everything.
What to do
Nothing specific. It is the aspect where encryption offers least.
| Aspect | What a connection in the clear allows | Severity |
|---|---|---|
| Confidentiality | Reading credentials, content, session cookies | High |
| Integrity | Altering the page and replacing files | Very high |
| Availability | Little more than is possible anyway | Low |
Why the risk has changed in recent years
It is worth being accurate, because an alarmist description of this recommendation would not be honest.
Ten years ago much of the web travelled in the clear, and this was one of the most urgent recommendations. Today the situation is profoundly different: almost every site uses encrypted connections, browsers actively flag the ones that do not, and some block them altogether.
That shifts the weight of the recommendation from “always check” to “recognise the exceptions”. The remaining exceptions are few and identifiable:
| Where traffic in the clear survives | Why |
|---|---|
| Old, unmaintained sites | Nobody has updated them |
| The configuration pages of home devices | Routers, printers, cameras |
| The sign-in portals of public networks | The page appearing before you connect |
| Dated applications | Not all use the browser and not all encrypt |
| Hastily built fraudulent sites | Though most today use valid certificates |
The third row concerns an everyday situation: the sign-in page of a public network is often in the clear, and it is exactly the point where some networks ask for personal data.
How much it really weighs, by context
Not every situation involving traffic in the clear carries the same weight. A proportionate assessment avoids both underestimation and needless alarm.
| Context | Exposure | Why |
|---|---|---|
| An open public network | High | Anybody connected can observe |
| A public network with a shared password | Medium-high | The password is known to every customer |
| A network in an office that is not yours | Medium | It depends on who runs it |
| A home network | Low | The perimeter is you and the people you live with |
| The operator’s mobile network | Low | Traffic is encrypted over the radio link |
The last row is useful because it corrects a widespread belief: a phone’s data connection is generally better protected than a cafe’s Wi-Fi, because the link between the device and the mast is encrypted by the operator. It does not make HTTPS unnecessary — the operator remains an intermediary — but it removes the scenario of somebody listening from the next table.
Hence a simple practical rule: if you have to do something sensitive and you are on a network you do not know, use your phone’s data instead of the Wi-Fi. It is more effective than many complicated precautions.
The impact that stays afterwards
As in the other units, the useful distinction is between what ends and what continues.
Ends: reading a page, viewing a piece of content.
Continues: a captured session cookie stays usable as long as the session is valid — often weeks. A swapped file stays installed. A credential that was read stays usable until it is changed.
That is why, after entering credentials over an unencrypted connection, the correct action is not merely to avoid doing it again: it is to change that password and close the active sessions.
It deserves its own paragraph, because it is the least intuitive impact in this unit and the one that bypasses the most protections.
What it is. When you sign in to a service, the site hands you a temporary identifier — a token — which the browser sends back with every later request. It is what saves you typing the password on every page.
Why it counts. That token is the proof that it is you. It is not a password: it is the result of having already proved you are.
What it means. Whoever captures it does not have to do any of the things the other recommendations prevent:
| Protection | Why it does not come into play |
|---|---|
| A unique, long password | The password does not have to be typed |
| A password vault | It never comes into play |
| A second factor | It was already passed at the original sign-in |
| A new sign-in alert | There is no new sign-in: the session was already active |
The last row is what connects this unit to R8: a reused session does not necessarily produce an alert, because from the service’s point of view no login took place.
What closes it. One thing only, and it is not changing the password on every service: explicitly revoking the active sessions, the function panels call “sign out of all devices”. It is the only action that invalidates the token.
And it is also why, in the recovery procedures described in this series, revoking sessions always comes before changing the password.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Awareness | Understanding that the greater impact is modification, not reading |
| Skills | Recognising the few situations where traffic in the clear survives |
| Secure Behaviour | Changing credentials used over an unprotected connection |
Reference level: FL2 — Beginner.
Summary
- Over a connection in the clear, credentials, content and session cookies are readable.
- A captured cookie bypasses password and second factor: the session is already authenticated.
- The most serious impact is not reading but altering the page and the files downloaded.
- Today traffic in the clear survives in a few identifiable situations, and those are the ones to recognise.
One thing to do today. Open your browser’s settings and turn on “HTTPS-only” mode. From then on the browser flags the exceptions for you, and you no longer have to look for them.
Related content
- Browsing only over HTTPS — the recommendation this expands on
- Consequences of data sent in the clear — the concrete effects
- Traffic interception — who can get in between, and with what techniques
- How HTTPS works — why alteration gets detected
Related resources
Short reads from the Resources section, for anyone who wants to stop on a single aspect:
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
