-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When using SOCKS5 proxy, do name resolution through the proxy #469
Comments
One other leak is DNS:
It sends DNS requests to the regular DNS server, while SOCKS5 does support DNS, and SOCKS5 should be used for DNS. Now when I look at the original UDP-connected sockets, they mostly or only call |
I have made a reproducible example https://gist.github.com/nurupo/c2a4eeaedec65dc4e55ef05e4b369f03
Anyway, it's the To fix this, we need to do name resolution over SOCKS5 proxy when SOCKS5 proxy is selected. |
Actually, there are 2 more |
Here is a summary of what changes need to be done in toxcore in order to resolve this issue. When using SOCKS5 proxy, there are 3 cases when the name resolution is done:
In case 1, toxcore can't connect at all unless it uses DNS without tunneling it through a proxy in order to resolve proxy's IP address. We could require the SOCKS5 proxy address in In case 2, we need to implement a In case 3, toxcore could just not resolve the address of TCP relays at all, as, in addition to IPv4 and IPv6, SOCKS5 also allows specifying hostname of the machine you want to establish the tunnel to ( |
Another relevant point here is that some SOCKS5 servers do support UDP, and some others don't. Particularly, Tor's SOCKS5 doesn't currently support UDP, only DNS UDP. 'Enable UDP'=true should generally enable UDP through SOCKS5. However, if SOCKS5 will be rejecting UDP associations, client should see some indication of this. Currently, user can always have 'Enable UDP'=true and it isn't quite clear what happens when UDP isn't supported by SOCKS5. |
Well, toxcore currently supports SOCKS5 in TCP-only. If you don't disable UDP, TCP traffic will go through the proxy, but UDP won't, you'd be making direct connections with UDP.
Because of this some Tox clients automatically disable UDP when you try to use a proxy (I know uTox does this, not sure about other clients). Also, toxcore doesn't even need SOCKS5 UDP support for the name resolution as DNS servers are required to listen on both UDP 53 and TCP 53, so we could just use SOCKS5 proxy to connect to TCP port 53 of a DNS server. |
This will differ from UDP DNS, because you will have to make a choice for a DNS server, while with UDP this isn't required. |
Could you elaborate more on that? I don't understand what you mean. The way I see it, you will have to chose a DNS server regardless of whether you want to communicate with it through UDP or TCP, since you will need to tell the SOCKS5 proxy the address of the DNS server to connect to in both cases. |
With SOCKS5, you have a choice of the address type. It can be IPv4 (ATYP=X'01'), textual domain name (ATYP=X'03'), or IPv6 (ATYP=X'04'). I am not sure you are supposed to send UDP/53 DNS through SOCKS5. And you shouldn't send DNS TCP either. You just connect to the destination using the address, whatever it is. No need for DNS as such. |
Oh, so that's what you mean. I have already mention this before. As I said in #469 (comment) in the 3rd case, you indeed don't have to do the name resolution for the TCP relays you want to connect though SOCKS5 proxy, because you can just tell the SOCKS5 proxy to connect to a hostname ( The issue is in the 2nd case of #469 (comment). It seems that toxcore requires you to perform bootstrap even if you use a TCP relay: In order to bootstrap off the DHT botostrap nodes, toxcore needs to resolve their hostnames. And no, it appears toxcore doesn't connect to the DHT bootstrap nodes through SOCKS5 proxy. DHT is UDP-only. So you can't connect using hostname, you have to actually do the name resolution, get IP address and use that. But toxcore also shouldn't send anything in clearnet when a proxy is enabled and UDP is disabled, so it should connect to those bootstrap nodes directly. I'm somewhat unfamiliar with how toxcore DHT works, but it might be the case that the TCP relay node, to which we are connected through SOCKS5 proxy, acts as a DHT relay and it expects all addresses of DHT nodes you send to it to be in IPv4 or IPv6. |
are you up for some testing? I'd like to give you my ID in order to test it. I'd like to see the output. |
Okay. |
2ED2CB2E3B98714A2FFA44084CB09E6953FF45E03FBB27BF552D3525FBA5677FBA1BF733A9E4 |
Well I did a bit of testing with yurivict. He was not able to see my IP because I were connected over Tor. He was just able to see all the other IPs and exit nodes so I assume it is save to use Tox over Tor. We didn't test any DNS leaks. I do not know how to test it. |
I had a conversation with @irungentoo on IRC about whether we really need to call |
Is there a documentation explaining how tox works? I understand DHT and encryption, but there are "UDP onion nodes", relay nodes, sometimes DHT isn't used. Is this explained anywhere? |
There is a documentation written in free form by irungentoo and there is an ongoing effort of making that documentation more structured. |
This is still an important issue and needs addressing. There's a way of simplifying the problem a bit to move forward: let's assume the SOCKS proxy is Tor, which is probably the majority of users right now. Corporate SOCKS proxies will require usernames and passwords which are not currently supported - for corporate proxies you will also need to do DNS resolution through the proxy. The normal configuration of Tor does not so we're OK for now. And the normal configuration of Tor has an IP address for the proxy so we don't have to worry about DNS lookup of the proxy. Additionally, if you configure Tor to do so, it will run a DNS server for you, UDP (and TCP?) on any port you choose using the So you can just write a documentation section for using Tox over Tor to describe DNSPort with Tor as the way of using Tox over Tor without leaking DNS queries if you extend ToxOptions to accept a IP/port for the DNS. But @nurupo went on to say
This may be really important to do for another reason: adding the ability of Tox to easily use Tor So we can move forward by :
|
The code to do this is almost trivial: it's a oneliner sent to the tor 9050 port. There's an implementation in Python you can follow in sTorResolve https://git.plastiras.org/emdee/toxygen_wrapper/src/branch/main/src/toxygen_wrapper/tests/support_onions.py |
@emdee-is if it's so trivial, then feel free to open a PR. However, I assure you that the change required to use a SOCKS5 proxy for name resolution in toxcore is far from being a trivial one-liner. It would require making If someone decides to tackle this for the general case of using a custom user-specified DNS server, via clearnet and proxy, they would find out that there is no standard API for asynchronous DNS: glibc has |
I stand corrected: it was close to trivial for me to implement in Python so I thought the same could be implemented in C. Shows you how much I know about C, and why I'll never open a PR in C. I assumed getting an answer would be no more complex than the current SOCK5 connect negotiation because it's the same port and protocol. Still I think this is an important issue and should be mentioned in the README; many Tor users are naive about DNS leaks while using Tor, and very few with have UDP+TCP firewalls in place, which are hard to do and even harder to test. We've had help requests in IRC from people in places like Iran so it can be crucial. I'll publicize the fact that you need a firewall if you want anonymity with Tor so people don't get burned. (I see 8 packages on my Linux that use c-ares and it runs on POSIX including arm sparc s390 and macos, Windows, and Android ) Do all the complications you listed apply to having the code get its DNS from other than 127,0.0.1:53? Tor is easily configured to provide DNS on 127.0.0.1:9053 UDP if that helps; we could "easily" add a SOCKS_DNS_HOST and SOCKS_DNS_PORT. I leave it in your capable hands but I'd hate for it to take another 6 years for this to be fixed. |
Clients should use the IP address of bootstrap nodes instead of host names. No leaking happens then. Proxy host similar, and it usually already is localhost. |
Good point and easy to arrange client side. I don't know the workings of the DHT: if my tox instance starts with only IP addresses, is there anything over time that wil cause it to DNSlook up some other addresses? In fact I already do this in Toxygen using the code I linked to above, if Tor is asked for. In python it's a cheap and easy call and the result is cached. Can we add this to the client spec and encourage clients to use external nodelists of IPs? Could you set an example by changing ctest: ideally break the list of nodes out of the C code #2467 and perhaps lookup the IP's at build time? If socks_proxy is set then on a tor system there's a standalone executable called tor-resolve -4 that resolves the IP. |
The C compiler can't do DNS lookups so we can't do that at compile time. No, the dht never does DNS lookups outside of the client driven bootstrap call. |
No but the ctest run can be wrapped in a bash/python script that parses BSnodes.json and does the lookups and writes them into a file of IP:ports that auto_test.c is told to look for them in. (You might even put the C code that reads a file of IP:port BSnodes into the library so all clients can use it.) The bash script could look at socks_proxy in the environment and write the IP:ports file accordingly before ctest is run. In most cases this is a once-and-done step. To deal with this (six year old) security issue one solution would be to make the library code deal only with IP addresses: no calls by c-toxcore to do DNS lookups. That would be the client's job, and you could write it into the client spec. The clients could do the lookup of the nodes list, using tor-resolve or not, and cache the result. The clients could each make its decision on what async DNS library code to use, e.g. c-ares, or python code or java libraries etc. Hopefully all the clients will stop using compiled in nodelists at the same time. It's not a problem for toxygen: it already either uses it's own code for tor, or I call something for non-SOCKs. The c-toxcore stays clean and safe of this security issue. You'd have to do some planning for this:
There's an advantage to doing this: for tox-in-tor
The code that resolves names to IPs in tor will handle .onion addresses for Tox-in-Tor, something I doubt c-toxcore will ever do. So you would get defacto .onion address compatability if you did this. |
Regarding my previous comment. I gave it a bit of thought and I think it is possible to make SOCKS5 hostname lookups synchronous without breaking a lot of things. We could create a |
I think so, especially if you cache the result and it's only probably a half dozen lookups per Tox lifetime. I looked at the C-toxcore code to do a SOCKs connect once and although I'm no good at C, I know the Python code is dead simple and must be less complex than the existing c-core SOCKs connect code. The existing connect code should be reusable with some command-response byte changes. And you have a working "reference" implementation in Python. Tor circuits can be slow but the lookups are immediate. And if the user is using tox over tor, he's in no hurry anyway :=,) If you go that route can you keep open to the likelihood that the node names may be .onion addresses for tox-in-tor? I don't see tox caring about what's in a name, except they are long (62b). You can do longterm mapping of onion addresses to spoofed IPs in a given reserved range in tor with a little tinkering on torrc. |
I'd like to remove DNS code from toxcore for 0.3.0. For that, the first step would be to deprecate passing host names to bootstrap and proxy hosts (in documentation, maybe adding an options flag to make it not work so clients can test compatibility with future changes). |
I agree with @iphydf here. Clients usually are in a better position to perform DNS lookups because they might already perform other types of out-of-band network connections like push notifications using more accessible libraries (@emdee-is mentioned it was pretty easy in python land). I think we discussed this a while back in chat and also came to the conclusion to allow clients to provide their own network functions. The idea here was that toxcore would by default not provide DNS lookup functions, but a client implementer could still provide their own. Not sure if this is worth doing, considering that the client implementer can just resolve them before handing them to toxcore though. |
Dropping DNS support is fine with me - toxygen already has. Can I get a yes on the idea of c-toxcore supporting reading a list of IP:port so clients can have that standardized? Can I get a yes on the idea of c-toxcore ctests reading a list of IP:port:prot so BSnodes are broken out of automatic.c? @robinlinden Are you putting together some release notes for the 0.2.19 release? If so, could you do a section on 'upcoming changes' and put your version of the steps I outlined? There could be a list of planned incompatabilities for 0.3.0. At the current rate, it may be another ~6 years before 0.3.0 lands; and I'd rather this security issue isn't left open until then. @nurupo it seems to (ignorant) me that the existing SOCKS code could be repurposed to do, admittedly blocking, tor lookups. Could you look into the possibility of doing it? Then this issue could get resolved and maybe testing can start on tox-in-tor. |
No. This has to be done at the client level, not in toxcore. Toxcore doesn't read files. It provides API allowing to specify IP and port, so just have clients read a file and call the appropriate API functions. Clients can decide on their own on whatever file format they want to standardize, if any -- this does not concern toxcore.
There is no "automatic.c" in toxcore.
Not sure what you mean by "tor lookups". If you mean using a Tor-aware SOCKS5 proxy to connect to TCP relays via their .onion addresses by passing those .onion directly to the proxy without toxcore doing the name resolution, then yes, this is possible. This doesn't fit the current
It doesn't make much sense to announce a list of planned changes for 0.3.0 in 0.2.19's release notes if we are unsure of what they will be yet ourselves. We have some ideas, but they might change when implementing them or when they clash with other changes we want to see in 0.3.0. It's also not known when 0.3.0 will release, for all I know we might continue working on 0.2.20, 0.2.21, etc. for a while now, working on changes that don't necessitate API breakage, meanwhile doing a better job on documenting what breaking changes we want to do in 0.3.0 by opening milestoned issues so that we don't forget about them and so that we could discuss them before they are implemented. API breaking changes are important changes, having them being scattered all around IRC, groupchats, random PR and Issue discussions (like the mentioning of #469 (comment) in here), or not even not being discussed at all but being in developers' heads and then dropping as a surprise fully implemented PR, is not very good. While it works for regular changes, for the API-breaking ones we really should keep a list of them all and be able to discuss if needed. Anyway, I got a little side-tracked here. |
I disagree - if you had standardized support for reading a list and the format of the list, it would encourage the use of external nodelists, rather than the groddy habit of compiled in lists, which are brittle and inhibit the testing in non-canonical situtations like tox-in-tor.
My bad - I meant to say auto_test_support.c - which I referred to above in #469 (comment) :
These should be broken out into a IP:port list, and if you standardized how to do that it would encourgage clients to use that stanardized function of reading an external Nodeslist. c-toxcore does not currently read files, but in this case, I think it should. |
A "tor lookup" is when you resolve an .onion address to an IP that is stable during the lifetime of a Tor process (usually long - longer than a Tox client except maybe a BSdaemon).
That IP is good for the lifetime of the Tor instance and the IP is what would be passed to Tox for a BS .onion via an external nodelist for .onion BS addresses with tox-in-tor. But you also do that lookup internally by the simple query of the socks proxy which is required anyway of non-onion BS adresseses, which is needed to fix DNS leak in this issue.
New versions of tox_add_tcp_relay(), are required to fix this issue and avoid the DNS lookups that leak in current Tox over Tor usage, hence #469 (comment) That code would also resolve .onion BS addresses as an incidental side benefit. |
I think this issue gets resolved by #2694 which is OK I guess - the clients will have to do the lookups, which toxygen already does. This is an API break as it changes the structure of Tox_Options and should be merged in a new version number of c-toxcore. |
trifa for android does dns lookups via tor, when you set tor (orbot) proxy. |
I just did a simple experiment. With 'Enable UDP'=off, 'Proxy type'=SOCKS5, 'Proxy address'=localhost, port=9050, system call log has this:
This is the UDP socket for the clearnet IP 104.156.104.15. So Tox does leak IP despite of the proxy setting, and despite of 'Enable UDP'=off.
With the above network settings all connections should go through the proxy. No UDP should be attempted. No IPs except 127.0.0.1 should appear in the log.
I think I created such bug report before, but can't find it now.
toxcore-0.1.5,1
qTox-1.8.1
The text was updated successfully, but these errors were encountered: