Re: [tor-dev] Exposing onion service errors to Tor Browser
d...@foundingdocuments.org: > 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' ? AFAIK this proposal has nothing to do with changing the Tor onion service protocol; it's solely related to conveying errors to the user that the Tor daemon used by Tor Browser already has access to. The security properties of onion services can't be changed by this -- if they could be, then this would be security by obscurity, which is a scam that the Tor devs (and any other legitimate software developers) don't engage in. Cheers, -- -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmob...@airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jer...@veclabs.net is having technical issues at the moment. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Exposing onion service errors to Tor Browser
> On Sep 30, 2019, at 8:15am, George Kadianakis 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
Re: [tor-dev] HSv3 descriptor work in stem
>Can I use `_descriptor_content()` to do that? Or should I call >`_descriptor_content()` to generate the whole thing _without_ the >sig, and then do the signature computation on its result and >concatenate it after? Hi George. Yup, to create a signed descriptor we create the bulk of the content then append the signature. Server and extrainfo descriptors already do this so I suspect you can do something similar... https://gitweb.torproject.org/stem.git/tree/stem/descriptor/server_descriptor.py#n902 https://gitweb.torproject.org/stem.git/tree/stem/descriptor/__init__.py#n1388 Will this do the trick? PS. Sorry about the duplicate. Hit reply rather than reply-all forgetting that you included the list. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Optimistic SOCKS Data
On Fri, Sep 27, 2019 at 1:35 PM Tom Ritter wrote: > > On Mon, 5 Aug 2019 at 18:33, Tom Ritter wrote: > > > > On Tue, 2 Jul 2019 at 09:23, Tom Ritter wrote: > > > Or... something else? Very interested in what David/asn think since > > > they worked on #30382 ... > > > > I never updated this thread after discussing with people on irc. > > > > So the implementation of > > SOCKS-error-code-for-an-Onion-Service-needs-auth implementation is > > done. David (if I'm summarizing correctly) felt that the SOCKS Error > > code approach may not be the best choice given our desire for > > optimistic data; but felt it was up to the Tor Browser team to decide. > > > > In the goal of something that works for 90%+ of use case today, the > > rest later, I'll propose the following: > > > > In little-t tor, detect if we're connecting to an onion site, and if > > so do not early-report SOCKS connection. > > > > Another ugly option is to early-report a successful SOCKS connection > > even for onion sites, and if we later receive an auth request, send an > > HTTP error code like 407 that we then detect over in the browser and > > use to prompt the user. I don't like this because it is considerably > > more work (I expect), horrible ugly layering violations, and I don't > > think it will work for https://onion links. > > I attached an updated proposal taking this into account, and I'd like > to request it be entered into torspec's proposals list. Okay! This is now proposal 309. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] HSv3 descriptor work in stem
Hello atagar,
I'm starting this thread to ask you questions about stem and the HSv3
work we've been doing over email so that we don't do it over IRC.
Here is an initial question:
I'm working on HSv3 descriptor encoding, and I'm trying to understand
how `_descriptor_content()` works. In particular, I want to compute the
signature of a descriptor, but I see that `descriptor_content()`
fills it with random bytes in all the `content()` methods I managed
to find:
('signature', _random_crypto_blob('SIGNATURE')),
What's the right way to compute the signature for such objects? In
particular, I would need a method that first generates the whole
descriptor body, and then computes the signature of that with a given
private key.
Can I use `_descriptor_content()` to do that? Or should I call
`_descriptor_content()` to generate the whole thing _without_ the
sig, and then do the signature computation on its result and
concatenate it after?
Thanks! :)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
