[tor-bugs] #27896 [Core Tor/Tor]: base32 padding inconsistency between client and server in HS v3 client auth preview

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Oct 19 21:21:10 UTC 2018


#27896: base32 padding inconsistency between client and server in HS v3 client auth
preview
--------------------------+------------------------------------
 Reporter:  jchevali      |          Owner:  (none)
     Type:  defect        |         Status:  needs_information
 Priority:  Medium        |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by jchevali):

 So we have one server (described in comment 4) that does not crash on
 unpadded .auth file entries, but might be generating invalid descriptors
 (unless they're valid and it's the client's fault -- by the way, the
 client I have at the moment is on Win32 and slightly older version at
 tor-0.3.5.2-alpha).  This server is not where Tor was build; it was copied
 over from another server, just the executables (some libraries external to
 Tor might be different versions, though Tor doesn't complain at run time).

 And we have another server, where the build was done originally (described
 in comment 5) that does crash on unpadded .auth file entries, but perhaps
 that's not because of lack of padding, but something else.  Perhaps in
 this server the assertion is hit and in the other isn't.  By the way, I
 can only wonder what'd happen if this assertion wasn't hit (i.e., would it
 also lead to uploading invalid descriptors?  I don't know.)

 Conversely, perhaps this later server isn't exhibiting any symptoms in the
 case I give it padded .auth file entries.  But in this case possibly it is
 not setting up any HS client-side authentication at all either.  That'd
 explain why the client can connect: maybe not a failure of the HS v3
 authentication mechanism, but simply that, silently, for the padded .auth
 file case authentication isn't actually set up.  While I originally
 thought that in this case the server was working successfully and the
 client was failing (by being able to connect when it shouldn't have),
 perhaps it's the reverse: the server's silently failing to set up
 authentication and publishing descriptors that would let everyone in, and
 the client of course connects.

 Does it make sense?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27896#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list