Re: [tor-bugs] #25124 [Core Tor/Stem]: Stem v3 Onion Service support

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

#25124: Stem v3 Onion Service support
---------------------------+-----------------------------------
 Reporter:  Dbryrtfbcbhgf  |          Owner:  atagar
     Type:  defect         |         Status:  needs_information
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-----------------------------------

Comment (by maqp):

 Glad to hear you're feeling better atagar! Hi everyone,

 So the bug is related to applications where the Onion Service uses
 persistent key but where the service goes online and offline frequently.
 Examples of those include file transmission applications like OnionShare,
 and instant messaging like Ricochet or TFC (that I'm working on).

 During development I noticed that by re-using a few times the same long
 term v3 ED25519 private key (passed to
 controller.create_ephemeral_hidden_service), would cause Stem to raise

 stem.OperationFailed(message = 'Failed to upload our hidden service
 descriptor to %s' % ', '.join(failures)) stem.OperationFailed: Failed to
 upload our hidden service descriptor to
 F4263275CF54A6836EE7BD527B1328836A6F06E1 (UPLOAD_REJECTED)... <followed by
 rest of directory services>

 I started to investigate this: I doubled delay between launched services,
 and at the point of one hour, the UPLOAD_REJECTED stopped happening.
 Example code and output here:
 https://gist.github.com/maqp/4817a4d1e71a27536ab9810d75e7b6c1

 The issue happens even with latest Stem dev build that includes
 https://gitweb.torproject.org/stem.git/commit/?id=53e73ad

 Now this is a problem with the applications that are online for short
 periods at a time. Say the computer or client crashes at start. User
 shouldn't have to wait for an hour before they can relaunch the software.

 ---

 I have only skimmed Tor's source code and documentation, but it is my
 understanding that the descriptor is uploaded with something called the
 revision counter. From what I've read I've understood those mean that
 descriptor for same service can be uploaded frequently if the bundled
 revision counter is incremented every time. If the revision counter is not
 incremented, new descritor is only accepted after one hour when the
 descriptor expires.

 I'm using Tor 0.3.3.2-alpha (that should support v3 Onion Services), so
 I'd assume the revision counter update not happening automatically is
 related to feature not yet in Stem.

 On a side note, if Stem indeed needs to manage persistent revision
 counter, it would be very helpful if developers could access them via
 something like response.rev_counter and provide them as arguments to
 create_ephemeral_hidden_service, kind of like how persistent keys can be
 provided.

 ---

 The last thing I'd like to understand is the key expansion and blinding.
 The private key's expansion function in the Gist I posted above was
 modified from Tor's testing code. It works but I'm not sure if developers
 should be doing all that: It's probably something Stem should handle, at
 least with some helper function.

 Related to this is the key blinding aspect. It is my understanding the
 Onion site crawling has been solved by uploading blinded (sub?)keys inside
 the descriptor. It is not at all clear whether this is the job of
 application developers, Stem, or Tor 0.3.3.

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