[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
Wed Nov 14 14:13:49 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: 0.4.0.x-final
Component: Core Tor/Tor | Version: Tor: 0.3.5.1-alpha
Severity: Normal | Resolution:
Keywords: tor-hs, hs-auth | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------+------------------------------------
Comment (by jchevali):
Several issues have been mentioned in this ticket, but I'd like to give a
bit of graphical expression to the issue I described 'formally' in comment
nÂș 8.
There are in my view two ways in which a given Tor service security lines
can fail to be understood. When the whole line can't be understood, and
when only the key part can't be understood, but the rest of the line can.
So suppose we have an {{{.auth}}} file server-side under
{{{authorized_clients}}} some of whose lines are properly formed up to the
second colon ("{{{descriptor:x25519:}}}"), but not any further.
For example, this case we came up recently, which is invalid because the
key is hex, not base32. However, the intention was clearly here to set up
security:
{{{
descriptor:x25519:5c8eac469bb3f1b85bc7cd893f52dc42a9ab66f1b02b5ce6a68e9b175d3bb433
}}}
Or the case at the centre of this ticket, where the client key is base32
but has padding, which currently makes it invalid:
{{{
descriptor:x25519:OM7TGIVRYMY6PFX6GAC6ATRTA5U6WW6U7A4ZNHQDI6OVL52XVV2Q====
}}}
A further could be a key that someone wrongly pastes, e.g., someone could
paste just part of the string, maybe missing only one digit, or by mistake
paste it with a space in it:
{{{
descriptor:x25519:OM7TGIVRYMY6PFX6GAC6ATRTA5U6WW6U7A4ZNHQDI6OVL52XVV2
}}}
or
{{{
descriptor:x25519: OM7TGIVRYMY6PFX6GAC6ATRTA5U6WW6U7A4ZNHQDI6OVL52XVV2Q
}}}
My argument is that in these cases, security for the hidden service in
question should still be activated, and if the only keys that are present
can't be parsed (all of them), then no one should be allowed in.
Because we currently deal with the case when there are keys and some are
valid, which we handle fine (the valid ones will take effect and the
invalid are ignored), and when there are altogether no valid lines
(security for the service overall won't be activated). But we might be
failing to handle the intermediate case: when security is defined but the
key parsing (and only that) fails (for all keys found, be that just one or
more than one). In that case we should throw away the unparseable keys,
but not throw away the fact that security has been defined for the service
(by way of an {{{.auth}}} file in the right place and apparently legal
except for the keys). In this case, overall security for the service
should be turned ''on'', and access for anybody trying to access it turned
''off''.
Because the alternative is that if someone tries to set up security for a
service and doesn't get it exactly right, his service will be wide open.
And he won't notice this fault, perhaps, because his clients will have
access. He'll think his clients will have access by virtue of the keys
given, but in fact they'll have access because everybody will have access.
That can be very dangerous.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27896#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list