Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • S Snowflake
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 93
    • Issues 93
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 14
    • Merge requests 14
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • Pluggable Transports
  • Snowflake
  • Issues
  • #26092

Split broker into components

This is my idea for breaking the broker into a few parts, instead of being a monolithic executable. The rationale is:

  • With additional rendezvous methods (legacy/trac#25594 (moved), legacy/trac#25874 (moved)), it will be nice to have a separate process per method, which can be restarted independently of the others and only has to manage its own listener.
  • With encrypted registrations (legacy/trac#22945 (moved)), it will be nice if the process holding the private key is not the same process that exposes a lot of attack surface in the form of HTTP servers, DNS servers, etc.

I propose having the broker in three components:

  1. The core broker database process, which matches client registrations with proxies. Only listens on localhost. Only handles plaintext.
  2. A decryption and signing oracle process. This is the only component that has access to the private key. Listens only on localhost. Receives encrypted registrations from the rendezvous processes, decrypts them, and passes them on to the core broker process.
  3. Registration method processes. These are the only components that listen externally. They take encrypted client registrations over HTTPS, DNS, or whatever, and pass them to the decryption oracle which passes them to the broker. Gets back signed proxy answers and passes them back to the client. There doesn't have to be strictly one process per registration method; for example the HTTPS POST and [ticket:25985 AMP Cache] are similar enough that they can be handled together. It might be better (simpler) to have components 1 and 2 in the same process--the broker logic is pretty simple so there's not much added risk in having it with private key.

We used a similar architecture in flash proxy; see facilitator-design.txt:

  1. facilitator (later renamed fp-facilitator)
  2. facilitator-reg-daemon (later renamed fp-reg-decryptd)
  3. facilitator.cgi for HTTP and facilitator-email-poller for SMTP (later renamed fp-registrar.cgi and fp-registrar-email)
Assignee
Assign to
Time tracking