Re: [tor-bugs] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

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

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---------------------------+--------------------------------
 Reporter:  dmr            |          Owner:  dmr
     Type:  enhancement    |         Status:  needs_revision
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  client         |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:  atagar         |        Sponsor:
---------------------------+--------------------------------

Comment (by atagar):

 > Limitation 1: dropping multiplexed cells or (worse) throwing exceptions
 when they occur
 > ...
 > My proposed solution to this for stem is to centralize ORPort reads -
 separating that from more specific handlers.

 Hi Dave. Gotcha, Tor's control socket is multiplexed to some extent too.
 General controller interactions are serialized, but asynchronous events
 can be interweaved with content we receive.

 Stem handles this via its stem.control.BaseController class, which wraps
 our socket and provides thread safe communication through its msg()
 method.

 My plan for ORPorts is to do the same. Like BaseController, our
 stem.client.Relay class wraps the socket. It, and the Circuit class it's
 collocated with, is the spot where we'll be implementing all IO.
 Multiplexing included.

 By contrast our Cells are IO agnostic parsers. We'll likely adjust them a
 bit when we add multiplexing, but I'd expect the bulk of such a patch to
 be there.

 > Limitation 2: having unpack()/pop() methods that effectively won't work
 on the stream of data received from a guard, if there's any
 RELAY/RELAY_EARLY cells in there

 Sorry, read this a few times and still unsure what you mean by
 'interpreting' cells. That said, the next bullet is probably more
 important.

 > Limitation 3: allowing only a single layer of decryption, instead of an
 arbitrary number of layers

 Ahh! Gotcha. That's definitely something we need to address, though I
 suspect it won't be overly challenging. First thought is maybe we can
 extend our new encrypt/decrypt methods to take a series of key/digests.
 Side stepping digests for simplicity, that is to say...

 {{{
 def encrypt(self, keys):
   if isinstance(keys, list):
     # Encrypt for each relay, last to first...
     #
     #   Circuit: Us => Relay #1 (Guard) => Relay #2 (Middle) => Relay #3
 (Exit) => Endpoint
     #     Cell to send:   [Header for relay #1][Encrypted payload for
 relay #1]
     #     Payload for #1: [Header for relay #2][Encrypted payload for
 relay #2]
     #     Payload for #2: [Header for relay #3][Encrypted payload for
 relay #3]
     #     Payload for #3: [Payload for endpoint]

     cell_to_send = self

     for relay_key in reversed(keys):
       cell_to_send = cell_to_send.encrypt(relay_key)

     return cell_to_send
   else:
     # Encrypting for a single hop.

     [ something similar to our present encryption method ]

 def decrypt(self, content, keys):
   if isinstance(keys, list):
     decrypted_cell = self

     for relay_key in reversed(keys):
       decrypted_cell.decrypt(relay_key)

       if decrypted_cell.recognized == 0 and [digest check thingy]:
         return decrypted_cell  # cell is now fully decrypted

     raise stem.ProtocolError('Cell received from X couldn't be fully
 decrypted')
   else:
     # Decrypt for a single hop.

     [ something similar to our present decryption method ]
 }}}

 Just pulling from my ass. No doubt naively ignoring complications, but I'm
 sure with a little work we can come up with an elegant and functional
 solution that makes us both happy.

 What I'd like from you isn't anticipatory refactoring, but rather a
 functional prototype that makes multi-hop circuits. Once we have something
 that **works** we can iterate on the code, but until then we're both just
 guessing.

 Cheers! -Damian

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27112#comment:11>
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