Re: [tor-dev] Exposing onion service errors to Tor Browser

["Drew@xxxxxxxxxxxxxxxxxxxxx" <Drew@xxxxxxxxxxxxxxxxxxxxx>]

> On Sep 30, 2019, at 8:15am, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
> 
> Hello list,
> 
> we've recently been thinking about how to expose onion-service-related
> errors to Tor Browser so that we can give more useful error pages to
> users.  We currently return "Unable to connect" error pages for any kind
> of onion service error, and I think we can do better.


Hello,

In doing a quick read of [1] X'F0' to X'F5’  it looks like most might describe potential day-to-day connections, but I’m not sure about the last two: X'F4' Onion Service Missing Client Authorization  & X'F5' Onion Service Wrong Client Authorization.

Please forgive me if I misunderstand things, but I thought leaked v3.onion addresses with (properly set up) authorized onion services (authorized_clients/*.auth & corresponding client-side .auth_private) can’t be loaded. Thus providing instant, inexpensive DOS protection, and denying the malevolent (and anyone) the opportunity to even know a specific onion address is in use. And keeping them from trying again later, and again, etc.

I am definitely in favor of feedback and clear error reporting, but I am not clear about how these authorization-only onion services will be affected. 

Is tor going to be changed such that unauthorized clients -- clients without a proper .auth_private file -- are going to be able to learn if a specific .onion domain is in use? Will the local tor inform the user that in effect that onion address is in use but perhaps X'F4' or X'F5' ?



[1] Extending SOCKS5 Onion Service Error Codes, https://gitweb.torproject.org/torspec.git/tree/proposals/304-socks5-extending-hs-error-codes.txt   Lines 62-93.

[2] Tor Rendezvous Specification - Version 3, https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt, First Appendix F & Appendix G. Using file system means, not control ports. 



> = Client-level errors =
> === 1) Typo error on address ===
> 
>    This can be detected by Tor using the checksum or if the address is
>    too big or too small.
> 
>    TODO: We will need to add a new error code to prop304. Not sure if
>    the error code should distinguish between checksum fail or length fail.
> 
>    There is no recovery here since the address is busted. The user
>    needs to find the right one.

There is an opportunity here for at least a tiny amount of education about onion addresses.  Perhaps copy the address to the page in an edit box and use JavaScript to help the user to fix it up? Perhaps a non base32 character got in. Maybe they didn’t paste in the whole address but missed part of it. 

I would suggest a few simple graphics and sentences explaining the vast address space of v3 onions, with a fun simple time calculation perhaps, to show how one would not want to try all the variations that might exist on a “misspelled” .onion address.


Thank you and have a nice day. 
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev