Re: [tor-dev] Hidden Service authorization UI

[Ximin Luo]

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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Michael Rogers]

-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-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Nathan Freitas]

On Sun, Nov 9, 2014, at 07:50 AM, George Kadianakis wrote:
> Hidden Service authorization is a pretty obscure feature of HSes, that
> can be quite useful for small-to-medium HSes.
... 
> 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.

We have been working on implementing an OnionShare feature for Orbot, as
a plugin/add-on. Since the client and the server are both one simple
app, it seems like we could easily implement the HS Authorization
feature. Since the goal is to share a file with a small audience, the
second "client key" approach seems to be the best, most secure approach
to me.

Any thoughts?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Gareth Owen]

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  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
> 
> 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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Andrea Shepard]

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

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


pgprRfXrwBan3.pgp
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Griffin Boyce]

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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[grarpamp]

On Sun, Nov 9, 2014 at 3:30 PM, 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.
>
> 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.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Fabio Pietrosanti - lists]

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

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

Re: [tor-dev] Hidden Service authorization UI

[Jacob Appelbaum]

> 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-ng.txt#l1446
> 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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [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
 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 
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
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Garrett Robinson]

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



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] Hidden Service authorization UI

[Yawning Angel]

On Sun, 9 Nov 2014 16:19:24 +
Andrea Shepard  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


pgp1Omyydtsp8.pgp
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] Hidden Service authorization UI

[Andrea Shepard]

On Sun, Nov 09, 2014 at 12:50:00PM +, 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

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


pgpzJ7kEbdqKF.pgp
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Andrea Shepard]

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

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


pgpk8DwIelER8.pgp
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Griffin Boyce]

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  
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-ng.txt#l1446
>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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev