How to chat safely online

Threat model (maximum suspicion)

This article assumes almost nothing is trustworthy by default. If we draw no trust boundary at all, then no software-only solution can exist, because an attacker can always control the device or the software.

So I make three temporary trust assumptions only for reasoning:

  • iOS on a real device: treated as a baseline trusted OS.
  • Pixel official Android (latest): similar or slightly lower trust than iOS.
  • Ubuntu (latest): treated as a trusted open-source OS.

This is not a claim of absolute safety. If the OS, firmware, supply chain, or update channel is compromised, the endpoint is lost and encryption fails. Everything below only makes sense if these temporary assumptions hold.

From principles: why encryption is not enough

Encryption has two separate problems:

  1. How do we share a key safely?
  2. How do we confirm the other person’s identity?

If either step fails, a man-in-the-middle can take over.

Symmetric encryption: fast, but key sharing is hard

Symmetric encryption uses one shared key for encrypt/decrypt (e.g., AES-256).
It is fast and good for long messages, but the hard part is how to deliver the key safely.

If you send the key over a monitored channel, the attacker can copy it. This is a passive attack (read-only, no modification).

Asymmetric encryption: solves key sharing, creates identity risk

Asymmetric encryption uses a public/private key pair.
A encrypts with B’s public key, and only B can decrypt with B’s private key.

This solves key sharing, but introduces a new question:
How do you know the public key really belongs to B?

MITM: the classic failure

If A and B exchange public keys through server C, and C replaces the key, then A encrypts to C by mistake.
C reads the message and re-encrypts it to B.
A and B think they are talking directly, but C sits in the middle.

Conclusion: asymmetric encryption alone does not stop MITM. It blocks passive eavesdropping but not active key replacement.

To stop MITM, you must authenticate identity

Two common paths:

  1. Certificate authentication (TLS/HTTPS): trust the CA system.
  2. Out-of-band verification: verify the key via a separate channel.

Certificate authentication (TLS/HTTPS)

Your browser ships with CA root certificates. Websites get certificates signed by a CA, and your browser verifies the signature.
This is the foundation of HTTPS — as long as you trust the CA system.

Out-of-band verification (humans)

You can verify the key fingerprint through another channel:

  • in-person (strongest, but least realistic)
  • voice/phone
  • video call

Voice/video is not perfect, but forgery costs are higher, so it is often the most realistic compromise.

The practical path (maximum suspicion, realistic trade-off)

In a maximum-suspicion model, distribution trust is the hardest problem. Individual developers can rarely provide strong, verifiable distribution, and app stores are not a final trust anchor.

So the practical path is not “pick a tool,” but reduce the trust surface.
In reality, pure client distribution is hard to verify, so “self-controlled clients” are difficult to make trustworthy.

I weighed this repeatedly: once the client is replaced, all encryption fails.
Compared to that, concentrating risk on the server side allows at least operational security and isolation.

So I ultimately prefer a Web-based chat client as the most realistic option for normal people:
focus the risk on the server, and reduce the attack surface with operational controls.
This is risk management, not a guarantee; the server remains a single point of failure.

Plan: self-hosted server + Web client (realistic mainline)

Core idea: accept that client distribution is not trustworthy, and focus on server security and network isolation, while still providing real end-to-end encryption.

Minimum security baseline this plan must satisfy (miss any of these and security drops sharply):

  1. Identity authentication: support fingerprint/safety-code verification to prevent MITM.
  2. Forward secrecy: use ephemeral session keys; leaking one key should not reveal history.
  3. Modern algorithms and strong keys: reject weak crypto or short keys.
  4. End-to-end encryption: messages are encrypted on the client; the server only relays ciphertext.
  5. Secure endpoint key storage: private keys must not be trivially readable.
  6. Auditable/reproducible builds: you can verify that what you run matches the code.
    For a Web client this is an ideal goal, not fully achievable in practice.

Practical, actionable steps:

  1. Self-host the server: at home or in a trusted location.
  2. Network isolation: use a dedicated switch/VLAN to prevent the server from accessing other home devices.
  3. Public exposure: open only required ports, use DDNS to reach your server.
  4. Force TLS/WSS: all connections must use HTTPS/WSS (it protects transport, not endpoints).
  5. Open-source the client code: at least allow logic auditing (even if distribution is not fully verifiable).
  6. Acknowledge Web endpoint limits: browser storage/keys are weaker than native clients.

Optional hardening: voice/video fingerprint check
Even with a Web client, identity authentication is still required.
A quick voice/video check can significantly reduce MITM success rate.

TLS vs E2EE: do not confuse them

  • TLS (HTTPS) protects the link between you and the server. The server can read it.
  • E2EE protects the link between you and the other person. The server cannot read it.

Conclusion: TLS protects transport; E2EE protects content from the service itself.

“Claims E2EE” is not the same as “trusted”

Even with a good protocol, failure is still possible:

  • the client is closed-source
  • the update channel can change behavior
  • metadata can still be logged
  • linked devices create new endpoints

So the key question is not “Does it claim E2EE?”
The key question is “Do I trust the software I am running?”

Skepticism toward phone/email registration

Many E2EE tools are respectable, but phone/email identity has built-in risks:

  • phone/email is a real-world identity anchor
  • SIM swap and email recovery flows can be attacked
  • metadata linkage is strong

This does not prove malicious intent. Under a maximum-suspicion model, the risk is still high.

What HTTPS can and cannot do

HTTPS protects the network path, not the endpoint.

  • If the browser is compromised, HTTPS does not help.
  • If the device is compromised, HTTPS does not help.
  • If the server is compromised, HTTPS does not help.

So HTTPS is necessary but not sufficient.

Practical rules (within the temporary trust boundary)

  1. Always authenticate identity: verify fingerprint/safety codes.
  2. Reduce metadata: avoid binding to phone/email when possible.
  3. Keep the server blind: prefer E2EE, never trust the server with plaintext.
  4. Keep endpoints clean: fewer apps, fewer extensions, fewer permissions.
  5. Keep suspicion: any claim can be false.

Final reminder

Security is built on assumptions.
If your assumptions fail, everything fails.

Write your threat model first, then build your solution.

Quick glossary (simple)

  • Symmetric encryption: one shared key for encrypt/decrypt.
  • Asymmetric encryption: public key encrypts, private key decrypts.
  • Public/private key: public can be shared; private must be secret.
  • Key exchange: the process of agreeing on a shared key.
  • Authentication: proving identity or key ownership.
  • Certificate/CA: a signed system that binds a public key to a domain.
  • MITM: attacker sits between you and the other person and relays messages.
  • Fingerprint: short hash of a public key used for verification.
  • Digital signature: proves a message came from a private key owner and was not modified.

Content licensed under CC BY-NC-SA 4.0.

Comments

⬆︎TOP