On November 9, 2014 7:50:00 AM EST, George Kadianakis <desnacked@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev