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 teor):

 Replying to [comment:6 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 descriptor is only accepted after one hour when the
 descriptor expires.

 The Tor onion service should do one or more of these things:
 * fetch and validate its own descriptor, and then use the revision counter
 in that descriptor to pick a higher revision counter
 * on failure, retry uploading with a higher revision counter (but that
 places a lot of load on the network if the revision counter is high)
 * keep the last revision counter in a state file, and use it to choose a
 higher revision counter (this doesn't have to be a huge disk leak, because
 you only need one number: the highest revision counter for the entire
 instance - but it does leak some state)

 > 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.

 No, it's a bug in Tor.

 > 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.

 I doubt we'll expose this feature, we'll fix the bug instead.

 > ---
 >
 > 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.

 It's not something Stem needs to handle.

 If you want Tor to generate your key blob, use "NEW:ED25519-V3", rather
 than "ED25519-V3:" KeyBlob
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1516
 Then Tor will tell you what the blob is, and you can store it, and feed it
 back next time.

 The blob is intentionally opaque: if you insist on creating your own key
 blob, it's something you will have to handle yourself:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1618

 > 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.

 Blinding is implemented in Tor, using this algorithm:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n652

 At some point in the future, Tor may support offline key blinding for v3
 onion services:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n540

 When it does, it will probably be implemented like offline ed25519 relay
 keys.

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