#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs