Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • P pluggable transports
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 5
    • Issues 5
    • List
    • Boards
    • Service Desk
    • Milestones
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • Pluggable Transports
  • pluggable transports
  • Issues
  • #14038
Closed
Open
Issue created Dec 28, 2014 by Philipp Winter@phw

Fix ScrambleSuit's replay protection

ScrambleSuit uses Uniform Diffie-Hellman as one of its authentication mechanisms. To defend against replay attacks, a sever caches the HMAC of a client's authentication message.

The attack works as follows. In the first step, an active adversary (e.g., a censor trying to detect ScrambleSuit) observes a client authenticate successfully towards a ScrambleSuit server and captures the server's Uniform Diffie-Hellman response. In the second step, the adversary replays the captured response to the very same server. Since the server did not cache the HMAC of its own response, it will interpret the replayed data as legitimate authentication message of a new client and respond with an authentication response. The adversary now successfully tricked the server into responding despite not knowing the shared secret. This creates a noteworthy distinguisher which can help identifying ScrambleSuit.

Luckily, it's easy to fix this problem. Introducing message types would be one option but it would break backwards compatibility. The easiest fix which retains backwards compatibility is to make the server also cache its own HMACs which are part of the response to a client's authentication message. The downside is that it doubles the size of the replay table but that's tolerable.

Note that obfs4 is not affected by this problem because a client's and a server's authentication message are different.

A patch follows in a minute.

Assignee
Assign to
Time tracking