[tor-dev] Hidden Service authorization UI

[Vlad Tsyrklevich]

I'm probably missing significant Tor development history here, but section
5.2 of the tor design paper
<http://www.onion-router.net/Publications/tor-design.pdf> 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 at freedom.press>
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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141109/2e083c0d/attachment.html>