> On Sep 30, 2019, at 8:15am, George Kadianakis <desnac...@riseup.net> 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
