On Sep 30, 2019, at 8:15am, George Kadianakis desnacked@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-extendin... 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.