Hidden Service authorization UI
Hidden Service authorization is a pretty obscure feature of HSes, that can be quite useful for small-to-medium HSes. Basically, it allows client access control during the introduction step. If the client doesn't prove itself, the Hidden Service will not poroceed to the rendezvous step. This allows HS operators to block access in a lower level than the application-layer. It also prevents guard discovery attacks since the HS will not show up in the rendezvous. It's also a way for current HSes to hide their address and list of IPs from the HSDirs (we get this for free in rend-spec-ng.txt). In the current HS implementation there are two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt#l768 both have different threat models. In the future "Next Generation Hidden Services" specification there are again two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec... One way is with a password and the other is with a public key. I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people. For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file. Furthermore on the server-side, like meejah recently suggested [0], it would be nice if there was a way for HSes to be able to dynamically add/remove authorized clients using the control port. [0]: https://lists.torproject.org/pipermail/tor-dev/2014-October/007693.html
So most of my work over the next three days is writing and editing documentation on hidden services. I'm in Boston and the purpose of this trip is to rewrite existing documentation to be more useful, but with authenticated hidden services, what's available is extremely sparse. GlobaLeaks and SecureDrop have good authenticated hidden service setups (and good use cases for them). A friend of mine uses an authenticated HS for his personal cloud. More secure for him than logging into DropBox, etc. So they're also useful for mere mortals like us. ;-) Is there something you need/want in terms of documentation. best, Griffin PS: yes I'm aware of the hilarious timing of this trip. On November 9, 2014 7:50:00 AM EST, George Kadianakis <desnacked@riseup.net> wrote:
Hidden Service authorization is a pretty obscure feature of HSes, that can be quite useful for small-to-medium HSes.
Basically, it allows client access control during the introduction step. If the client doesn't prove itself, the Hidden Service will not poroceed to the rendezvous step.
This allows HS operators to block access in a lower level than the application-layer. It also prevents guard discovery attacks since the HS will not show up in the rendezvous. It's also a way for current HSes to hide their address and list of IPs from the HSDirs (we get this for free in rend-spec-ng.txt).
In the current HS implementation there are two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt#l768 both have different threat models.
In the future "Next Generation Hidden Services" specification there are again two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec... One way is with a password and the other is with a public key.
I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people.
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file.
Furthermore on the server-side, like meejah recently suggested [0], it would be nice if there was a way for HSes to be able to dynamically add/remove authorized clients using the control port.
[0]: https://lists.torproject.org/pipermail/tor-dev/2014-October/007693.html _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, Nov 09, 2014 at 08:18:40AM -0500, Griffin Boyce wrote:
So most of my work over the next three days is writing and editing documentation on hidden services.
I'm in Boston and the purpose of this trip is to rewrite existing documentation to be more useful, but with authenticated hidden services, what's available is extremely sparse. GlobaLeaks and SecureDrop have good authenticated hidden service setups (and good use cases for them). A friend of mine uses an authenticated HS for his personal cloud. More secure for him than logging into DropBox, etc. So they're also useful for mere mortals like us. ;-)
Is there something you need/want in terms of documentation.
best, Griffin
PS: yes I'm aware of the hilarious timing of this trip.
No particular suggestions to offer on documentation, but 'hilarious' may actually be 'good', since for situations like this where an HS doesn't need to be open to the general public, it denies attackers the ability to cause the HS to produce traffic on demand and thus probably makes it more resistant to any HS exploits that may have been involved in recent events. -- Andrea Shepard <andrea@torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5
On Sun, Nov 09, 2014 at 12:50:00PM +0000, George Kadianakis wrote:
I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people.
Yes, HS authoritzation is rare. It's rare enough that it was broken for a whole series of releases and no one noticed or complained. That sucks and it should be used more because it probably does help resist attacks for a large category of use cases.
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file.
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. -- Andrea Shepard <andrea@torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5
On Sun, 9 Nov 2014 16:19:24 +0000 Andrea Shepard <andrea@torproject.org> wrote:
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.
Well prop 229 is on my todo list, though it's not very high up. The last time I spoke to people about this, it seemed like a nice to have but not massively important sort of thing, but I'd be more than happy to rearrange things in that department. Especially as my tenative plans for obfsng (aka obfs6 depending on how long it gets stuck in design and deployment) involves 1 KiB keys... Regards, -- Yawning Angel
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...
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@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
In the future "Next Generation Hidden Services" specification there are again two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec... One way is with a password and the other is with a public key.
A {shared secret,key} and a user specific onion?
I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people.
I've used this feature extensively. I love it.
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file.
That sounds interesting. All the best, Jacob
On 11/9/14 8:58 PM, Jacob Appelbaum wrote:
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file. That sounds interesting.
Also i love this idea but i would suggest to preserve the copy&paste self-authenticated URL property of TorHS, also in presence of authorization. It could be done with a parameter in the URL http://blahblah.onion/?authTorHBauBauMeowMeow=PASSWORD Or it could be done with a URL handler httpA://PASSWORD@blahblah.onion . That way it will be possible to use such authenticated TorHS by bookmarking an URL in TBB or by copy/pasting it from a password manager. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org - http://ahmia.fi
On Sun, Nov 9, 2014 at 3:30 PM, Fabio Pietrosanti - lists <lists@infosecurity.ch> wrote:
On 11/9/14 8:58 PM, Jacob Appelbaum wrote:
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file. That sounds interesting.
Also i love this idea but i would suggest to preserve the copy&paste self-authenticated URL property of TorHS, also in presence of authorization.
It could be done with a parameter in the URL http://blahblah.onion/?authTorHBauBauMeowMeow=PASSWORD Or it could be done with a URL handler httpA://PASSWORD@blahblah.onion .
That way it will be possible to use such authenticated TorHS by bookmarking an URL in TBB or by copy/pasting it from a password manager.
This assumes you're using a Tor aware browser, or Tor is somehow protocol aware and MITM for all user protocols (such as TLS non-web) which is impossible. So this won't work. Any such descriptor authenticating would need done at the onion 'hostname' level since that's the only non-user-protocol area available. ie: authtoken.16char.onion. Or in torrc as is today.
On 2014-11-09 15:30, Fabio Pietrosanti - lists wrote:
On 11/9/14 8:58 PM, Jacob Appelbaum wrote:
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file. That sounds interesting.
Also i love this idea but i would suggest to preserve the copy&paste self-authenticated URL property of TorHS, also in presence of authorization.
I'm conflicted about this idea. Much better for usability ~but~ there should be an option for authenticated hidden services that want to *not* prompt and instead fail silently if the key isn't in the torrc (or x.y.onion url, depending on the design). Use case: if someone finds my hidden service url written in my planner while traveling across the border, they might visit it to see what it contains. If it offers a prompt, then they know it exists and can press me for the auth key (perhaps with an M4 carbine). If there's no prompt and the request fails, then perhaps it "used to exist" a long time ago, or I wrote down an example URL. best, Griffin -- "I believe that usability is a security concern; systems that do not pay close attention to the human interaction factors involved risk failing to provide security by failing to attract users." ~Len Sassaman
On Sun, Nov 09, 2014 at 09:16:40PM -0500, Griffin Boyce wrote:
On 2014-11-09 15:30, Fabio Pietrosanti - lists wrote:
On 11/9/14 8:58 PM, Jacob Appelbaum wrote:
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file. That sounds interesting.
Also i love this idea but i would suggest to preserve the copy&paste self-authenticated URL property of TorHS, also in presence of authorization.
I'm conflicted about this idea. Much better for usability ~but~ there should be an option for authenticated hidden services that want to *not* prompt and instead fail silently if the key isn't in the torrc (or x.y.onion url, depending on the design).
Use case: if someone finds my hidden service url written in my planner while traveling across the border, they might visit it to see what it contains. If it offers a prompt, then they know it exists and can press me for the auth key (perhaps with an M4 carbine). If there's no prompt and the request fails, then perhaps it "used to exist" a long time ago, or I wrote down an example URL.
best, Griffin
I believe it's verifiable whether an authenticated HS exists anyway; you can get the descriptor, but the list of intro points is encrypted. -- Andrea Shepard <andrea@torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5
It is verifiable. In authenticated hidden services, the introduction points are first encrypted and then base64 encoded. So a simple test is: When base64 decoded, is the MSB bit set on any bytes ? If yes, then it's probably authenticated, otherwise not. Note, you can use the Tor research framework to fetch any hidden service descriptor, it will even parse the document and pull out the IP text. Best Gareth On 10 November 2014 07:42, Andrea Shepard <andrea@torproject.org> wrote:
On Sun, Nov 09, 2014 at 09:16:40PM -0500, Griffin Boyce wrote:
On 2014-11-09 15:30, Fabio Pietrosanti - lists wrote:
On 11/9/14 8:58 PM, Jacob Appelbaum wrote:
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file. That sounds interesting.
Also i love this idea but i would suggest to preserve the copy&paste self-authenticated URL property of TorHS, also in presence of authorization.
I'm conflicted about this idea. Much better for usability ~but~ there should be an option for authenticated hidden services that want to *not* prompt and instead fail silently if the key isn't in the torrc (or x.y.onion url, depending on the design).
Use case: if someone finds my hidden service url written in my planner while traveling across the border, they might visit it to see what it contains. If it offers a prompt, then they know it exists and can press me for the auth key (perhaps with an M4 carbine). If there's no prompt and the request fails, then perhaps it "used to exist" a long time ago, or I wrote down an example URL.
best, Griffin
I believe it's verifiable whether an authenticated HS exists anyway; you can get the descriptor, but the list of intro points is encrypted.
-- Andrea Shepard <andrea@torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- Dr Gareth Owen Senior Lecturer Forensic Computing Course Leader School of Computing, University of Portsmouth *Office:* BK1.25 *Tel:* +44 (0)2392 84 (6423) *Web*: ghowen.me
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/11/14 12:50, George Kadianakis wrote:
I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people.
For what it's worth, the reason I haven't (so far) implemented HS authorization for Briar is that it's inconvenient to manage the list of auth cookies (effectively a second copy of the controlling app's contact list) via the control port. It would be really nice if the controlling app could store the auth cookies itself and supply the relevant cookie when making a SOCKS connection. The SOCKS password field seems like a natural fit, but I think perhaps Tor's already using the username and password for some other purpose? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUYjENAAoJEBEET9GfxSfMJz4H/iAHIn02IbkyjFEPYko2IIg/ ms6uTABTHm1VkF+UgrKejlNwYO/aVpPmeWGjohCrbqDbxw1PQdYVBncOyL1pLWa3 KkKYsyfoREGkp0/PR/jsRic3dopzp5wVKC2jT9ujVVrH1+Al1iG6f4feI6kmv4R+ jaXrjd4g57NnLpYlFwB8DMeLm/+Q5tWWp42pjNyy6edL+H06TDOe85ivcYsfzrbb BmMJexNvspKsmN5lDaG402TVnrmHaxJCj/ZaPBvQdEXDjOMQQD4MLM8eZYMY3nYA 23SW3QiXERqdg7jf8l2cLZNZyeTyYhZTRjbkySbsCwRWLN/UgE/s8WYkdbDRo0I= =i490 -----END PGP SIGNATURE-----
On 09/11/14 12:50, George Kadianakis wrote:
Hidden Service authorization is a pretty obscure feature of HSes, that can be quite useful for small-to-medium HSes.
Basically, it allows client access control during the introduction step. If the client doesn't prove itself, the Hidden Service will not poroceed to the rendezvous step.
This allows HS operators to block access in a lower level than the application-layer. It also prevents guard discovery attacks since the HS will not show up in the rendezvous. It's also a way for current HSes to hide their address and list of IPs from the HSDirs (we get this for free in rend-spec-ng.txt).
In the current HS implementation there are two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt#l768 both have different threat models.
https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt#l936 936 "client-key" NL a public key in PEM format A private key is what's actually generated. Not sure if it's a bug in the spec, or a bug in tor. From a quick read of the rest of it, I'm guessing the spec? X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
participants (12)
-
Andrea Shepard -
Fabio Pietrosanti - lists -
Gareth Owen -
Garrett Robinson -
George Kadianakis -
grarpamp -
Griffin Boyce -
Jacob Appelbaum -
Michael Rogers -
Vlad Tsyrklevich -
Ximin Luo -
Yawning Angel