Using the QuantumGate Socks5 extender for private encrypted communications
During the last few weeks I’ve done a lot of work on QuantumGate. It’s still in experimental stages right now, but very usable. A lot of the time I spent on working on it went into optimizations. I’ve been using it in the last few days together with the SOCKS 5 test extender (Socks5 Extender) for browsing the Internet and it’s been working quite well.
On one machine I used the FireFox browser and configured it to use a SOCKS 5 proxy so that it would connect through the Socks5 Extender. I also wanted to test it as a system-wide proxy setting on Windows 10 on another machine, and it turned out that Windows 10 uses SOCKS 4 to connect by default, so I had to add partial support for SOCKS 4 to the Socks5 Extender as well. That took only a few hours of programming work.
Figure 1
In figure 1 you can see a diagram of one of the setups I used. On the user PC FireFox connects to the Socks5 Extender running within QuantumGate using the TestApp which can be found in the ‘Test’ folder in the project source code. That instance of QuantumGate is connected via the ISP to another instance of QuantumGate (also the TestApp) running on a relay server, which could be hosted somewhere in the cloud, for example on Amazon Web Services (AWS) or Microsoft Azure. In my case, I used an AWS EC2 instance running Windows Server 2019. It doesn’t have to be a server however; it could be just another peer. The instance of QuantumGate running on the relay server also has the Socks5 test extender loaded. And as you can see in the image, the connections made by FireFox (the yellow arrows) are routed through the encrypted connection between the two QuantumGate instances (the green tube), and through the Socks5 Extender on the relay server are forwarded to the destination websites.
In this setup, the user would be able to bypass surveillance, tracking, traffic analysis/shaping, spying, censorship and any other kind of malicious behavior from their ISP as long as they’re able to reach the relay server. In this specific case, using FireFox, there’s much more that you need to be aware of, such as that you also need to configure FireFox to use the SOCKS 5 proxy for DNS requests. In the case of the Windows system-wide proxy settings, you can’t configure Windows to send DNS requests to the SOCKS 5 proxy, and if you were to use the Microsoft Internet Explorer or Edge browsers, you would be leaking the DNS requests to your ISP (where they can be recorded and tampered with).
Figure 2
In figure 2 the setup from figure 1 is expanded slightly with another node in the middle, adding another level of indirection. As you can see from the image, the middle node (relay server 1) runs an instance of QuantumGate without the Socks5 Extender (the TestApp without the Socks5 extender loaded). The Socks5 Extender is not needed there because that node simply acts as a router or gateway to connect the user PC to relay server 2. In this case, the QuantumGate instance on the user PC is connected to relay server 2 (the blue tube) first through its connection to relay server 1, and secondly through the connection between relay server 1 and relay server 2 (the green tubes). In the image you can see the blue tube going through the two green tubes. This is what is called a 2-hop relay connection, and you can read more about this in the relay documentation.
Adding another level of indirection in this way makes it more difficult to track the origin and destination of traffic on the network and would better guarantee the user’s anonymity, especially when more users use relay server 1 and relay server 2 to connect to the Internet.
Figure 3
Figure 3 shows another one of the cool capabilities of QuantumGate. In this setup, the user PC is connected directly to relay server 1 and 2 via two separate direct connections (the green tubes). The connections that FireFox is trying to make get split up by the Socks5 Extender and are tunneled in a random way through both connections to relay server 1 and 2. When you visit a website, it often happens that multiple connections are made by the browser (to a couple of different servers) to load that website. In this setup, these connections would randomly get routed by the Socks5 Extender (which is programmed to use multiple connections on the QuantumGate instance to do this) to either relay server 1 or 2. Now keep in mind that relay server 1 and 2 could be running in different parts of the world; for example relay server 1 could be in the USA while relay server 2 runs in Sweden, and the user PC might be in the Netherlands. The destination website (and any other website where it needs to load embedded resources, such as CSS, javascript, images, fonts etc.) would see connections coming from different parts of the world, and would have a difficult time to realize that these are all related to one single user.
It doesn’t take a lot of imagination to realize that this would make user tracking for advertising and other purposes much more difficult. This setup could easily be expanded with more relay servers to create even more confusion. And as a big bonus, this setup also acts as a load balancer; the Socks5 Extender is spreading the load of requests made by FireFox on the user PC over the two relay servers, which can result in better performance.
Figure 4
In figure 4 you can see a combination of the setups in figure 2 and figure 3. Such a setup would cause even more confusion and difficulty tracking the traffic. The way QuantumGate is architected really allows for some very cool things to be built on top of it.
The Socks5 Extender could easily be made into a commercial product for private browsing and in its current state there’s not a lot of extra work that would be required to get to a minimum viable product (mostly security related extra work). It could be offered as some kind of VPN-like service with a monthly subscription for example. The code is currently available on GitHub under an MIT license, so if anyone reading this is interested, feel absolutely free to take it and use it.
I spent a lot of time on optimizing the way QuantumGate handles relay connections. I had to make some changes to the relay functionality adding the ability to deal with traffic congestion. With regard to dealing with traffic congestion there’s still more work left to do. Certain things will be left up to the writers of extenders, but I want QuantumGate to be able to detect and handle any issues where possible.
I also wrote two tutorials on how to create relays using QuantumGate using the C++ programming language. You can find them in the wiki on GitHub: “How to create a single hop relay” and “How to create a two hop relay”. I plan to write more tutorials in the future providing more code examples demonstrating how to use the QuantumGate library and API. And this is apart from the example projects that are also available on GitHub, with comments in the source code explaining the code.
There were also some changes in the QuantumGate API that would break compilation for those who had already been using the library, but these are easy to change and fix. I’ll be updating the API documentation in the wiki on GitHub in the coming days to reflect the latest changes. If you’re using QuantumGate and are having issues, report them on GitHub and I’ll be happy to assist.
Comments
There are 0 responses. Follow any responses to this post through its comments RSS feed. You can leave a response, or trackback from your own site.