[tor-bugs] #26092 [Obfuscation/Snowflake]: Split broker into components

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#26092: Split broker into components
---------------------------------------+--------------------
     Reporter:  dcf                    |      Owner:  (none)
         Type:  project                |     Status:  new
     Priority:  Low                    |  Milestone:
    Component:  Obfuscation/Snowflake  |    Version:
     Severity:  Normal                 |   Keywords:
Actual Points:                         |  Parent ID:
       Points:                         |   Reviewer:
      Sponsor:                         |
---------------------------------------+--------------------
 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 (#25594, #25874), 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 (#22945), 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
 [https://gitweb.torproject.org/flashproxy.git/tree/facilitator/doc
 /facilitator-design.txt?id=0c5ea1b04c4725fccc5a98a25bede5c419e07fcd
 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)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26092>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs