[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Hidden Service authorization UI

I'm probably missing significant Tor development history here, but section 5.2 of theÂtor design paperÂmentions using the domain format x.y.onion where x is used for authorization and y.onion is used for actual the actual addressing. I'm not sure if this idea was ever actually taken any further, but this seems preferable to the UI flow you're talking about and might mean that TBB doesn't have to be updated at all! The concerns I can see are 1) potentially caching the authorization component in the history and 2) essentially disallowing sub-domains for hidden services [this is a minor problem since if hidden services want the security benefits of single-origin policyÂseparationÂthey can just do what facebook did and have aÂseparateÂonion addresses.] Upstreaming this into the tor daemon would also allow any application to address authenticated hidden services easily instead of just TBB.
On Sun Nov 09 2014 at 12:21:01 PM Garrett Robinson <garrett@xxxxxxxxxxxxx> wrote:
SecureDrop (and former Firefox) dev here. A few months ago I started
working on a patch to support prompting users for an authenticated
hidden service cookie in the manner of HTTP Basic Auth. [0] We require
journalists who use SecureDrop to download submissions from an
authenticated Tor hidden service, and bootstrapping that for them is
currently a major UX pain point. [1]

The main difficulty was that there was not a clear way to communicate
the HidServAuth info to the Tor Browser's running Tor process. AFAICT,
that is not currently supported in the Tor control protocol. So an
extension to the Tor control would be useful here. It would also be
possible to edit the torrc, reload Tor, and have the TB wait for that,
but that is a) incredibly ugly and b) probably prone to causing all
kinds of fun problems. Haven't tried it yet.

> How would Tor Browser learn about this reason for not being able to
connect/
> tell Tor the authentication info? This is starting to sound like
> wanting SOCKS5 extensions to indicate different causes for
> connection failures in #6031 did.

My current patch waits for a connection timeout on a .onion, then offers
a tab-modal prompt that says "A connection to a Tor Hidden Service
failed. If you are trying to connect to an authenticated Tor hidden
service, enter your authentication string below:". A SOCKS5 extension
would be even better, to avoid annoying users who mistype onion's or who
are trying to access an onion that is down. I included a "Don't ask
again" checkbox but it would probably still be annoying.

Would be interested in hearing ideas about how hard it would be to
extend the control protocol and add a SOCKS5 extension for connection
failures, and if anybody is already working in those directions. I'll
try to return to this patch when I have time in the coming weeks.

[0] https://trac.torproject.org/projects/tor/ticket/8000
[1]
https://github.com/freedomofpress/securedrop/blob/develop/tails_files/README.md

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev