[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):
It's funny; I'm testing this on two servers that are using the same
tor-0.3.5.3-alpha build (though not the same version of Debian).
One server is causing the problem I described an hour ago, but only at the
client side. There seem to be no problem at the server side, and it seems
to accept unpadded pk descriptors.
The other server however is not accepting unpadded descriptors, only
padded descriptors, as per my original bug submission, i.e., it would
accept this:
{{{
descriptor:x25519:LSHKYRU3WPY3QW6HZWET6UW4IKU2WZXRWAVVZZVGR2NROXJ3WQZQ====
}}}
(which as you see is the same as the contents in my previous bug comment,
only with padding)
If I give it an unpadded pk descriptor in the .auth file, with the same
exact content I gave the other server, it would crash like this (part what
I originally called 'padding intolerance'):
{{{
tor_assertion_failed_(): Bug: src/feature/hs/hs_descriptor.c:2897:
hs_desc_build_authorized_client:
Assertion !tor_mem_is_zero((char *) descriptor_cookie,
HS_DESC_DESCRIPTOR_COOKIE_LEN) failed; aborting.
Bug: Assertion !tor_mem_is_zero((char *) descriptor_cookie,
HS_DESC_DESCRIPTOR_COOKIE_LEN) failed in
hs_desc_build_authorized_client at
src/feature/hs/hs_descriptor.c:2897. Stack trace:
Bug: ./tor(log_backtrace_impl+0x47) [0x5644802aa7d7]
Bug: ./tor(tor_assertion_failed_+0x93) [0x5644802a5e63]
Bug: ./tor(hs_desc_build_authorized_client+0x2c7) [0x5644801b99a7]
Bug: ./tor(+0x1026e0) [0x5644801bb6e0]
Bug: ./tor(hs_service_load_all_keys+0x7c0) [0x5644801bf580]
Bug: ./tor(set_options+0xe0a) [0x564480229c2a]
Bug: ./tor(options_init_from_string+0x4c7) [0x56448022b997]
Bug: ./tor(options_init_from_torrc+0x471) [0x56448022bef1]
Bug: ./tor(+0x53d61) [0x56448010cd61]
Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)
[0x7fe103a85a6c]
Bug: /usr/lib/x86_64-linux-
gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fe103a86537]
Bug: ./tor(do_main_loop+0x91) [0x564480121241]
Bug: ./tor(tor_run_main+0x1373) [0x56448010f1b3]
Bug: ./tor(tor_main+0x3a) [0x56448010c61a]
Bug: ./tor(main+0x19) [0x56448010c179]
Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
[0x7fe1029c9b45]
Bug: ./tor(+0x531c9) [0x56448010c1c9]
}}}
If I use the padded version, then the server would not crash, however, the
client will be able to connect to the HS -- which shouldn't be the case,
because the client hasn't been given any private key to match that (it
doesn't matter if I give the client under the form of .auth_private files
private keys for unrelated services, or no private keys / no files at
all).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27896#comment:5>
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