Building Prizrak: How a Developer Created a Federated Messenger That Masks All Traffic as Legitimate HTTPS

A developer created Prizrak, a federated messenger with end-to-end encryption where all traffic, including calls, is indistinguishable from ordinary HTTPS connections. The project addresses three common limitations of existing messengers: centralized control points, mandatory phone numbers, and detectable encrypted traffic. It uses real TLS 1.3 handshakes to actual domains, multi-port listening, and a hidden token mechanism inside the encrypted channel. When servers cannot reach each other directly, messages are delivered through a network of storage nodes modeled after Ceph's RADOS system. Voice and video calls run on a native media stack with custom STUN-like functionality and careful UDP buffer sizing to avoid packet truncation. An integrated two-hop VPN reuses the same stealth transport while keeping messenger traffic outside the tunnel.

HabrTranslated from Russian

Read at source

A developer has built Prizrak, a federated messenger that uses end-to-end encryption and makes all traffic, including voice and video calls, appear as ordinary HTTPS connections on the wire.

The project began because existing messengers could not be configured to remove three persistent problems: a central point that can be shut down, mandatory phone number registration, and traffic that remains identifiable even when encrypted. Prizrak uses identifiers in the form name:domain, OpenPGP long-term keys for identity, X3DH and Double Ratchet for forward secrecy, and ChaCha20-Poly1305 for encryption. Federation occurs between independent homeservers that locate each other automatically.

Transport designed to resist DPI

The developer discovered that perfect encryption is useless if the first bytes of a packet reveal the protocol. Standard WebRTC calls expose the STUN magic cookie 0x2112A442 and DTLS record type 22. The solution was to stop imitating HTTPS and instead become it: clients perform genuine TLS 1.3 handshakes to real domains and present a hidden token only after the channel is encrypted. Servers listen on multiple stable ports including 443, 8801, 993 and others, silently ignoring occupied ones. Clients start at port 443 and discover a working port automatically.

Key management and multi-device support

Long-term OpenPGP keys serve as identity passports verified via QR code and sign ephemeral X25519 prekeys. Each device receives its own identity key signed by the account root. Messages are encrypted separately for every device of the recipient. Revoking a device simply stops delivering envelopes to it. The design accepts O(participants × devices) encryption cost and plans to adopt MLS (RFC 9420) for very large groups.

Resilient delivery through storage nodes

When homeservers cannot reach each other directly, messages travel through a network of storage nodes. Each node stores opaque blobs addressed by HKDF-derived identifiers. The system replicates data across four nodes using a placement model taken from Ceph RADOS, including rendezvous hashing, Merkle reconciliation, and anti-entropy. Delivery acknowledgments are the only source of truth; nodes delete blobs only after receiving a signed ACK.

Native media stack and careful buffer sizing

Calls use a fully native media stack on Android with Camera2, MediaCodec, AudioRecord and Opus. A custom address-mapping service replaces public STUN to avoid detectable signatures. After switching to direct P2P paths, video frames were being truncated because the receive buffer was only 2048 bytes. Raising the buffer to 65536 bytes, adding proper fragmentation, and implementing PLI-based recovery eliminated artifacts. Bitrate is now controlled by queue length rather than observed loss.

Ringback tones and call-state machine

Users complained that calls lacked ringback tones. The developer added a full state machine that reports presence after an offer is sent, distinguishes “subscriber unavailable,” “busy,” and “no answer” conditions, and plays 425 Hz tones with familiar cadences. The same work exposed several signaling bugs that had previously gone unnoticed.

Built-in two-hop VPN

The stealth transport is reused for a two-hop VPN. The first hop sees the user’s IP but not the destination; the exit hop sees the destination but not the user. Messenger traffic is excluded from the tunnel to avoid loops. Node selection uses Bayesian reputation with 60-day freshness and make-before-break switching.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Privacy & Surveillance

Maximizing iPhone Privacy: Essential Settings to Enable, Disable, and Verify Immediately
Top 10 Secure DNS Servers for Privacy, Threat Blocking and Ad Filtering in 2026
WebRTC IP Leaks Explained: Why Disabling the Protocol Harms Anonymity in Anti-Detect Browsers