Re: [tor-bugs] #31369 [Core Tor/Stem]: HSv3 descriptor support in stem [decoding]

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

#31369: HSv3 descriptor support in stem [decoding]
-----------------------------------------+--------------------------------
 Reporter:  asn                          |          Owner:  atagar
     Type:  defect                       |         Status:  reopened
 Priority:  Medium                       |      Milestone:
Component:  Core Tor/Stem                |        Version:
 Severity:  Normal                       |     Resolution:
 Keywords:  tor-hs onionbalance scaling  |  Actual Points:  2.5
Parent ID:  #26768                       |         Points:  4
 Reviewer:                               |        Sponsor:  Sponsor27-must
-----------------------------------------+--------------------------------

Comment (by atagar):

 Perfect, thanks asn!

 > But yes, IMO we should have a generic certificate validate (or verify?)
 function that just verifies that the certificate correctly signs the
 included key using the intended public key

 Agreed. Thought I just had: lets use isinstance checks here. That is to
 say...

 {{{
 def validate(self, descriptor):
   if isinstance(descriptor,
 stem.descriptor.server_descriptor.RelayDescriptor):
     # server descriptor specific things
   elif isinstance(descriptor,
 stem.descriptor.hidden_service.HiddenServiceDescriptorV3):
     # hidden service specific things
   else:
     raise ValueError('ED25519 certificate validation only presently
 supports server and hidden service descriptors, not %s' %
 type(descriptor).__name__)
 }}}

 > Great! I see that you have disabled the checksum verification but this
 actually passes for me.

 Interesting! Yes, likely is a pysha3 vs python 3.6 difference. I'll look
 into it.

 > Would you be interested in digging more there; that is parsing the
 middle and inner layers of the descriptor?

 Yup! At this point I should have everything I need to run with this. Many
 thanks asn!

 Give me a bit and hopefully I'll have a mergeable branch for you to take a
 peek at.

 > In the meanwhile, I will be working on the encoding part, if you don't
 think that's too chaotic to do.

 Nope. Feel free, but I won't be able to give much significant thought to
 it until this end is wrapped up.

 > Commit 14a44b1c6e1438abdf5687a1c468536d88481f81 killed a few XXXs I had
 added to remind myself in the future (so that we don't forget them before
 merging).

 If that's the case would you mind this before encoding so we can get this
 branch into a mergeable state?

 To be clear at this point my plan is...

 1. Productionize hsv3_crypto.py. This will probably include some
 refactoring.
 2. Add parsing support for the other layers.
 3. Unit test decryption and parsing.
 4. Consider merging the branch.

 If there's any additional verifications we'd care to get in prior to
 merging it would be preferable (but not a big whoop) to get them in during
 this.

 > FYI the encoding methods will also need an extra argument during
 descriptor encoding

 Gotcha. That's perfectly fine. Descriptor creation can take additional
 arguments. For example server_descriptor.py has...

 {{{
 def content(cls, attr = None, exclude = (), sign = False, signing_key =
 None, exit_policy = None):
 }}}

 > BTW, any plans on putting this stuff into github so that I can do some
 inline comments?

 Not at present. I use my personal TPO repo for in flight branches (GitHub
 is simply a mirror of the official repo). That said, I'm leaning toward
 migrating to GitHub when the rest of tor moves to GitLab so in the future
 I'll likely fully be on that platform.

 > I'm splitting this ticket into two.

 Perfect! Thanks.

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