Yesterday, 04:05 AM
SOCKS5 proxies do not perform hostname resolution by proxy. What this means, in layman's terms, is that whenever you do something as simple as try to visit google.com through a socks5 proxy, the resolution happens through your computer's or router's assigned dns resolver.
Why this can be problematic might be subtle at first, but you don't truly understand the logging policies or practices of your assigned DNS resolver, furthermore you also don't want that kind of traffic correlation to be possible for opsec reasons.
However, opsec might not be the only reason why this might be problematic, there can by functional applications for it as well. If you're used to routing your traffic through Tor by pointing your tools, such as curl, through Tor's SOCKS5 proxies running locally on port 9050, you might notice that even with curl configured to route through tor, you cannot access hidden services. This is because as aforementioned DNS resolutions happen through a configured dns resolver.
To demonstrate why what I mean, I've setup a simple example scenario.
I setup a tor service on my Windows VM, running on port 9050 locally.
Now, let's try to visit dark.fail through our socks5 tor proxy on curl.
Great, seems to work flawlessly, however, let's now try to visit dark dot fail's onion mirror, in theory it should work as its being routed through the same protocol.
Odd. This doesn't work. This is, in hindsight, because onion services are not normaly domain TLDs, they are not accepted or recognized by conventional DNS resolvers.
Thankfully, the fix for this is easy, here it is:
Yes, it's really that easy. The solution was simple as replacing `socks5` with `socks5h`, which is from my perspective is just a more 'extended' version of the SOCKS5 protocol, as corroborated by google sources:
This is in stark contrast to VPNs, which provide a much more 'wholesale' tunneling of your traffic through elegant protocols like WireGuard, in fact, Mullvad (which I recommend everyone to use and ditch in favour of their current VPN provider, unless stated otherwise), encrypts your DNS traffic and redirects it through their own DNS servers.
Why this can be problematic might be subtle at first, but you don't truly understand the logging policies or practices of your assigned DNS resolver, furthermore you also don't want that kind of traffic correlation to be possible for opsec reasons.
However, opsec might not be the only reason why this might be problematic, there can by functional applications for it as well. If you're used to routing your traffic through Tor by pointing your tools, such as curl, through Tor's SOCKS5 proxies running locally on port 9050, you might notice that even with curl configured to route through tor, you cannot access hidden services. This is because as aforementioned DNS resolutions happen through a configured dns resolver.
To demonstrate why what I mean, I've setup a simple example scenario.
I setup a tor service on my Windows VM, running on port 9050 locally.
Code:
PS C:\Users\user\Downloads\Tor-Expert\tor> .\tor.exe
Apr 19 20:17:20.325 [notice] Tor 0.4.9.6 (git-894a92ac2279747e) running on Windows 8 [or later] with Libevent <redacted>-stable, OpenSSL <redacted>, Zlib <redacted>, Liblzma N/A, Libzstd N/A and Unknown N/A as libc.
Apr 19 20:17:20.325 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Apr 19 20:17:20.337 [notice] Configuration file "C:\Users\user\AppData\Roaming\tor\torrc" not present, using reasonable defaults.
Apr 19 20:17:20.337 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\Users\user\Downloads\Tor-Expert\tor\<default>. Is this what you wanted?
Apr 19 20:17:20.337 [warn] Path for GeoIPv6File (<default>) is relative and will resolve to C:\Users\user\Downloads\Tor-Expert\tor\<default>. Is this what you wanted?
Apr 19 20:17:20.338 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 19 20:17:20.338 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050 <- Important part
...................................Now, let's try to visit dark.fail through our socks5 tor proxy on curl.
Code:
C:\Users\user>curl --proxy socks5://127.0.0.1:9050 https://dark.fail
<!doctype html>
<html lang="en"><head><title>dark.fail: Which Tor sites are online?</title><meta charset="UTF-8"><link rel="canonical" href="https://dark.fail">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0"><meta name="description" content="Learn how to use Tor hidden services safely. Check whether a .onion site is online, View the uptime history of popular Tor sites and their mirrors."><link href="data:image/x-icon;base64,AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAMNn/AAKQsAAXiicABKnPAAKwLgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABISFAAAAAABQUFBQAAAABERERERAAAAQSEhISEAAAAUFBQUFAAAABERERERAAAAQSEhIUEAAAAUFBQUFAAAAAEREREQAAAAABFEEQAAAAAAATMQAAAAAABTMzUAAAAAAAMwMAAAAAAFMwMzUAAAAAADAwAAAAAAAFAAUAAAD4HwAA8A8AAOAHAADgBwAA4AcAAOAHAADgBwAA4AcAAPAPAAD4HwAA/D8AAPgfAAD8vwAA8Q8AAP1/AAD7vwAA" rel="icon" type="image/x-icon">Great, seems to work flawlessly, however, let's now try to visit dark dot fail's onion mirror, in theory it should work as its being routed through the same protocol.
Code:
C:\Users\user>curl --proxy socks5://127.0.0.1:9050 http://darkfailenbsdla5mal2mxn2uz66od5vtzd5qozslagrfzachha3f3id.onion/
curl: (97) Not resolving .onion address (RFC 7686)Odd. This doesn't work. This is, in hindsight, because onion services are not normaly domain TLDs, they are not accepted or recognized by conventional DNS resolvers.
Thankfully, the fix for this is easy, here it is:
Code:
C:\Users\user>curl --proxy socks5h://127.0.0.1:9050 http://darkfailenbsdla5mal2mxn2uz66od5vtzd5qozslagrfzachha3f3id.onion/
<!doctype html>
<html lang="en"><head><title>dark.fail: Which Tor sites are online?</title><meta charset="UTF-8"><link rel="canonical" href="https://dark.fail">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0"><meta name="description" content="Learn how to use Tor hidden services safely. Check whether a .onion site is online, View the uptime history of popular Tor sites and their mirrors."><link href="data:image/x-icon;base64,AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAMNn/AAKQsAAXiicABKnPAAKwLgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABISFAAAAAABQUFBQAAAABERERERAAAAQSEhISEAAAAUFBQUFAAAABERERERAAAAQSEhIUEAAAAUFBQUFAAAAAEREREQAAAAABFEEQAAAAAAATMQAAAAAABTMzUAAAAAAAMwMAAAAAAFMwMzUAAAAAADAwAAAAAAAFAAUAAAD4HwAA8A8AAOAHAADgBwAA4AcAAOAHAADgBwAA4AcAAPAPAAD4HwAA/D8AAPgfAAD8vwAA8Q8AAP1/AAD7vwAA" rel="icon" type="image/x-icon">Yes, it's really that easy. The solution was simple as replacing `socks5` with `socks5h`, which is from my perspective is just a more 'extended' version of the SOCKS5 protocol, as corroborated by google sources:
Quote:SOCKS5 and SOCKS5h are both versions of the SOCKS protocol used for proxy servers. The main difference between the two is that SOCKS5h includes support for hostname resolution, allowing for more flexibility in routing traffic through the proxy server. This means that SOCKS5h can handle requests for domain names, while SOCKS5 requires the client to resolve the hostname before sending the request to the proxy server. Overall, SOCKS5h offers a more seamless and efficient proxy experience compared to SOCKS5.
This is in stark contrast to VPNs, which provide a much more 'wholesale' tunneling of your traffic through elegant protocols like WireGuard, in fact, Mullvad (which I recommend everyone to use and ditch in favour of their current VPN provider, unless stated otherwise), encrypts your DNS traffic and redirects it through their own DNS servers.