Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
S
Snowflake
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 46
    • Issues 46
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 4
    • Merge Requests 4
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
    • A
      Anti-censorship
  • Pluggable Transports
  • Snowflake
  • Issues
  • #22945

Closed
Open
Opened Jul 15, 2017 by David Fifield@dcfOwner

End-to-end confidentiality for Snowflake client registrations

Client requests sent to the /client broker endpoint use TLS to the front domain, and TLS from the front to the broker, but the fronting service itself (e.g. App Engine) can inspect them in plaintext. The fronting service unavoidably gets to learn the IP addresses of clients, but we could encrypt the additional metadata that appears in the registration messages.

I was thinking of giving the broker a private key and wrapping client registrations in a NaCl box.

This is roughly how it worked in flash proxy. The facilitator had a private RSA key, and client registration methods were encrypted before being posted to the facilitator. https://gitweb.torproject.org/flashproxy.git/tree/facilitator/facilitator.cgi?id=1.4#n60 The actual key material was isolated into a facilitator-reg-daemon process that was separated from the web server and facilitator CGI: https://gitweb.torproject.org/flashproxy.git/tree/facilitator/facilitator-reg-daemon?id=1.4

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/anti-censorship/pluggable-transports/snowflake#22945