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-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