#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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
