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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Any solution to this should also differentiate between different circuits.
Trac: Cc: N/Ato 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
"""
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.
"""
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:
This is a large private subnet, so we don't accidentally collide with anyone else's IP.
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.