DEV Community: Haven Messenger

The Terrapin Attack: How a Few Deleted Packets Weaken SSH

Haven Messenger — Tue, 21 Jul 2026 12:19:27 +0000

SSH is the protocol most engineers trust without a second thought. Terrapin, disclosed in December 2023 as CVE-2023-48795, showed that a network attacker sitting between client and server can quietly delete messages from the very start of an SSH connection, and the encryption never notices. It does not decrypt anything. It manipulates the sequence numbers that hold the session together.

Terrapin is a prefix truncation attack. That phrase does most of the work: an attacker who controls the network path can chop a controlled number of messages off the front of the encrypted stream so that both sides end up in a slightly different state than they agreed to. The research came from Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk at Ruhr University Bochum, and it is notable because SSH had spent two decades being treated as effectively unbreakable at the transport layer.

The attack does not recover your password or read your files. What it does is subtler, and understanding it is a good lesson in how real cryptographic protocols fail. They rarely fail because the cipher is broken. They fail at the seams between the parts.

How SSH keeps a session honest

When an SSH client and server connect, they run a handshake. They exchange version strings, negotiate which algorithms they will use, perform a key exchange, and then switch on encryption for everything that follows. To make sure nobody has tampered with any of the messages in transit, SSH uses a running sequence number. Every binary packet gets an implicit counter, starting from zero, and that counter feeds into the message authentication code that protects each packet.

The sequence number is the quiet guarantee that message number five really is the fifth message, in order, with nothing added and nothing removed. If an attacker drops a packet, the counters on the two sides drift apart, the authentication tags stop matching, and the connection tears down. That is the design working as intended.

The core insight: SSH authenticates the order and count of messages using a shared sequence number. Terrapin's trick is to make the client and server disagree about that count before authentication starts protecting the stream, so the mismatch is invisible.

The gap Terrapin exploits

Here is the problem. During the handshake, before the secure channel is fully established, SSH allows certain unencrypted messages. One of them is SSH_MSG_IGNORE, a no-op message that exists so implementations can pad traffic or keep connections alive. There is also an optional SSH_MSG_EXT_INFO message that lets the two sides advertise protocol extensions right at the start of the encrypted phase.

The sequence counter starts ticking during the unencrypted portion of the handshake. That means an attacker can inject an extra ignorable message during the handshake, which bumps the counter on one side, and then later delete a real message to bring the counter back into apparent agreement. The two sides never notice, because the injection happened while the messages were not yet authenticated. By the time the authenticated encryption is running, both sides believe their counters are aligned, but the actual conversation has had a message silently removed from the front.

The most useful thing to delete is SSH_MSG_EXT_INFO. Removing it strips the extension negotiation, which can downgrade security features the client and server would otherwise have turned on. In particular, some servers use extension negotiation to enable stronger, more modern message authentication or to signal support for defenses against keystroke timing analysis. Delete the announcement and you delete the upgrade.

Which algorithms were affected

Terrapin is not a flaw in every SSH configuration. It depends on specific encryption modes that let the truncation go undetected. Two categories were vulnerable:

Cipher / mode	Terrapin exposure
ChaCha20-Poly1305 (chacha20-poly1305@openssh.com)	Vulnerable: the sequence number is used in a way that lets the truncation stay hidden
CBC with Encrypt-then-MAC (*-etm@openssh.com)	Vulnerable: the EtM construction combined with CBC allowed the same manipulation
AES-GCM	Not affected by the prefix truncation in the same way
CTR with Encrypt-and-MAC (older non-EtM modes)	Not the target: different construction, though these have their own reasons to avoid

The awkward part is that ChaCha20-Poly1305 was, and remains, an excellent cipher. There is nothing wrong with the algorithm itself. The vulnerability lived in how SSH wired the sequence number into that particular packet construction. This is the recurring theme of authenticated encryption going wrong: the primitive is sound, the integration leaks.

The fix: strict key exchange

The repair was elegant and quick. It is called strict key exchange, or "strict kex," and OpenSSH shipped it in version 9.6 alongside the disclosure. The idea is simple. During the handshake, no unnecessary messages are tolerated. If a client or server receives an unexpected message like SSH_MSG_IGNORE before the key exchange completes, it aborts the connection instead of accepting it.

Strict kex also resets the sequence number to zero when encryption is switched on. That removes the attacker's ability to smuggle counter drift across the boundary between the unencrypted and encrypted phases. Both sides now start counting from the same clean baseline once the secure channel exists. The catch is that strict kex only protects a connection if both endpoints support it, since it is negotiated. An updated client talking to an old server gets no benefit.

Terrapin required an attacker positioned to intercept and modify traffic between client and server. That is a meaningful bar. But "on the network path" describes every public Wi-Fi router, every compromised ISP node, and every state actor with access to a backbone. It is not an exotic position.

What Terrapin does and does not mean for you

It is worth being precise about severity, because Terrapin was reported with a range of headlines that oversold it. The attack does not let someone read your SSH session or steal your keys directly. Its real effect is downgrade: stripping the security extensions two modern endpoints would have negotiated, which in some configurations weakened defenses and, when chained with certain implementation bugs in specific SSH libraries, could enable more serious follow-on attacks.

For most administrators the response was undramatic and correct: update OpenSSH on both ends, confirm strict kex is negotiated, and if you cannot update immediately, temporarily prefer AES-GCM and disable the vulnerable ChaCha20-Poly1305 and CBC-EtM modes. The researchers published a scanner so operators could test their own servers.

If you run SSH servers: Confirm both client and server are on OpenSSH 9.6 or later, or the patched build from your distribution. Strict key exchange only defends a session when both ends support it. Auditing your negotiated algorithms with a tool like ssh -vv or a Terrapin scanner tells you where you actually stand, rather than where you assume you stand.

The larger lesson for protocol design

Terrapin is a clean example of a class of failure that keeps appearing in secure protocols: the transcript is not fully authenticated. A handshake is only trustworthy if both parties can prove, after the fact, that they saw exactly the same sequence of messages, in the same order, with nothing added or removed. SSH authenticated most of that, but left a small unauthenticated window at the boundary, and that window was enough.

Newer protocols design against this from the start. TLS 1.3 binds the entire handshake into a transcript hash that both sides confirm before any application data flows, which is one reason it closed off a whole family of downgrade attacks that plagued earlier versions. The Noise protocol framework takes the same discipline further, treating the running transcript as a first-class object that every step mixes into the keys. The lesson SSH learned the hard way is one these designs assume: authenticate the whole conversation, including its shape, not just its contents.

For anyone building or evaluating encrypted communication, Terrapin is a reminder that "it uses strong encryption" is the beginning of the security question, not the end. The interesting failures happen in the negotiation, the ordering, the state machine, and the seams. That is exactly where careful protocols like MLS spend most of their engineering budget, because a strong cipher wrapped in a sloppy handshake is only as good as the handshake.

Originally published at havenmessenger.com

Subdomain Takeover: When Dangling DNS Hands Your Domain to Strangers

Haven Messenger — Sun, 19 Jul 2026 12:20:10 +0000

A marketing team spins up a landing page on a cloud platform, points shop.example.com at it with a CNAME record, and moves on. Two years later someone deletes the cloud resource but nobody touches the DNS. That leftover record now points at an address anyone can claim, and whoever claims it gets to serve content as shop.example.com, with a valid TLS certificate to match.

This is subdomain takeover, and it is one of the most common findings in bug bounty programs for a simple reason: it is created by ordinary operational drift, not by a mistake anyone notices at the time. The vulnerability lives in the gap between two teams, the one that manages DNS and the one that manages cloud resources, and it appears the moment those two stop agreeing about what exists.

How the takeover works

Most cloud hosting platforms let you attach a custom domain to a resource you control. GitHub Pages sites, object storage buckets, managed app platforms, and CDN distributions all follow the same pattern: you create the resource, the platform gives you a target hostname, and you point your subdomain at that target with a CNAME record.

The trouble starts when the resource is deleted but the CNAME survives. The record is now "dangling": it points at a hostname on the platform's infrastructure that no longer belongs to anyone. On platforms where resource identifiers are claimable, an attacker registers a new resource that answers at that same target, and the platform starts serving the attacker's content to anyone who visits your subdomain.

The attacker never touched your DNS, your registrar account, or your servers. That separates this from domain hijacking, where the registrar account itself is compromised. Here the DNS is doing exactly what you told it to do. The instruction is simply stale.

Why it is worse than a defaced page

Serving phishing pages from a trusted domain is the obvious payoff, and it is bad enough: a login form at accounts-help.example.com convinces people that a form at totally-unrelated-domain.com never would. But the browser security model makes a controlled subdomain considerably more dangerous than a convincing fake.

Cookies scoped to the parent domain leak. A cookie set with Domain=example.com is sent to every subdomain, including the one the attacker now controls. Depending on what the main site stores in domain-wide cookies, that can mean session material arriving in the attacker's logs. Cookie attributes like SameSite restrict cross-site sending, but a sibling subdomain is same-site.
Valid TLS comes free. The attacker controls the content served at the subdomain, which is exactly what a certificate authority checks during HTTP-01 domain validation. They can obtain a browser-trusted certificate for your subdomain in minutes. CAA records can narrow which authorities will issue, but they do not stop issuance for a subdomain whose content the attacker controls unless the policy is unusually strict.
Trust relationships in code fire. Sites frequently allowlist their own subdomains in CORS policies, Content Security Policy directives, OAuth redirect URIs, and postMessage origin checks. Every one of those becomes a bridge from the attacker's page into the application proper.

A subdomain is not a separate identity. Browsers, certificate authorities, and your own application code all extend measures of trust from example.com to its children. Taking over one subdomain means inheriting slices of that trust, not just borrowing the name.

The variants: CNAME, NS, and forgotten A records

The CNAME-to-dead-resource case is the most common, but it has siblings. A dangling NS record, left over from a delegated zone whose nameservers were decommissioned, hands an attacker control of an entire subtree of your namespace rather than one hostname: they re-register the nameserver domain or claim the hosted zone and answer authoritatively for everything under the delegation. A stale A record pointing at a released cloud IP address is a slower, luckier version of the same thing, since the attacker has to be assigned that specific IP by the provider, but with enough churn in a provider's address pool it happens.

Researchers have demonstrated takeovers against subdomains of some of the largest companies on the internet, and continue to. The platforms have responded unevenly. GitHub Pages added domain verification so an organization can prove ownership of a domain and block others from claiming its subdomains. Several cloud providers now require a TXT record proving domain control before a custom hostname binds to a new resource. Many services still perform no such check, which is why the class persists.

Finding your own dangling records

The defensive work is an inventory problem. You need to know every DNS record your organization publishes and whether the thing each record points at still exists and still belongs to you.

Step	What it catches
Export the full zone	Shadow records nobody remembers creating. Zone files from the provider's API beat memory every time.
Resolve every CNAME target	Targets that return NXDOMAIN or a platform's "no such app" page are candidates for takeover right now.
Match records to live resources	Records that resolve but point at resources in accounts your organization no longer controls, such as a departed contractor's platform account.
Audit NS delegations	Whole-subtree exposure from decommissioned nameservers, the highest-impact variant.
Watch certificate transparency	A certificate you did not request for one of your subdomains is a loud signal someone else validated control of it. CT logs are public and monitorable.

The deeper fix is procedural: make DNS cleanup part of resource decommissioning, in that order. Delete the record first, then the resource. A resource that briefly outlives its DNS record is harmless. A DNS record that outlives its resource is the entire vulnerability.

What this means if you just use the web

You cannot audit other people's DNS, and a takeover on a site you use is invisible by design: the URL is right, the padlock is present, the certificate validates. The practical defenses are indirect. Password managers help here in a way people rarely credit, since autofill keyed to an exact origin will happily fill a hijacked subdomain, but unique per-site passwords cap the damage at one account. Phishing-resistant authentication helps more: a passkey or hardware key bound to the real login origin will not authenticate to a page an attacker stood up on a different subdomain than the one the credential was registered on.

Mostly, though, subdomain takeover is a reminder of how much of web trust is infrastructural. The security of a name depends on an unglamorous chain of records, resources, and the people who remember to delete both together.

Originally published at havenmessenger.com

PQXDH and PQ3: How Messengers Are Going Post-Quantum

Haven Messenger — Sat, 18 Jul 2026 12:20:07 +0000

Nobody has a quantum computer that can break encryption. Signal and Apple upgraded their messengers anyway, and they were right to. The attack that matters is already running: record the encrypted traffic today, decrypt it when the hardware arrives. Here is what PQXDH and PQ3 actually changed, and what they deliberately left alone.

In September 2023, Signal replaced the key agreement at the start of every new conversation. The old handshake, X3DH, built its shared secret entirely from elliptic-curve Diffie-Hellman operations. The new one, PQXDH, runs the same elliptic-curve exchange and adds a second secret produced by a post-quantum key encapsulation mechanism. Five months later, Apple shipped PQ3 for iMessage in iOS 17.4, built on the same idea with one significant addition. Both upgrades rolled out silently. No user saw a prompt, and no message looked different.

That silence is worth unpacking, because these two deployments moved post-quantum cryptography from conference papers into the default texting apps of a large fraction of the planet, and the design choices they made are a preview of how the rest of the industry will do it.

The Deadline Is Not the Quantum Computer

A cryptographically relevant quantum computer, one that can run Shor's algorithm against real key sizes, does not exist. Estimates of when one might range from a decade to never. If that were the whole story, upgrading in 2023 would have been early.

It is not the whole story, because encrypted traffic can be stored. An adversary that captures your TLS sessions or your messaging handshakes today can hold the ciphertext until decryption becomes possible, then read everything retroactively. The approach is usually called harvest now, decrypt later. For most people the risk is abstract. For a journalist's source list, a dissident's contact graph, or a company's negotiating position, a message that must stay confidential for fifteen years has to be encrypted, today, against the computer that might exist in fifteen years.

Quantum attacks split into two categories. Breaking confidentiality works retroactively on recorded ciphertext, so the key exchange had to move first. Forging signatures only helps an attacker at the moment of the handshake, so classical authentication can wait until post-quantum signatures mature. Both Signal and Apple made exactly this split.

What PQXDH Actually Does

PQXDH keeps the entire X3DH structure: long-term identity keys, signed prekeys, one-time prekeys uploaded to the server so that conversations can start while the recipient is offline. To this it adds a Kyber-1024 key encapsulation. Kyber, standardized by NIST in 2024 under the name ML-KEM, is a lattice-based scheme; its security rests on a different mathematical problem than elliptic curves, one with no known quantum shortcut.

The important design decision is that the two exchanges are combined, not substituted. The elliptic-curve secrets and the Kyber secret are all fed into the key derivation function together. An attacker has to break both to recover the session key. This hybrid construction is deliberate humility: lattice cryptography is newer than elliptic curves, and if a classical weakness turns up in Kyber, the conversation is still protected by X25519. The same belt-and-suspenders reasoning appears in post-quantum TLS.

The cost is size. An X25519 public key is 32 bytes. A Kyber-1024 public key is 1,568 bytes. Prekey bundles got bigger, servers store more, and handshakes carry more data. For a messenger this is noise on a modern connection, which is part of why the rollout could be silent.

PQ3 and the Rekeying Problem

Apple's PQ3 starts from the same playbook: hybrid initial key agreement, elliptic curves plus Kyber, secrets combined so both must fall. Then it addresses a problem PQXDH initially left open: what happens after the handshake.

Modern messengers do not use one key per conversation. The Double Ratchet continuously replaces keys, which is what gives you forward secrecy and self-healing after a compromise. In Signal's 2023 design, the ratchet's ongoing Diffie-Hellman steps remained classical, so the post-quantum guarantee applied to the conversation's starting secret. PQ3 built periodic post-quantum rekeying into the conversation itself: fresh Kyber material is woven in as the conversation progresses, so even a conversation that runs for years keeps re-anchoring itself to post-quantum secrets.

Signal closed the same gap from its own direction. In 2025 it published the Sparse Post-Quantum Ratchet, which adds a quantum-resistant component to the ongoing ratchet rather than only the handshake. The engineering challenge in both designs is the same: Kyber material is fifty times the size of the elliptic-curve equivalent, and a ratchet touches every message, so the schemes go to real lengths to amortize the large keys across many messages instead of paying the cost each time.

What Stays Classical, and Why That Is Fine For Now

Neither system uses post-quantum signatures for identity. Your long-term identity key, the thing your contacts verify, is still an elliptic-curve key. This is a considered choice, not an oversight. To exploit it, an attacker needs a working quantum computer at the time of the attack, because forging an identity only helps during a live handshake. Recorded traffic does not become forgeable in retrospect. When post-quantum signature schemes settle down (they are currently much larger and less battle-tested than ML-KEM), identity keys can migrate without invalidating the confidentiality work already shipped.

Component	Signal (PQXDH + SPQR)	iMessage (PQ3)
Initial key agreement	Hybrid: X25519 + Kyber-1024	Hybrid: elliptic curve + Kyber
Ongoing rekeying	Post-quantum ratchet added 2025	Periodic post-quantum rekeying from launch
Identity / authentication	Classical elliptic curve	Classical elliptic curve
Fallback if Kyber breaks classically	Elliptic-curve layer still holds	Elliptic-curve layer still holds

How to Read a Post-Quantum Claim

As more services advertise quantum resistance, the useful questions are specific ones. Is the post-quantum exchange hybrid, or did the classical layer get removed? Does the protection cover only the first handshake, or does rekeying stay quantum-resistant over the life of the conversation? Is the scheme a NIST-standardized one like ML-KEM, or something proprietary? And is there a published protocol description that outside cryptographers can check? Signal and Apple both published detailed designs and invited formal analysis; several academic verifications of PQ3 and PQXDH followed. A vendor that claims quantum safety without showing the construction is asking for trust it has not earned.

It is also worth keeping the threat in proportion. For most attackers, breaking the cryptography was never the plan. Compromising the endpoint is cheaper, today and in the quantum future: a phone infected with mercenary spyware reads your messages in plaintext regardless of which lattice problem protects the wire. Post-quantum migration protects one specific, real, long-horizon risk. It does not change the rest of your threat model.

Group messaging is the next frontier: the MLS working group is standardizing post-quantum ciphersuites, and group protocols multiply the key-size problem by the member count, which makes the amortization tricks above matter even more.

Originally published at havenmessenger.com

Off-the-Record Messaging: Where Deniable Encryption Started

Haven Messenger — Thu, 16 Jul 2026 12:20:46 +0000

In 2004, three researchers published a paper with a pointed subtitle: "Why Not To Use PGP." Their argument was that encrypting instant messages with PGP gets the security properties backwards, and their replacement protocol, Off-the-Record Messaging, introduced ideas that every serious messenger now treats as mandatory. OTR itself is nearly gone. Its ideas run inside billions of phones.

The paper was "Off-the-Record Communication, or, Why Not To Use PGP," by Nikita Borisov, Ian Goldberg, and Eric Brewer, presented at the Workshop on Privacy in the Electronic Society in 2004. Its core observation: a private conversation in person has two properties that PGP-encrypted email destroys.

First, once the conversation is over, it is over. Nobody can later produce a transcript and prove what was said. Second, if someone steals your house keys tomorrow, they cannot retroactively hear what you said in your kitchen yesterday. PGP fails both tests. A signed message is durable, transferable proof that you wrote those exact words. And a message encrypted to a long-term key stays decryptable for as long as that key exists, so a key stolen years later unlocks years of archived ciphertext.

Borisov, Goldberg, and Brewer wanted digital conversations to behave like spoken ones. That requirement produced two properties with names that are now standard vocabulary: forward secrecy and deniability.

Forward secrecy: keys with a shelf life

OTR never encrypts messages directly to a long-term key. Instead, both parties run a Diffie-Hellman key exchange with fresh, ephemeral values, and they keep re-running it as the conversation continues. Each time a message flows in a new direction, the parties advertise new DH values and derive new encryption keys, discarding the old ones.

The consequence is that no single stolen key unlocks the conversation history. The long-term key in OTR exists only to authenticate the initial handshake, never to encrypt content. Compromise it and you can impersonate someone in future conversations, which is bad, but you cannot decrypt anything already said. In 2004, when the norm for "secure" chat was a static key or a plain TLS tunnel to the server, this was a genuinely unusual design decision.

Deniability: encryption that refuses to testify

The stranger idea was deniability, and OTR implemented it with two mechanisms that still read as clever twenty years later.

Malleable encryption. OTR encrypts with AES in counter mode, a stream cipher construction. Stream ciphers are malleable: anyone who can guess the plaintext can flip bits in the ciphertext to produce any other plaintext of the same length. For data integrity this sounds like a defect, and inside a live conversation OTR prevents tampering with authentication codes. But as forensic evidence, malleability is a feature. A ciphertext that anyone could have forged proves nothing about who wrote it.

Published MAC keys. Messages are authenticated in transit with a MAC (a symmetric integrity check) rather than a digital signature. Both parties hold the MAC key, so each party already knows the other could have forged any given message. Then OTR goes one step further: once a MAC key is no longer needed, the protocol broadcasts it in plaintext as part of the conversation. After the fact, literally anyone who captured the traffic could have forged messages with valid MACs. The transcript authenticates the conversation while it happens and is worthless as proof afterwards.

Signatures prove authorship to anyone, forever. MACs prove authorship only to someone who already holds the key, and only until the key is public. OTR chose MACs precisely because they make weaker promises. In a private conversation, the weaker promise is the correct one.

The socialist millionaires check

Version 2 of the protocol added a verification method that remains one of the more user-friendly ideas in applied cryptography. Comparing key fingerprints over the phone works, but most people never do it. OTR's alternative, the Socialist Millionaire Protocol, lets two people verify each other by answering a shared question.

The name comes from a variant of a classic puzzle: two millionaires want to learn whether they are equally rich without revealing their fortunes. The protocol lets two parties learn whether their secrets match without revealing the secrets. In OTR, you would pick something only the two of you know ("the name of the restaurant where we met") and both type the answer. If the answers match, the protocol confirms it and binds the result to the session keys. If they differ, each side learns only that they differ, and an active attacker in the middle learns nothing usable for a second attempt.

This is key verification for people who will never read a hex fingerprint, and it deserved more adoption than it got.

Why OTR faded

Through the late 2000s, OTR was the tool for encrypted chat. It shipped as a plugin for Pidgin, came built into Adium on the Mac, and rode on top of any messaging network the client supported, XMPP especially. Journalists and activists relied on it for years. Its limits were structural, and they became fatal when messaging moved to phones:

Both parties had to be online. The handshake and the DH ratchet assume a live, synchronous session. Mobile messaging is asynchronous by nature; your recipient's phone is in a pocket, offline, half the time.
No group conversations. The protocol is strictly pairwise. Group chat, where most real coordination happens, had no answer.
No multi-device story. An OTR session lives on one device. A phone and a laptop signed into the same account confused it badly enough that version 3 added instance tags just to keep parallel sessions from breaking each other.

The protocol that solved these problems is the one you are probably carrying right now. TextSecure, the app that became Signal, started from OTR's ratcheting idea and asked what it would take to make it work asynchronously. The answer involved precomputed key bundles fetched from a server (X3DH) and a two-part ratchet that can advance even when only one side is talking (the Double Ratchet). Signal's own protocol documentation credits OTR as the ancestor of its DH ratchet. The deniability goal survived the translation too: Signal authenticates messages without producing transferable cryptographic proof of authorship, the same property OTR pioneered, achieved with different machinery.

A fourth version of OTR was drafted in the late 2010s with modernized primitives, but by then the momentum belonged to Signal-descended protocols and to MLS for groups. OTR's libraries still exist and still work. Almost nobody starts a new project on them.

What OTR settled

Protocol design arguments rarely get settled this cleanly. OTR won three of them:

Claim (2004)	Status (2026)
Conversations need forward secrecy, so keys must be ephemeral and constantly rotated	Standard in Signal, WhatsApp, MLS (RFC 9420), TLS 1.3
Message authentication should not create durable proof of authorship	Deniable authentication is the default in modern messaging protocols
Long-term keys should authenticate, never encrypt content	Universal in modern protocol design

The 2004 paper's title argument also holds up. PGP remains the right tool where its properties fit: durable, storable, asynchronous messages to a known key, which is to say, email. It was never the right shape for conversation. The messaging world took OTR's path, and email encryption and conversation encryption evolved into different protocols for different jobs. Any tool that handles both has to hold both models at once, which is a design constraint we think about a great deal.

Originally published at havenmessenger.com

The Hotel Wifi Problem: What Actually Changes on a Shared Network

Haven Messenger — Wed, 15 Jul 2026 12:18:21 +0000

Most home networks put one household behind one router, with every device trusting every other device by default because they're all yours. Hotel, cafe, and conference wifi routes dozens or hundreds of unrelated devices through the same access point, often on the same subnet, frequently without client isolation enabled, because isolation breaks the casting and printing features guests expect to work.

What "same subnet" actually exposes

On a network without client isolation, devices can see each other's presence and, depending on configuration, respond to ARP requests that let another device on the segment quietly reroute your traffic through itself. This is the mechanism behind most "wifi hacking" demonstrations you'll see at security conferences: not breaking encryption, just sitting on the same local segment and asking, politely, in a protocol with no built-in authentication, to be treated as the gateway.

Captive portals compound this. The login page a hotel serves before granting internet access is, from a security standpoint, a piece of unauthenticated infrastructure your device trusts implicitly the moment it joins the network. A malicious actor on the same floor can stand up a nearly identical access point with a stronger signal, a technique generally called an evil twin, and a device set to auto-join known network names will connect to whichever signal is loudest without checking who's actually running it.

What TLS protects, and the part it doesn't

Once you're past the captive portal and on the real internet, HTTPS is doing real work: the content of your traffic to any TLS-protected site is encrypted end to end between your device and that site's server, regardless of who's watching the local network. That part of the picture is genuinely solid and has been for years.

What's still visible to someone on the same network, in most current deployments, is the domain name you're connecting to. The TLS handshake includes a field called Server Name Indication that tells the server which site you want, and by default that field goes out in cleartext before encryption is established. A newer extension, Encrypted Client Hello, closes this gap, but it requires support from both your browser and the site's hosting infrastructure, and as of 2026 that support is still inconsistent across the web. The practical result: someone on the hotel network can't read your banking session, but they can often see that you connected to your bank.

The metadata that survives encryption

Even with perfect TLS, a passive observer on a shared network can typically see: which domains you visited, roughly how much data you exchanged with each, and the timing pattern of your connections. None of that is your messages or your password. All of it is a usable behavioral fingerprint.

DNS is the other leak

Before your device can connect to anything, it resolves a domain name to an IP address, and by default that DNS query goes out in plaintext to whatever resolver the network's DHCP server handed your device, which on hotel and cafe networks is whatever the property's ISP configured, not one you chose. Every domain you visit gets logged by that resolver whether or not the connection that follows is encrypted. DNS over HTTPS and DNS over TLS close this specific gap by encrypting the query itself, and most modern browsers and operating systems support configuring a resolver manually, though it typically requires a deliberate setting change rather than being the default.

Where a VPN actually helps, and where it just moves the trust

A VPN wraps your entire connection, DNS queries included, in an encrypted tunnel to a server the VPN provider controls, before any of it touches the local network. That genuinely closes the local-network exposure: ARP tricks, evil twins watching your SNI, a curious DNS resolver, all of it becomes invisible to anyone else on the hotel's segment, because your traffic is opaque encrypted noise the moment it leaves your device.

What it doesn't do is make the exposure disappear. It relocates it to the VPN provider, who can now see the same domain and timing metadata the hotel network used to see. That's a real improvement if the local network is the specific threat you're worried about, business travelers on a conference room's wifi, journalists reporting from a hotel abroad, but it's not privacy in the abstract. It's a trade of one observer for a different one, and the VPN provider's jurisdiction, logging policy, and business model all become the relevant questions. We covered that trade-off in more depth in our VPN limitations piece.

Threat on shared wifi	What handles it
Message and password content exposure	TLS, already the default on most sites
Which sites you visited (SNI)	Partial: needs Encrypted Client Hello, or a VPN
DNS query logging by the local resolver	Encrypted DNS, or a VPN
ARP-based traffic redirection on the local segment	A VPN tunnel, since it bypasses the local segment entirely
Evil twin access points	Mostly you: verify the network name with staff, disable auto-join

The practical version

Turn off auto-join for open networks in your device settings, so you're not silently reconnecting to whatever signal is strongest. Confirm the network name with staff rather than trusting the strongest signal in the list. If the connection you care about matters, prefer a VPN over trusting the local network, and pick a provider whose logging policy you've actually read rather than the one that came free with your router. None of this requires new hardware or a security background. It requires treating a hotel's wifi the way you'd treat a hotel's phone line a generation ago: useful, functional, and not yours.

Originally published at havenmessenger.com

SecureDrop and the Architecture of Anonymous Whistleblowing

Haven Messenger — Tue, 14 Jul 2026 12:18:35 +0000

A contact form on a newsroom website is not an anonymous submission system, even with HTTPS. SecureDrop was built specifically for the case where the source's safety depends on the newsroom never learning who they are, and that requirement shapes every part of the design.

SecureDrop began as DeadDrop, a project started by Aaron Swartz and journalist Kevin Poulsen, and after Swartz's death in 2013 it was picked up and is now maintained by the Freedom of the Press Foundation. It's open source, and it's in use at dozens of newsrooms, including major outlets that need a way for sources with sensitive information, government employees, corporate insiders, people inside institutions with something to disclose, to make contact without a metadata trail leading back to them.

The threat model is specific and it's worth stating plainly: the goal isn't just to encrypt a message in transit. It's to make sure that even if the server hosting the system, or the newsroom's network, or a single compromised laptop, is seized or subpoenaed, there's nothing on it that identifies who sent what.

Onion services only, by design

A SecureDrop instance is reachable only as a Tor onion service. There's no clearnet URL, no fallback HTTPS address a source could accidentally use. This isn't an anonymity bonus layered on top; it's the entry point. Tor's onion routing means the SecureDrop server never sees the source's IP address, and the source's ISP never sees that they connected to a news organization's tip line. Newsrooms publish their onion address on their regular website, often alongside a warning to only access it through Tor Browser, ideally from a device and network not otherwise tied to the source's identity.

Why not just use encrypted email. PGP-encrypted email protects the message body, but the envelope, sender address, recipient address, timestamps, IP address at send time, is often visible to mail servers along the way and sometimes to the recipient's provider. A source using their personal or work email to contact a journalist has already created a durable record of contact, independent of what the message says.

Two-sided isolation: the source and the newsroom

When a source submits a message or document through the onion service, they're given a randomly generated codename, a pass phrase with no connection to their real identity, that lets them log back in later to check for a reply or submit follow-up material. No account creation, no email address, no username tied to anything outside the system.

On the newsroom side, journalists don't read submissions on the same machine that runs the server or that touches the regular internet. The recommended architecture uses three separate machines: an application server that receives submissions, a monitor server that watches for intrusion attempts, and an air-gapped viewing station, a computer that has never been and will never be connected to a network, used only to decrypt and read submissions with GPG keys that live on that machine alone. Files move to the air-gapped machine via a one-way USB transfer, specifically to avoid the viewing station ever touching a network where malware could exfiltrate what it decrypts.

Component	Purpose
Tor onion service	Hides the source's IP address and the fact that they contacted this newsroom at all.
Codename login	Lets a source check for replies without any persistent identifier tying sessions together.
Per-submission GPG encryption	Each submission is encrypted to the newsroom's public key before it leaves the browser session.
Air-gapped viewing station	Decryption happens on a machine that has never touched a network, closing the exfiltration path.
Tails OS (recommended for sources)	An amnesic operating system that leaves no trace on the machine it was booted from, reducing what a seized device could reveal.

What this design assumes, and what it doesn't protect against

SecureDrop's architecture assumes the server could be seized, subpoenaed, or compromised, and is built so that outcome still doesn't reveal a source's identity. What it can't do is protect a source who makes a mistake outside the system: logging in from a work computer, discussing the submission over an unencrypted channel beforehand, or being one of a small enough number of people with access to the leaked material that the leak itself narrows the suspect list regardless of how the tip was delivered. Every whistleblower guide built around SecureDrop spends as much time on operational discipline, which device, which network, who else knows, as on the tool itself, because the tool only protects the parts of the process it actually touches.

The reply mechanism, and why it's harder than it looks

A working tip system has to let a journalist ask a follow-up question without ever learning who they're asking. SecureDrop handles this by having the source generate their own codename at first contact and requiring them to remember it, since there's no password reset flow that wouldn't require some identifying recovery information. If a source loses their codename, that conversation thread is gone permanently. It's a real usability cost, and it's also the direct consequence of refusing to store anything that could re-identify a source later, including a recovery email address. Most consumer software treats "we can help you get back into your account" as a baseline feature. Here it's specifically the thing the design avoids, because a recovery path is also a re-identification path.

Newsrooms that run SecureDrop typically publish guidance alongside their onion address telling sources to use Tails, a live operating system that boots from a USB drive and leaves no trace on the host machine once it's shut down, rather than their normal, possibly monitored or logged, daily-use computer. That instruction matters more than it might seem: the strongest server-side architecture in the world doesn't help a source whose employer-issued laptop is already logging their browser history before Tor Browser ever opens.

Why the pattern matters beyond newsrooms

The core idea, minimize what's retained, assume the server will eventually be examined by someone hostile, and design so that examination reveals nothing useful, shows up anywhere a system needs to protect people who are taking a real risk to communicate: legal aid intake forms, corporate ethics hotlines with teeth, and human rights documentation projects all borrow pieces of the same architecture. It's a useful model to know even outside journalism, because it's a concrete answer to a question most software never asks: what happens to the people who used this if the server is compromised tomorrow.

Haven wasn't built as a SecureDrop replacement, and general-purpose messaging is a different threat model from anonymous source submission. But the same discipline, encrypting client-side before anything reaches a server, minimizing what the server retains, applies to journalists doing day-to-day reporting work even when the extreme isolation of an air-gapped drop box isn't warranted for the conversation at hand.

Originally published at havenmessenger.com

What's Actually Left on the Hard Drive You Sold

Haven Messenger — Mon, 13 Jul 2026 12:19:50 +0000

Deleting a file does not erase it. Formatting a drive does not erase it either. For over a decade, academic researchers have bought used hard drives from resale markets and consumer auction sites specifically to test this, and they keep finding the same thing: recoverable personal and financial data on drives their previous owners believed were clean.

When you delete a file on almost any consumer operating system, what actually happens is narrow: the file system stops pointing to the data and marks that space as available to be overwritten. The bytes on disk do not change. Until something else happens to be written to that same physical location, the original content is recoverable with off-the-shelf forensic software, no special access required, just the drive and a tool that anyone can download.

Formatting a drive through a standard operating system "quick format" does something similarly shallow: it rebuilds the file system's index structures but does not touch the underlying data blocks. A "full format" on some systems does more, but the terminology is inconsistent enough across Windows, macOS, and third-party disk utilities that most users cannot tell from the dialog box alone which one they are running.

What Researchers Keep Finding When They Buy Used Drives

This is not a theoretical risk. Since the mid-2000s, digital forensics researchers, notably a long-running study line out of the University of South Wales (previously the University of Glamorgan) led by Andy Jones and collaborators, have periodically purchased batches of used hard drives and USB storage from secondhand markets, resale auctions, and computer recyclers specifically to measure what remains recoverable. Across repeated rounds of this research published over more than a decade, a consistent share of the drives purchased contained recoverable personal data: financial records, personal correspondence, photographs, and in some rounds corporate or government data that should never have left an organization's control at all.

The pattern held across geographies and across years, which is the useful finding: this is not a one-time lapse by careless sellers, it is what happens by default when the disposal step of a device's life cycle is skipped or done wrong, and it happens often enough that researchers can reliably reproduce it by buying a batch of drives and checking.

The same forensic recoverability applies to more than spinning hard drives: USB flash drives, old phones, tablets, printers with internal storage for scanned documents, and smart home hubs with local caches all hold data past a factory reset unless the reset method specifically addresses the underlying storage, not just the user-facing settings.

Solid State Drives Are a Different, Harder Problem

SSDs complicate this further rather than simplifying it. Wear-leveling, the technique SSD controllers use to spread writes evenly across memory cells to extend the drive's lifespan, means a "delete" or even an overwrite command issued by the operating system does not necessarily touch the same physical cells the original data lived in. The controller may have already relocated that data elsewhere and left the original cells marked internally as stale but not zeroed. Traditional overwrite-based erasure methods, developed for spinning disks, are less reliable against this behavior on SSDs, which is part of why NIST's guidance treats SSDs and traditional hard drives differently rather than prescribing one method for both.

The Standard That Actually Defines "Erased"

The U.S. National Institute of Standards and Technology publishes the reference standard for media sanitization, NIST Special Publication 800-88. It defines three tiers, not one, because "erased" means different things depending on how much residual risk is acceptable.

NIST 800-88 tier	What it involves
Clear	Software-based overwrite of user-addressable storage, resistant to recovery via standard file recovery tools. Adequate for most personal and consumer disposal.
Purge	Techniques that address data even in areas not normally addressable, including a drive's own cryptographic erase command (if the drive supports full-disk encryption at the hardware level) or vendor-specific secure erase. Recommended before a drive leaves an organization's control entirely.
Destroy	Physical destruction: shredding, disintegration, or degaussing for magnetic media. The only tier with no residual recovery risk, at the cost of the drive being unusable afterward.

For most people selling or donating a personal laptop or phone, "Clear" done correctly, a full cryptographic wipe or several passes of a dedicated overwrite tool, not a quick format, is a reasonable bar. For a drive that held anything genuinely sensitive, financial records, health information, professional client data, "Purge" or physical destruction is the more defensible choice, and it is inexpensive: most consumer SSDs and modern hard drives support a built-in secure erase command that performs a cryptographic-level wipe in minutes.

The Easiest Fix Is Set Up Before the Drive Is Ever Sold

The single most effective mitigation is full-disk encryption enabled from the moment the device is first set up, not applied retroactively before resale. If a drive has been encrypted its entire operating life, discarding the encryption key, rather than overwriting the data itself, renders the ciphertext on disk unrecoverable in practice, because there is no plaintext version of the data to recover; only ciphertext remains, and without the key it does not decrypt. This is functionally equivalent to a cryptographic "Purge" and takes seconds instead of hours.

What to Actually Do Before You Sell, Donate, or Recycle a Device

Confirm full-disk encryption was on before you start (BitLocker, FileVault, or LUKS, depending on platform), not applied for the first time right before resale.
Use the manufacturer's built-in secure erase or cryptographic erase command rather than dragging files to the trash or running a quick format.
For phones and tablets, use the platform's official "erase all content" reset, which on modern iOS and Android devices is built on the same encrypted-storage principle, rather than a third-party "wipe" app of unknown provenance.
For anything that held financial, medical, legal, or client data, consider physical destruction over software erasure. A drive is inexpensive; the data on it may not be replaceable if it leaks.

Originally published at havenmessenger.com

Hybrid Post-Quantum TLS: How Your Browser Is Already Defending Against a Computer That Doesn't Exist Yet

Haven Messenger — Sun, 12 Jul 2026 12:19:11 +0000

A large quantum computer capable of running Shor's algorithm against the key sizes used on the internet today does not exist. The reason to care about post-quantum cryptography now anyway has a name: harvest now, decrypt later. An adversary with the resources to record encrypted traffic at scale, whether a state intelligence service or anyone with equivalent capability, can store today's TLS-encrypted connections and simply wait. If a cryptographically relevant quantum computer arrives in ten or twenty years, everything encrypted with a purely classical key exchange today becomes readable retroactively. Data with a long shelf life, medical records, legal communications, anything meant to stay private for decades, is exposed by that timeline even though the attack hasn't happened yet.

Why Hybrid, Not Pure Post-Quantum

The obvious fix is to switch TLS to a post-quantum key exchange algorithm and be done with it. Nobody serious is doing that yet, for a good reason: post-quantum algorithms are mathematically newer and less battle-tested than the elliptic curve cryptography they'd replace. ML-KEM, the algorithm NIST standardized in FIPS 203 in 2024 based on the CRYSTALS-Kyber submission, is built on lattice problems that have had far less adversarial scrutiny than the discrete-log problem underlying X25519 and other elliptic curve systems used today.

The deployed answer is a hybrid key exchange: run the classical algorithm (typically X25519) and the post-quantum algorithm (ML-KEM) side by side in the same handshake, and combine both resulting secrets into the final session key. Breaking the connection then requires breaking both algorithms, not just one. If ML-KEM turns out to have an undiscovered flaw, X25519 still holds the line; if a quantum computer eventually breaks X25519, ML-KEM still holds it. Security only improves, and it can't get worse than the classical baseline.

What's actually being combined
A hybrid handshake isn't ML-KEM replacing X25519, it's both running in parallel and their outputs being mixed together with a key derivation function, so an attacker has to defeat both independently to recover the session key.

What's Actually Running Today

Chrome enabled a hybrid key exchange combining X25519 and Kyber768 (now standardized as X25519MLKEM768) by default in 2024, meaning a large share of HTTPS connections from Chrome to a supporting server already negotiate post-quantum protection without any user action. Cloudflare has offered post-quantum hybrid key exchange across its edge network since 2022 and expanded default support to a large share of the domains it fronts. The IETF's TLS working group has been standardizing the codepoints for this in draft-ietf-tls-hybrid-design, giving different implementations a shared way to signal support for the same combination.

Messaging protocols moved on a parallel track. Signal added PQXDH, a post-quantum extension to its X3DH initial key agreement, in 2023, combining X25519 with CRYSTALS-Kyber for the first message exchange that establishes a conversation. Apple shipped PQ3 for iMessage in 2024, a post-quantum ratchet built for the same harvest-now-decrypt-later threat, independent of the TLS work happening at the browser and CDN layer.

The Size Cost of a Bigger Public Key

Nothing about this is free. A Kyber768 public key runs around 1,184 bytes, against roughly 32 bytes for an X25519 public key, so a hybrid handshake sends noticeably more data than a classical one. For a single web connection this is invisible, an extra kilobyte or so on a handshake that's already exchanging certificates. At the scale of a CDN handling billions of connections, or on a constrained network, the overhead is a real engineering line item, which is part of why adoption has rolled out gradually by provider rather than flipping on everywhere at once.

Component	Approximate public key size
X25519 (classical)	32 bytes
ML-KEM / Kyber768 (post-quantum)	~1,184 bytes

SSH Got There First

TLS and messaging apps get the attention, but OpenSSH quietly made the same move earlier and with less fanfare. OpenSSH 9.0, released in 2022, changed its default key exchange method to sntrup761x25519-sha512, a hybrid combining X25519 with Streamlined NTRU Prime, a post-quantum algorithm distinct from ML-KEM but built on a related lattice-based approach. Anyone running a current OpenSSH client or server has likely been using a hybrid post-quantum key exchange for every session since, without any configuration change, years before Chrome's rollout made headlines. WireGuard-adjacent projects like Rosenpass have pursued a similar hybrid approach for VPN key establishment. The pattern across all of these deployments is consistent: post-quantum protection arriving as a default upgrade to existing infrastructure, layered on top of classical cryptography rather than replacing it.

What's Not Fixed Yet: Certificates and Signatures

Everything above is about key exchange, the part of the handshake that establishes a shared secret. It says nothing about the signatures inside TLS certificates, which still rely on classical algorithms like RSA and ECDSA almost everywhere. NIST has also standardized post-quantum signature algorithms, ML-DSA and SLH-DSA among them, but migrating the certificate ecosystem is a much larger undertaking: certificate authorities, browsers, and every piece of software that validates a certificate chain all need to agree on new formats before it can roll out safely. Harvest-now-decrypt-later mainly threatens confidentiality, which is why key exchange moved first; signature migration protects authenticity, on a slower and separate timeline.

What This Means for You Right Now

If you're running a recent version of Chrome or Firefox and connecting to a site fronted by a CDN that supports it, some of your web traffic is already hybrid-protected without any setting to find or toggle. There's nothing to configure and nothing to verify manually in normal browsing. The more useful question to ask about any service handling sensitive, long-lived data isn't whether it has "quantum-proof encryption," a phrase that should read as a marketing flag on its own, but whether it's tracking the actual standards timeline and has a credible plan for the parts, like certificate signatures, that haven't moved yet.

The Timeline Nobody Can Pin Down

Estimates for when a cryptographically relevant quantum computer might exist range widely, and every serious estimate carries the caveat that it's a projection, not a schedule. What's not speculative is the data being harvested right now for a future decryption attempt, and the multi-year lag between "we should migrate" and "the migration is actually deployed everywhere it needs to be." Certificate authorities, hardware security modules, embedded devices, and legacy systems all move slower than a browser vendor pushing an update. What the hybrid approach actually buys is time: it lets the slow parts of the ecosystem start moving now, on a timeline decoupled from actually knowing when the threat becomes real.

Originally published at havenmessenger.com

The One-Time Pad: Provably Unbreakable, Almost Never Used

Haven Messenger — Sat, 11 Jul 2026 12:23:27 +0000

Every cipher in daily use, AES included, is secure in the practical sense: nobody currently knows how to break it with feasible amounts of computation. Exactly one scheme is secure in a stronger sense, with a mathematical proof that no amount of computation will ever break it. It was patented in 1917, the proof arrived in 1949, and cryptographers have spent the decades since deliberately not using it. The reasons why say a lot about what encryption actually has to solve.

The Whole Algorithm in One Paragraph

Take your message as a string of bits. Take a key that is a string of truly random bits, at least as long as the message. XOR them together, bit by bit. The result is the ciphertext. The recipient, holding an identical copy of the key, XORs the ciphertext with the key and gets the message back. Each key is used once and destroyed.

Gilbert Vernam, an engineer at AT&T, patented the electrical version of this in 1919 for teletype traffic. Joseph Mauborgne of the US Army Signal Corps added the requirement that makes it what it is: the key must be random and must never be reused. Hence the name. Spy services later distributed keys as printed pads of random digits, one sheet per message, torn off and burned after use.

What "Provably Unbreakable" Actually Means

Claude Shannon formalized the security of the one-time pad in his 1949 paper "Communication Theory of Secrecy Systems." The property he proved is called perfect secrecy: the ciphertext carries zero information about the plaintext. Formally, the probability of any given plaintext is the same after seeing the ciphertext as before.

The intuition is worth having. Suppose you intercept a 10-character ciphertext. For every possible 10-character message, there exists some key that decrypts the ciphertext to exactly that message. "ATTACK DAWN" is a candidate. So is "RETREAT NOW". So is your grandmother's soup recipe, truncated to ten characters. Since the key was chosen uniformly at random, all of those keys were equally likely, so all of those plaintexts remain equally plausible. Brute force does not merely take too long; it produces every possible message and no way to prefer one.

The catch, stated early: perfect secrecy requires a truly random key as long as the message, delivered to the recipient in advance over a channel you already trust, used once, and destroyed. Shannon also proved this is the cheapest perfect secrecy gets: any scheme with perfect secrecy needs at least as much key as message. The requirement is not an implementation detail. It is the price.

VENONA: What Cutting the Corner Costs

The proof holds only if every requirement holds, and the requirement that fails in practice is "never reuse." The best-documented failure is the VENONA project.

During the Second World War, Soviet intelligence services encrypted their cable traffic with one-time pads, which should have made it permanently unreadable. But wartime pressure on pad production led the manufacturers to duplicate some pad pages across different pad books. Starting in 1943, US Army codebreakers noticed the duplication, and the effect was devastating in slow motion: when two messages are encrypted with the same key, XORing the two ciphertexts together cancels the key entirely, leaving the XOR of the two plaintexts, which skilled analysts can pick apart using the statistics of language.

The VENONA cryptanalysts worked on that intercepted traffic for nearly four decades, eventually decrypting around three thousand messages. The results identified Klaus Fuchs's atomic espionage and figured centrally in the case against Julius Rosenberg. A cipher with a proof of unbreakability was defeated by its own logistics.

A one-time pad reused even once is not a weakened one-time pad. It is a different, breakable system that happens to look like one.

The Problem the Proof Cannot See: Key Distribution

Suppose you accept the discipline: real randomness, full-length keys, no reuse. You now face the question the one-time pad has no answer for. How does the key get to the other side?

You cannot send it over the network unencrypted, obviously. You cannot encrypt it with another one-time pad without needing to deliver that pad first, which restates the problem. What remains is physical delivery: couriers, diplomatic bags, an in-person meeting before any communication happens. That works for embassies and it famously worked for the Moscow-Washington hotline established in 1963, which used one-time tapes delivered through each side's embassy. It does not work for messaging someone you have never met, which is nearly everyone you communicate with online.

Notice the shape of the trade modern cryptography made instead. A scheme like AES-256 uses a short key, 32 bytes, for gigabytes of traffic, and key agreement protocols based on Diffie-Hellman let two parties who have never met establish that key over a hostile network. The price is that security becomes computational rather than absolute: it rests on problems believed, not proven, to be hard. Cryptographers took that deal because a slightly weaker guarantee you can actually deploy protects more people than a perfect guarantee you cannot.

Two More Quiet Weaknesses

No integrity. The one-time pad hides content and does nothing else. An attacker who cannot read your message can still modify it with surgical precision, because flipping bit n of the ciphertext flips exactly bit n of the decrypted plaintext. If the attacker knows your message format, "pay 100" becomes "pay 900" without any decryption. Modern systems pair encryption with authentication for exactly this reason; see authenticated encryption and HMAC.

Randomness is harder than it looks. The proof requires the key bits to be uniformly random. Keys from a pseudorandom generator seeded with a short secret give you a stream cipher, not a one-time pad, and the perfect-secrecy proof no longer applies. Producing large volumes of high-quality randomness is its own engineering discipline; secure randomness is where a lot of systems get this wrong.

The Marketing Red Flag

The phrase "one-time pad" survives mostly in two places today: cryptography courses, and the marketing of products that do not contain one. A product that claims one-time-pad encryption over the internet, with no explanation of how pads longer than your total traffic were exchanged in advance, is describing a stream cipher with a famous name attached. Some vendors go further and generate the "pad" from a small seed, which abandons the entire point.

The test is the key-material accounting. If the secret material exchanged in advance is smaller than the data protected, whatever the system is, it is not a one-time pad, and its security is computational like everyone else's. That is not necessarily bad engineering. Well-built computational cryptography is what protects essentially everything today, including this page in transit. What should lower your trust is a vendor either not knowing the difference or hoping you do not.

Why It Still Matters

The one-time pad earns its place in every cryptography curriculum because it marks the boundary of the possible. It answers, precisely, the question "what would it cost to have encryption that no adversary, ever, with any computer, can break?" The answer is: a secure channel that carries one key bit for every message bit, which is nearly the thing you were trying to build. Everything else in cryptography is the study of what you can get for less.

Originally published at havenmessenger.com

TLS Interception: How Corporate Proxies Read Your Encrypted Traffic

Haven Messenger — Thu, 09 Jul 2026 12:20:53 +0000

The padlock in your browser tells you the connection is encrypted. It does not tell you who is on the other end of that encryption. On millions of corporate and school devices, the answer is a middlebox in the IT department, decrypting and re-encrypting every HTTPS request before it ever reaches the real website.

TLS interception, sometimes sold as "SSL inspection" or "HTTPS filtering," is a standard feature in enterprise security products. Firewalls and secure web gateways from most major vendors ship with it. The stated purpose is reasonable on its face: malware arrives over HTTPS too, and a filter that cannot see inside encrypted traffic cannot scan it.

What the feature actually does is run a man-in-the-middle attack against every user behind it, with permission from the device owner rather than the person typing. Understanding the mechanics matters, because the same trick shows up in contexts far less benign than a corporate firewall.

How the interception actually works

TLS normally prevents interception because the server proves its identity with a certificate signed by a certificate authority your browser already trusts. A proxy sitting in the middle cannot present a valid certificate for your bank's hostname, so the connection fails.

Enterprise interception solves this by changing the trust store, not by breaking the cryptography. The steps:

The organization generates its own private root CA and installs it in the trust store of every managed device, usually through mobile device management or Group Policy.
The proxy terminates your TLS connection and reads the hostname you asked for.
It mints a fresh certificate for that hostname on the fly, signed by the corporate root, and presents it to your browser.
Your browser sees a certificate chain ending in a trusted root and shows the padlock.
The proxy opens its own separate TLS connection to the real server and shuttles data between the two, inspecting everything in between.

From the browser's point of view, nothing is wrong. The cryptography on each leg is intact. What changed is that "end-to-end" now ends at the proxy, and everything you send, including passwords, medical searches, and private messages sent over webmail, is plaintext at that point.

The core distinction: TLS interception does not break encryption. It relocates the endpoint. Your traffic is encrypted to the proxy, and separately from the proxy to the site. The proxy itself sees plaintext, logs whatever it is configured to log, and retains it under whatever policy the organization chose.

The security cost is measurable, not theoretical

A middlebox that terminates TLS also negotiates TLS on your behalf, and it rarely does it as well as your browser would. A 2017 study presented at NDSS, "The Security Impact of HTTPS Interception" by researchers from Mozilla, Google, Cloudflare, and several universities, measured intercepted connections at scale and found that the majority negotiated weaker cryptography than the client originally offered. Some middleboxes accepted broken cipher suites, skipped certificate validation entirely, or advertised support for TLS versions with known attacks.

The finding was serious enough that US-CERT issued alert TA17-075A the same year, warning organizations that HTTPS inspection products "may weaken the protections that TLS is intended to provide" and urging them to verify what their middleboxes actually do with upstream certificates.

The consumer-side version of this failure had already made headlines. In 2015, Lenovo shipped laptops with Superfish adware that installed a root CA to inject ads into HTTPS pages. Every affected laptop carried the same root CA private key, and it was extracted within days of discovery. Anyone on the same network could then impersonate any website to any Superfish-infected machine. The certificate that made ads possible made banking fraud possible too.

When the "enterprise" is a government

The technique scales past companies. In 2019, and again in 2020, Kazakhstan instructed citizens to install a government-issued "national security certificate" as a condition of internet access in parts of the country. With that root installed, the state could intercept HTTPS traffic to any site it chose. Browser vendors responded by hard-blocking the certificate: Chrome, Firefox, and Safari all shipped explicit blacklist entries so the certificate would not validate even if a user installed it.

That vendor response is worth noticing. The browser makers treated a government-mandated root CA as an attack, because structurally it is one. The only difference between "SSL inspection" and mass surveillance is who controls the root key and what they do with the plaintext.

How to tell whether your connection is intercepted

On a device you own but did not fully configure, such as a work laptop, checking takes under a minute:

Inspect the certificate issuer. Click the padlock on any HTTPS site and view the certificate chain. If the root is your employer's name, or a security vendor's product name, rather than a public CA like Let's Encrypt or DigiCert, your traffic is being intercepted.
Compare across networks. Load the same site on the corporate network and on your phone's mobile data. A different issuing CA on the corporate network is the tell.
Watch for pinning failures. Applications that use certificate pinning refuse to accept the proxy's substitute certificate. If a specific app fails on the office network but works everywhere else, interception is the usual cause. Many enterprise proxies keep a bypass list for exactly these apps.

Note what does not help here: Certificate Transparency only covers certificates from public CAs, so a corporate root minting certificates locally never appears in any CT log.

What interception means for your actual privacy

On a managed device, assume the organization can read anything you do in a browser, including your personal webmail, your bank session, and any "private" browsing window. Private browsing prevents local history storage; it does nothing about a proxy that sees plaintext.

What you use	What an intercepting proxy sees
Webmail over HTTPS	Full message contents, both directions
Banking session	Credentials and transactions, unless the app pins certificates
End-to-end encrypted messenger	Metadata and traffic patterns only; message contents stay encrypted because the keys never touch the proxy
VPN from the device	Often blocked or forced through the proxy; on managed devices the VPN itself is visible to the administrator

The messenger row is the important one. End-to-end encryption is the one design that survives TLS interception, because TLS is only the outer layer. A proxy that terminates TLS on an end-to-end encrypted connection gets ciphertext it cannot decrypt, since the message keys live on the endpoints, not in the transport. That is precisely the property end-to-end encryption exists to provide: the network, including a hostile or nosy network, is not trusted.

The practical rules

Three habits cover most of the risk:

Treat managed devices as observed. Do personal things on personal hardware, on a network you chose.
Never install a root certificate someone hands you unless you accept that they can read all your TLS traffic from that point on. That is what the install means, whatever the stated reason.
For anything that must stay private, use end-to-end encryption rather than relying on transport encryption, because you generally cannot verify who terminates TLS on someone else's network.

TLS interception is legal on hardware the interceptor owns, and in regulated industries it is sometimes mandatory. None of that changes the engineering fact: a connection is only as private as its least trustworthy endpoint, and interception quietly adds one you did not pick.

Originally published at havenmessenger.com

SLSA Explained: The Levels That Prove Where Your Software Came From

Haven Messenger — Tue, 07 Jul 2026 12:19:20 +0000

In the SolarWinds attack, the malicious code was not smuggled past code review or slipped into the source repository. It was injected during the build, after the trusted source was compiled and before it was signed. The result was a poisoned update that carried a valid signature from a company nobody had reason to doubt. SLSA exists because that class of attack showed the industry that trusting the source and trusting the artifact are two different things.

SLSA stands for Supply-chain Levels for Software Artifacts, and it is pronounced "salsa." It began at Google, drawing on that company's internal build-integrity practices, and is now maintained as an open project under the Open Source Security Foundation. Its purpose is narrow and useful: to give a common vocabulary for how much you can trust the way a piece of software was built, and to define concrete, checkable levels that raise that trust step by step.

The framework is worth understanding because most of the supply-chain defenses people already know sit somewhere else in the pipeline. A software bill of materials tells you what went into a build. Code signing tells you who released the result. Reproducible builds let you check that source produces the expected binary. SLSA addresses a gap those leave open: whether the build process itself can be trusted, and whether there is tamper-evident evidence of how the artifact was actually produced.

Provenance is the core idea

The central concept in SLSA is provenance. Provenance is a signed statement, generated by the build system, that records how an artifact came to exist: what source commit it was built from, what build steps ran, what builder produced it, and what the resulting artifact's cryptographic hash is. If you have trustworthy provenance, you can check that the binary in front of you really did come from the commit you audited, built by the system you expected, and was not swapped or altered afterward.

SLSA expresses provenance using the in-toto attestation format, a standard way of writing signed claims about software artifacts. The attestation is the evidence. The SLSA levels are graded largely by how hard that evidence is to forge, which in turn depends on how the build platform is run.

The shift in trust: Signing answers "who published this." Provenance answers "how was this actually built, from what, and by whom." An attacker who compromises the build step can still get a valid signature. Provenance is designed to make that tampering visible.

The build track levels

The current version of SLSA organizes its requirements into a Build track with three ascending levels, on top of a Level 0 that simply means no guarantees. Each level adds a requirement that closes off a category of attack. The higher you go, the less an attacker who controls part of the pipeline can lie about what happened.

Level	What it requires	What it defends against
L0	No requirements	Nothing. The baseline.
L1	Provenance exists and is distributed with the artifact	Mistakes and casual tampering; makes build metadata available to verify
L2	Provenance is signed and generated by a hosted build platform	Forged provenance from a developer's own machine; ties evidence to a build service
L3	The build runs on a hardened platform with strong isolation, so provenance is non-forgeable even by the build's own steps	A compromised build script tampering with its own provenance or reaching other builds

The jump that matters most is from Level 1 to Level 3. At Level 1, provenance exists, but a developer could in principle generate a plausible-looking attestation by hand. At Level 2, the provenance is signed by a hosted build service, so it is tied to a system rather than an individual laptop. At Level 3, the build platform is hardened so that the steps running inside a build cannot forge their own provenance or interfere with other builds. That isolation is what would have made the SolarWinds-style injection detectable, because the tampering would have contradicted the recorded provenance.

What SLSA deliberately does not cover

SLSA is careful about its own scope, and that honesty is part of what makes it usable. The current Build track does not, by itself, guarantee that the source code is free of malicious commits, that dependencies are safe, or that the developers are trustworthy. A project can reach a high build level and still ship a vulnerability that was in the source all along. Work on a separate source track, covering how code enters the repository, has been developing alongside the build track but is a distinct concern.

This is why SLSA is best understood as one instrument in a set rather than a single score for supply-chain safety. It pairs naturally with dependency scanning, with a bill of materials for what went in, and with reproducible builds so a third party can independently confirm the binary matches the source. Together those give you both a record of how something was built and a way to check that record against reality.

A signature tells you the door was locked by someone with a key. Provenance tells you what happened inside the room. After SolarWinds, the industry decided it needed both.

Why this matters beyond big companies

It is tempting to file supply-chain frameworks under enterprise compliance and move on. That misses the point for anyone who depends on software they did not write, which is everyone. The open-source libraries inside your messaging app, your password manager, and your operating system all pass through build pipelines, and a compromise at that layer reaches every user of the finished product regardless of how careful they personally are. Supply-chain attacks against privacy software are attractive precisely because they bypass the user entirely.

For a security-focused project, the practical takeaway is to build in a way that produces verifiable provenance and to publish enough that an outsider can check the chain from source to artifact. That is the same instinct behind open source and reproducible builds: reduce how much anyone has to take on faith. The more of the path from source to running code that can be independently verified, the less any single point in the pipeline has to be trusted blindly.

Originally published at havenmessenger.com

Wi-Fi Sensing: Your Router Is Becoming a Motion Detector

Haven Messenger — Sun, 05 Jul 2026 12:21:11 +0000

Every Wi-Fi transmission arrives at the receiver as a mess of overlapping reflections. The signal bounces off walls, furniture, and people, and each path arrives with slightly different timing and strength. Wi-Fi chipsets measure this constantly, in a data structure called channel state information (CSI), because they need it to decode the transmission correctly.

A human body is mostly water, and water absorbs and reflects 2.4 GHz and 5 GHz radio energy. When a person moves through a room, the pattern of reflections shifts in a measurable, characteristic way. Wi-Fi sensing is the practice of reading those shifts deliberately: not to decode data, but to infer what is physically happening in the space the signal passes through.

What the research has demonstrated

Academic groups have been publishing on this for over a decade, and the results go well past simple motion detection. Using commodity Wi-Fi hardware, researchers have demonstrated presence detection through interior walls, gesture recognition, fall detection, and respiration monitoring from the tiny periodic movement of a chest rising and falling. In 2023, researchers at Carnegie Mellon published work showing that signals from ordinary Wi-Fi routers, processed with a neural network, could estimate full human body poses in a room.

The person being sensed carries nothing. There is no app to decline, no permission dialog, no MAC address to randomize. The sensing target is the body itself, and the sensor is the ambient radio environment. None of the usual device-tracking defenses apply here.

Why encryption does not help: Wi-Fi sensing operates at the physical layer. It reads how the radio wave was distorted in flight, not what data the wave carried. A network running WPA3 with perfect key hygiene is exactly as usable for sensing as an open one. There is no cryptographic defense against a capability that never touches the payload.

This is shipping, not speculative

Wi-Fi sensing left the lab years ago. Comcast ships a feature called WiFi Motion that turns Xfinity gateways into whole-home motion detectors. Standalone products such as Origin Wireless's Hex Home sell Wi-Fi sensing as a security system: a few plug-in pods, no cameras, motion alerts derived entirely from signal analysis. Router and chipset vendors market sensing as a value-add for elder care, sleep tracking, and intrusion detection.

The IEEE has been working since 2020 on 802.11bf, an amendment that standardizes how Wi-Fi devices coordinate and exchange sensing measurements. Standardization matters because it moves sensing from a proprietary trick in a few products to an interoperable capability across the installed base. Once client devices, access points, and mesh nodes can all participate in coordinated sensing sessions, the resolution improves and the deployment cost drops to zero: the hardware is already in the walls.

The bystander problem

The person who buys a Wi-Fi sensing product at least made a choice. The people around them did not. Radio does not respect property lines: a sensing-capable access point in one apartment receives reflections from the unit next door. A guest in a home with WiFi Motion enabled is being motion-tracked without any notice. A landlord who controls the building's mesh network controls a building-wide presence sensor.

There is no consent mechanism in the protocol, and it is hard to imagine what one would look like. You cannot opt your body out of reflecting radio waves. The closest legal analogue is Kyllo v. United States, the 2001 Supreme Court case holding that police use of a thermal imager to observe activity inside a home was a search requiring a warrant. The reasoning turned partly on thermal imagers not being "in general public use." Wi-Fi sensing inverts that premise: the sensing hardware is the most widely deployed radio equipment in human history.

Law enforcement interest follows capability. Utility records, license plate readers, and geofence warrants all became routine investigative tools once the data existed. If ISP-managed gateways log motion events, those logs are held by a third party and reachable with legal process: data that exists gets requested.

What you can actually do

The individual mitigations here are thinner than we would like, and it is worth being clear about that rather than padding the list.

Know what your gateway is running. If your router is ISP-managed, check whether motion or sensing features exist in the account settings and whether they are on by default. Comcast's WiFi Motion, for example, is opt-in and can be turned off.
Prefer hardware you control. A router you own, running firmware you chose, does not ship sensing features you never agreed to.
Reduce always-on radios where they serve no purpose. Fewer active transmitters means a coarser sensing picture. Wired backhaul for stationary devices helps at the margin.
Treat this as a policy problem. The durable fixes are regulatory: notice requirements for sensing features, warrant requirements for sensing-derived data, and privacy review inside the 802.11bf process itself. Individual workarounds do not scale to a capability embedded in the ambient infrastructure.

The wider pattern

Wi-Fi sensing belongs to a family of techniques that extract surveillance value from infrastructure built for something else: ultrasonic beacons riding on speakers, Van Eck emanations leaking from displays, timing side channels in shared hardware. The pattern is consistent. A signal deployed for a benign purpose turns out to carry more information than its designers intended, and the extraction cost falls every year.

What makes Wi-Fi sensing distinctive is scale. There are billions of compatible transmitters already installed, in nearly every home, office, and public building. The question is no longer whether the capability exists. It is who gets to use it, against whom, with what notice, and under what legal standard. Those questions are being settled now, mostly in standards meetings and product launches, while almost nobody outside the industry is watching.

Originally published at havenmessenger.com