Tor should provide a mechanism for hidden services to differentiate authorized clients and circuits

Tor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exported.

Trac:
Username: katmagic

changed milestone to %Tor: 0.3.5.x-final

added 035-roadmap-master component::core tor/tor milestone::Tor: 0.3.5.x-final needs-design needs-proposal points::10 priority::medium reporter::katmagic resolution::implemented reviewer::dgoulet severity::normal status::closed tor-control tor-hs type::enhancement labels

Good idea; will need a proposal.

Trac:
Keywords: hiddenServices control deleted, hiddenServices control needs-proposal added
Milestone: N/A to Tor: unspecified

Trac:
Keywords: hiddenServices control needs-proposal deleted, hiddenServices control needs-proposal tor-hs added

Trac:
Component: Tor Hidden Services to Tor

Any solution to this should also differentiate between different circuits.

Trac:
Cc: N/A to special
Summary: Tor should provide a mechanism for hidden services to differentiate authorized clients. to Tor should provide a mechanism for hidden services to differentiate authorized clients and circuits

Not quite the same thing, but an intriguing direction anyway:

https://lists.torproject.org/pipermail/tor-dev/2014-March/006576.html

""" I've written this (ugly, unconfigurable) patch for Tor which is designed to allow hidden services more information about their users, by giving each inbound circuit its own temporary "IP address" in the 127.x range. This technique works on Linux (I've not tried it on anything else) and allows the application server to do some useful things which were previously difficult:

• Identify TCP connections coming from the same client, in a short space of time, for example, for diagnostic log analysis, identifying traffic trends
• Rate-limit operations coming from the same client, to defend against some types of DoS attacks
• Temporarily block abusive clients (at least, until they make a new Tor circuit)

More importantly, it can do this with an unmodified application-server (e.g. web servers typically have these features built-in) because it effectively "spoofs" the client ID as an ip-address, in the 127.x range. """

Trac:
Severity: N/A to Normal
Reviewer: N/A to N/A
Keywords: hiddenServices control needs-proposal tor-hs deleted, needs-proposal, tor-hs, control added
Sponsor: N/A to N/A
Points: N/A to medium

Trac:
Keywords: control deleted, tor-control added

Trac:
Keywords: tor-hs deleted, tor-hs needs-design added
Points: medium to 10

Trac:
Cc: special to special, ahf

Potential protocol to use here: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

Some programs that can understand it: https://www.haproxy.com/blog/haproxy/proxy-protocol/

Trac:
Keywords: N/A deleted, 035-proposed added

ahf, do I remember that you had a patch for this one? Is it nearly-ready-but-sitting-in-a-mailbox-somewhere?

See also #24299 (moved) which looks very related.

arma, yes, there is indeed a very early patch in https://github.com/ahf/tor/commits/ahf/wip-ascii-tcp-proxy - this was shared with our contact at CF to test.

It encodes our 32-bit global identifier on the circuit as two 16-bit in the HA ASCII proxy protocol.

The patch needs some torrc options before being worthwhile to include.

Hmm, yes indeed we want some torrc options. Perhaps we can introduce a string torrc option HSClientIdentifierMethod which takes the proxy value (or haproxy) value for the proxy protocol of comment:10? And then in the future perhaps we can introduce other methods, like client_auth which returns the name of the client visiting, etc.?

Also as you pointed out, the current patch will do the protocol also for regular exit conns. We should check that the edge_connection_t has either hs_ident or rend_data` before doing the protocol.

Sorry I forgot to give any feedback for this. It worked well! At some point in the future it might be a good idea to implement the v2 protocol as well.

Regarding torrc options: Can you also add an option for encoding the circuit ID in the port or in the source IP?For our specific application using the last 32 bits of a private ipv6 subnet (like fc00::/7) is ideal for two reasons:

1. This is a large private subnet, so we don't accidentally collide with anyone else's IP.
2. The rest of the pipeline can simply look at that IP and pretend everything is normal, no need to implement special logic to parse the port numbers. The only requirement is to implement a proxy protocol server in the normal pipeline, which is already done. Perhaps HiddenServiceExportCircuitID proxy port for ahf's implementation and proxy srcIP fdXX:XXXX:.../96 for my suggestion?

Trac:
Username: mahrud
Cc: special, ahf to special, ahf, mahrud

This is a sufficiently narrow use case that I think we should try to limit ourselves to one torrc option, which turns it on or not, and one behavior that happens when you turn it on.

In that case I would prefer HiddenServiceExportCircuitID 1 to choose a random /96 subnet of [fc00::/7] for each hidden service and encode circuit ID in the source IP. I'm working on a Caddy plugin that takes this information and hands it over to the server, so anyone can use this feature. I think returning accurate values for the ports is probably best, but I'm not sure what the destination IP should be.

Trac:
Username: mahrud

Trac:
Keywords: tor-hs needs-design, 035-proposed deleted, 035-roadmap-proposed, needs-design, tor-hs added

Trac:
Keywords: 035-roadmap-proposed deleted, 035-roadmap-master added

OK I worked on this. Please see my branch bug4700_rebase: https://github.com/torproject/tor/pull/327

It does various things:

• Saves up original virtual port.
• Adds torrc option.
• Puts stuff in functions and documentation.
• Unittest and changes file.

Please review and test if possible. I've done rudimentary basic testing but I don't know how to test this feature more deeply (i.e. actually use the results of the proxy protocol).

Trac:
Status: new to needs_review

Some questions that might require changes.

Trac:
Status: needs_review to needs_revision
Reviewer: N/A to dgoulet

OK, after review and revisions from dgoulet and ahf I present the final merge_ready branch: https://github.com/torproject/tor/pull/343

I'm also gonna send this to mahrud so that he can check it out.

Trac:
Status: needs_revision to merge_ready

Found another bug with this code:

$ nc -l -p 6667
CAP LS
NICK user
USER user user rxyw2yu2mxczblqcov5d3m6fqyem7rnamcean46wu7srdh5so7dro7qd.onion :Unknown
PROXY TCP6 fc00:dead:beef:4dad::0:25 ::1 37 6667

This happens when an IRC client is connecting to an OS with this feature enabled. We need to make sure the PROXY string is added to the beginning of the buffer and not the end.

https://github.com/ahf/tor/commit/3477a73af99eb72f8374928fdc2fab4858485219 patch for the above problem.

Replying to ahf:

https://github.com/ahf/tor/commit/3477a73af99eb72f8374928fdc2fab4858485219 patch for the above problem.

Thanks. Cherry picked it into bug4700 branch.

Because of the timeframe, calling this "0.3.6", but please let me know if I'm wrong.

Trac:
Milestone: Tor: unspecified to Tor: 0.3.6.x-final

Changing back to 035 after discussion on IRC with Nick.

This is not a huge priority ticket so if the release gets overwhelmed with features we can potentially move this to 036 if needed.

Trac:
Milestone: Tor: 0.3.6.x-final to Tor: 0.3.5.x-final

Hi! This patch looks good.

Three things I think we should do here:

• I think that the configuration option should accept "none" in addition to "haproxy".
• We should link to the spec for this protocol, in the code and in the manual, and explain which version we support.
• Are we exposing the 'global_identifier' field for an important reason, or is it just important that we expose some unique value? If it's the latter case, instead of putting the 'global_identifier' into the IPv6 address and source port directly, I think we should hash them first, possibly with siphash. It's not that these values are very sensitive, but I don't want anybody depending on the actual global_identifier layouts from Tor unless we're exposing them intentionally. (But if we are exposing them intentionally, we should document that.)

One thing for the future, or maybe I don't understand this:

• Is there some intended way for programs to tell whether a user's circuit is authenticated, and if so to which user?

Trac:
Status: merge_ready to needs_revision

After talking with ahf, I think we shouldn't hash the global_identifier, but we should document that we use it.

Added two patches to https://github.com/ahf/tor/commits/asn/bugs4700_2 to fix documentation and support of the 'none' config option.

LGTM!

Trac:
Status: needs_revision to merge_ready

merged!

Trac:
Status: merge_ready to closed
Resolution: N/A to implemented

closed

changed time estimate to 80h

mentioned in issue #16052 (moved)

mentioned in issue #24299 (moved)

mentioned in issue #27680 (moved)

moved to tpo/core/tor#4700 (closed)