In spite of promises and several decades after, Cloudflare generally failed to address the issue of anonymity by handling tor connections, indirectly hitting to the fact that the explicit de-anonymization of users is, in fact, desired, such that there is not much left to do except drop all Cloudflare handling and access websites that run through Cloudflare directly without going through tor. The only other option is to simply not access websites using Cloudflare at all.

Of course, this solution is not a solution regarding privacy but if you ever browsed the Internet using Cloudflare websites, you would know that an atrocious amount of your lifepsan (the human lifespan) is expended on solving CAPTCHAs, such that at the very least, this way will spare you that time and still use anonimity for websites that do not use Cloudflare. Most of the time, seeing the petty CAPTCHA, it becomes a psychological test where you self-evaluate whether your time is worth the de-anonimization and maybe you should just turn tor off and visit the website directly, especially given that lots of content seems to de-duplicated on the Internet and most of the time when that happens, the website tends to run through Cloudflare (plagiarism, and crime, go hand-in-hand with paranoia).

Due to the Cloudbleed attack, a list of websites using Cloudflare is publicly avaialble (and mirrored locally) with about 3 million entries. Another source is a website named SecurityTrails that offers a curated list (mirrored locally) using their own analysis engine with another 4 million entries.

The two files can be merged and only unique entries kept (about 6.5 million entries), and then the list of websites can be used to create SOCKS routing rules in order to access these websites directly whilst accessing the rest of the Internet using tor.

The obvious drawback is that these lists are not really updated and we've been unable to locate a stable and publicly available source. On the other hand, once websites go with Cloudflare, it is unlikely that they would switch back. Outsourcing is more of a state of mind. . .

There are several alternatives:

• privoxy that can peek into the TCP CONNNECT request of a SOCKS connection, determine the hostname to connect to (if any) and then send the connection to an upstream SOCKS server (or HTTP) or access the website directly,
• compile Squid with SOCKS proxy support and then build an ACL using the list of Cloudflare websites and just access the Cloudflare websites directly and any other website via tor,
• use privoxy as an HTTP proxy and then use the Cloudflare website list as an ACL to access the Cloudflare websites directly whilst other websites are accessed through tor

The topology depends on what capabilities are available and how the various solutions scale. For example, using privoxy via a Docker swarm to sort the requests depending on whether they have to be fetched directly or through tor, traffic destined for anonymization is piped into "haproxy" that then schedules the connection to available tor servers running within the same docker swarm.

             +---------+
             | IPVS IP | IP: 192.168.1.80
             +----+----+
                  |
                  |
------------------|-----------------------
                  |
           +------+-------+
+----------+   privoxy    |
|          +------+-------+
|                 |
|            +----+----+
|            | haproxy |
|            +----+----+
|                 |
|                 |
|      +----------+---------+
|      |          |         |   
|   +--+--+    +--+--+   +--+--+
|   | tor |    | tor |   | tor | . . .
|   +-----+    +--+--+   +--+--+
|      |          |         |
|------|----------|---------|-------------

Internet
        

privoxy can be used to access domains that use Cloudflare directly and then pass everything else through tor. Configuring privoxy for this usage is fairly trivial with little configuration options necessary. The main config file must be changed to contain only:

# useful to observe errors from docker terminal
logfile /dev/stdout
debug 2
actionsfile /data/config/cloudflare.action
listen-address  0.0.0.0:8118
forward-socks5t /       tor.tld:9050    .
toggle 1
tolerate-pipelining 1

where:

• /data/config/cloudflare.action is the absolute path to a file containing the cloudflare domains to access directly,
• tor.tld:9050 is the FQDN and port number where tor can be found,

The file /data/config/cloudflare.action will contain the domain names prefixed with a wildcard (*) with a single line at the top indicating to skip forwarding the traffic to tor.

Here is an excerpt of the /data/config/cloudflare.action file:

{+forward-override{forward .}}
*000000000000000000000000000000000000000000000000000000000000000.co.uk
*000000000000000000000000000000000000000000000000000000000000000.host
*0000000000000.pro
*000000004.com
*0000000xpj.com
*000000907.com
...

Overall the list works perfectly, with many important show-stopper domains being accessed directly rather than through tor. The main worries here are domains that serve as CDNs or domains that contain vital content that is shared amongst many different websites (Google trash, etc).

One of the problems stem from the very large file of domains that tends to be typically loaded up by software such as privoxy or socks-router and maintained within structures in memory ending up eating up far too much RAM than would be acceptable. This issue should be addressed somehow because it seems very detrimental to running such as list.