New Tor Hosting Upgrade

We have seen an explosive need of our cPanel Tor Hosting. In light of this we have need to upgrade our tor service to be fast and better for our tor hosting customers.

Becauase of this we have built our new tor proxy which includes haproxy via socks which will improve performance.

Our old tor daemon before the upgrade used 1 CPU for the tor daemon. Our new service will use 8 CPUs are we will be running 8 Tor Instances for our cPanel Tor Hosting.

These instances will improve performance 800% based on our current performance specs.

This new service will be rolled out over 14 days and we will slowly migrate customers to this new service. The downtime expected is zero however there may be a delay while the nodes update with the new service.

We will be using HAPROXY voa SOCKS and many other caching that we deem best for our customers.

Our implmentation of our multi-tor script thanks to Trimstray uses multiple Tor processes to ensure faster tor processes. Below is a little from the Github repo.

Multitor was created with the aim of initialize many TOR processes as quickly as possible. I could use many instances for my daily use programs (web browsers, messangers and other). In addition, I was looking for a tool that would increase anonymity when conducting penetration tests and testing the security of infrastructure.

Before using the multitor you need to remember:

• TOR does attempt to generate a bunch of streams for you already. From this perspective, it is already load balancing (and it’s much smarter at it than HAproxy)
• the main goal is masking from where we get by sending requests to multiple streams. It is not so easy to locate where an attacker comes from. If you used http/https servers e.g. proxy servers, you will know what is going on but…
• using multiple TOR instances can increase the probability of using a compromised circuit
• multitor getting some bandwidth improvements just because it’s a different way of connecting to TOR network
• in multitor configuration mostly HAProxy checks the local (syn, syn/ack) socket – not all TOR nodes (also exist nodes). If there is a problem with the socket it tries to send traffic to others available without touching what’s next – it does not ensure that the data will arrive
• TOR network is a separate organism on which the multitor has no effect If one of the nodes is damaged and somehow the data can not leave the exit node, it is likely that a connection error will be returned or, at best, the data will be transferred through another local socket
• HAProxy load balance network traffic between local TOR or http-proxy processes – not nodes inside TOR network

TOR is a fine security project and an excellent component in a strategy of defence in depth but it isn’t (sadly) a cloak of invisibility. When using the TOR, always remember about ssl (e.g. https) wherever it is possible.

‍

 

‍