Now DNS requests are send to ExitNodes so Exit operator does see DNS request from MiddleRelay and then it’s connection request to destination IP:PORT so it’s easy to see for him what exact site MiddleNode is connecting to, with separate circuit for DNS requests ExitNode operator would only see IP:PORT connection but no DNS request from MiddleRelay so it should be a little harder to guess what site/content MiddleNode requests from target site as there may be many sites operating at same IP:PORT
If the DNS request is done via UDP that would be correct but I seems to remember that DNS is done via https. I’m not sure where I read that but it would make sense that the authors of Tor would have thought of this also if I could.
I checked the Tor browser settings and that option is not on by default.
Do you have evidence that it is always done with UDP?
I’m talking about standalone Tor service not Tor Browser, so now I’m using Firefox ESR + 127.0.0.1:9050 as SOCKS server, DNS requests are send via this SOCKS which support TCP only so no UDP involved here.
Within actual Tor design DNS requests are sent to ExitNodes to be resolved there, then DNS response (A/AAAA field IP address for domain) is send back and a moment later ExitNode does see HTTP/S connections request from the same MiddleNode that asked for domain resolution to IP:PORT.
So at this moment ExitNode operator can easily connect those two requests (1.DNS + 2.HTTP/S) and think that way: Aha, someone send me DNS request for www.somebadthing.com which A/AAAA record is IP and now he is connecting to that IP so such a operator does clearly see that someone is looking especially for www.somebadthing.com and is connecting there, while with my propose DNS resolving would be made via separate Tor circuit so ExitNode would only see HTTP/S request for IP:PORT without knowing which domain was requested (as this is if I’m not mistaken) send over encrypted TLS connection.
Yes, but imagine there is a Police which started an ExitNode, and they made simple software which filters/groups such a connection scheme (1. DNS request + 2. HTTP/S request) they can easily filter out not so important connections and look only for those to www.somebadthing.com and other domains they have on their watch list and then start typical investigation, without this 1.DNS request thing they wouldn’t know what exact site MiddleNode is connecting.
I’m not telling this would make such a connection much safer but a little yes, it should complicate logical analysis of the logs @ ExitNode because they would only have typical TIME IP:PORT info but not exact domain someone was looking for.
You can see that, whether DNS or not, from which middle node the connection comes.
But that doesn’t matter at all with 3 hops Tor circuits. Tor is designed in such a way that it doesn’t matter if there is an adversary in the connection.
For this, NSA/FBI/Interpol does not need an exit at all, they can analyze Netflow data. There is a reason why DNMs are not in the Clearnet, but are hidden services.
I’m not talking about MiddleNode revealing to ExitRelay as it is of course known to ExitRelay at IP layer. Let’s don’t care about this, I’m talking about revealing to ExitRelay what exact site is MiddleNode connecting.
Due to SNI you can host multiple sites on single www server at same IP:PORT, for ex. www.somebadthing.com and www.somegoodthing.com, their A/AAAA DNS records may point to the same IP. When ExitRelay does DNS resolving for MiddleNode it does see which one of those two MiddleNode is going to access (because MiddleNode asked for that exact domain in DNS request) so you may put more interest on that connection from official services operating such a ExitRelay, while when you do DNS resolution somewhere else (separate Tor circuit as I propose) you make only https://IP:PORT connection request without revealing which domain you are accessing (good or bad, due to ESNI) to ExitRelay and that’s why I’m suggesting to Tor devs that it would make sense to add such a new circuits, so DNS requests are always resolved by some random nodes not being part of actual Data transfer circuit.
@leek makes an interesting point. Perhaps one could run a second Tor instance specifically for DNS, and then uncheck Firefox’s “Proxy DNS when using SOCKS5”. At this point Firefox would be using the system DNS, and that may have some privacy pitfalls, too.
For example, currently I check Firefox’s “Proxy DNS when using SOCKS5”; however, the remaining DNS traffic flows from pfSense to Pi-hole to Tor. Adding another QEMU-KVM guest for Tor DNS would be trivial.
I think I have read that multiple instances of Tor (separate processes) can be run on the same computer, but I have never tried that. It may be an option if you are adverse to hypervisors.
I’m doing something different to separate DNS traffic from other/Data circuits with one Tor instance, If you set:
SocksPort 127.0.0.1:9050 IsolateDestAddr
in torrc, the easiest way to get separate circuit for DNS is to enable DoH in Firefox and uncheck “Proxy DNS when using SOCKS5” this way your connection to DoH will be routed via separate Tor circuit so you are anonymous at DoH server and ExitRelay does not resolve DNS so it should only see IP:PORT requests not knowing which domain/site you are connecting.
It does make some sense. Seeing you basically answered your own post after some distraction. I know how it feels. What are you using it for? Do you have any Tor for Android advise?
@leek, your SocksPort isolation flag “IsolateDestAddr” encouraged me to review the available isolation flags. Both SocksPort and DNSPort offer isolation flag “IsolateClientProtocol” which may be the way to go to segregate HTTPS traffic from DNS traffic.
“IsolateClientProtocol:
Don’t share circuits with streams using a different protocol. (SOCKS 4, SOCKS 5, TransPort connections, NATDPort connections, and DNSPort requests are all considered to be different protocols.)”
You have probably focused yourself on something that is irrelevant for this subject.
I’m claiming that simply splitting DNS and Data traffic can be easy trick to make ExitRelay operator a little more blind about traffic flowing through his node and that’s it, nothing more. It would be nice to have it in Tor by default without tweaking here and there.
Detailed fingerprint in this case is not important because I’m talking about hiding fact: “which site MiddleNode/user is connecting to” to the ExitRelay operator and not who is the user requesting this. These are two different things.
I’m talking about prevention of being hit by Police crawling lights at very early stage.
or are you making ‘dig’ requests out of boredom?
There is a reason why DNMs are not in the Clearnet, but are hidden services.