[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