Why is it said that the Internet is not secure

Published on 2026-09-12 by frfrand

Internet se diseñó para que los paquetes lleguen, no para que nadie los lea. Qué significa eso en la práctica, qué arregló HTTPS, qué sigue siendo visible y por qué el eslabón débil casi nunca es el cifrado.

The phrase "Internet is not secure" is repeated so often that it has lost its meaning. It’s worth unpacking, because the true part is quite specific, and the false part leads to wrong decisions.

The original design

The Internet was designed so that packets reach their destination even if parts of the network fail. That was the goal, and it was achieved wonderfully.

What was not part of the goal was that no one could read those packets along the way. In a network of universities and research centers where everyone knew each other, this didn’t seem like the main problem.

The consequence is structural: when you send something, that packet passes through your router, your provider, exchange points, transit networks you didn’t choose, until it arrives. Each of those hops handles your traffic. None of them promised you anything.

That’s what "Internet is not secure" means: the transport, by itself, protects nothing.

What HTTPS fixed

HTTPS adds an encryption layer over that transport. And it works: today, in a properly configured connection, no one in the middle can read or modify the content.

It also authenticates the server. The certificate says you’re talking to who you think you’re talking to, and that’s backed by a certificate authority. Without that, encryption would be of little use: you could be having a perfectly encrypted conversation with an impostor.

That today it's free and automatic (Let's Encrypt) is probably the biggest security improvement of the last decade, simply because it made almost everyone use it.

What remains visible

Here is where it pays to be precise, because exaggeration goes in both directions.

With HTTPS, anyone looking at your traffic still sees:

• Which domain you're connecting to. The name travels unencrypted at the start of the handshake, so the server knows which certificate to present.
• How much and when. The size and timing of the packets say quite a bit. You can infer what video you're watching from the download pattern.
• The source and destination addresses. Without those, the packet couldn't be routed.

What it doesn't see: the specific page, what you typed, what you uploaded.

And the point that matters most

None of the above is where real attacks actually enter.

Practically no known breach came from breaking the encryption. They came from:

Repeated passwords. A random site leaks, and that same password opens your email, your bank, and your admin panel.

Outdated dependencies. A known vulnerability, published months ago, with a patch available, on a server nobody updated.

A convincing message. Someone clicks. No math involved.

Something left open. A port, a panel with default credentials, a misconfigured cloud storage.

Encryption is the part of the system that works. The problems are around it.

What to do with this

If you are a user: use different passwords in a password manager, and enable two-factor authentication where possible. That alone will get you out of most cases.

If you manage servers: apply automatic security updates, leave nothing open that doesn’t need to be, use keys instead of passwords, and maintain backups that you have tested restoring.

None of these things is sophisticated. They are exactly the ones that get postponed because they are never urgent—until they are.