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

[Tor Bug Tracker & Wiki]

#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:
--------------------------+------------------------------------
Changes (by dgoulet):

 * status:  new => needs_information
 * milestone:  Tor: 0.3.5.x-final => Tor: unspecified


Comment:

 Replying to [ticket:27896 jchevali]:
 > There seems to be some base32 padding tolerance inconsistency between
 client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
 >
 > The server seems to accept base32-encoded client public keys padded with
 = signs to 56 characters in length and won't work otherwise (i.e., if =
 signs are removed).

 I don't think that is accurate. Service side we explicitly do not allow
 padded base32. If the client key line is not equal to the *no padding*
 length, we don't accept.

 {{{
   if (strlen(pubkey_b32) != BASE32_NOPAD_LEN(CURVE25519_PUBKEY_LEN)) {
     log_warn(LD_REND, "Client authorization encoded base32 public key "
                       "length is invalid: %s", pubkey_b32);
     goto err;
   }
 }}}

 > while the client would work without the padding (i.e., = signs removed)
 but will ignore the client's private key if the padding is present.

 And the client code does exactly the same:

 {{{
   if (strlen(seckey_b32) != BASE32_NOPAD_LEN(CURVE25519_PUBKEY_LEN)) {
     log_warn(LD_REND, "Client authorization encoded base32 private key "
                       "length is invalid: %s", seckey_b32);
     goto err;
   }
 }}}

 >
 > I don't think this affects how the feature works (which I haven't been
 able to test anyway because it doesn't seem to enforce authorization at
 this stage - it still seems to let everyone in), but at least it seems to
 affect which values are valid and allowed to be loaded when reading the
 config.

 Can you explain how you came down to this conclusion? And also, why are
 you saying it is "not enforced"? If the service is configured to use
 client authorization and a client is configured for it, it should NOT let
 everyone go through.

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