0

I have tor running on a pc, with its socks server listening on localhost port 9050.

I would like to limit the socks server in this way:

socks requests (from clients) should be allowed only for a given hidden service url, and blocked for any other request.

Is this possible with tor? How can I do it?

0

No, this cannot be done within Tor.

You'd need to run some SOCKS shim to filter out requests that aren't explicitly for that onion address which should be a simple (for a programmer) task if the application using the SOCKSPort is using SOCKS5h or SOCKS4a (if it's not, it's a bit more involved) but it would need to be done outside of Tor.

  • I am using SOCKS4a. Can you suggest a SOCKS proxy or another kind of "shim" to filter out requests? – mrtexaz Jan 8 '18 at 15:18
  • The process would really be implementing SOCKS4a/SOCKS5 well enough to mimick enough functionality for the client(s) to be able to use it, then when they provide you with where to connect check it against the list and either fail the connection by sending the client a response, or allow it to continue. – cacahuatl Jan 8 '18 at 19:48
0

Well, using just SOCKS it's impossible - whatever the software is applied: the reason is in the SOCKS protocol nature. It's not like HTTP proxy that works like "I want to connect to http://xy.z via GET http://xy.z -> Ok, here it is" - it's working by providing pipes, so the "jailbreak scenarios" can be exploited here with Auto-mapping hosts to local network - like 10.0.0.0/16, so SOCKS server will get a request like "I want to connect to 10.0.11.12 port 1234", not like "I want to connect to not-whitelisted-onion-service.onion port 1234". If you will not use automapping - well, it still be quite a work with an intermediate proxy to filter the URL list. But keep in mind - a jailbreak here is still possible if, for example, the whitelisted service makes some proxy-like stuff - you won't see the URL's. So - if you want to be 100% sure to allow access to your own hidden service - use HTTPS for it with an enforced HTTPS with self-generated certificate and a SSL proxy - and on your SSL proxy drop any traffic that is not goes through with your server's certificate(you'll have to load a copy of that cert to your SSL proxy). Only that particular solution will ensure the strictness and won't break end-user experiences much.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.