Skip to content

How is traffic attribution managed?

Attribution is the question of who can tell that this traffic came from your organisation? Waveshift's answer is: nobody on the path, by design. Each observer along the route sees a different, narrow slice — and none of them can stitch the slices back together without privileged access inside the customer's AWS account.

Attribution management — what each observer sees on the path

The three observers

  • Local ISP (the bearer) sees only a UDP/51820 flow to one AWS public IP (the Egress Server's ingress proxy). The payload is ChaCha20-Poly1305 ciphertext — no SNI, no DNS lookups, no HTTPS metadata.
  • Destination website sees a standard HTTPS request from the Egress Server's public IP. No Waveshift headers, no injected fingerprint, no shared CDN identifier.
  • AWS-inside view (only available to operators with IAM access to the customer's account) sees Site identity per peer and the cleartext routing decision. Peer private keys live in the orchestrator's PostgreSQL database; each Egress Server's own private key never leaves the instance (only its public key is published, via SSM Parameter Store).

The three views are deliberately disjoint. The ISP can't see the destination; the destination can't see the user; and the AWS-inside view requires credentials the customer controls.

See also