[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #27896 [Core Tor/Tor]: base32 padding inconsistency between client and server in HS v3 client auth preview
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs