If you say you didn't catch them on spoofing your website, I can believe you. If you say you've never heard about them altering the contents of a single http request, this still sounds plausible because it is hard to detect such alteration. But if you say you've never heard about them cutting off pieces of webpages by breaking some of the (many) http requests a browser makes when it loads a (single) page, thus also damaging webpages' integrity, I will not believe you. Cloudfare does this all the time, and this is easily detectable by looking at the list of http requests and their results in "web developer tools" in a browser.

Your website doesn't have to be even the first case of altering the contents of a single http request. If you don't know about such precedents, this doesn't mean they don't exist. They may just stay completely unnoticed if the admins of those previous websites don't access them from various IPs.

This is better than what you said before "automatically shut down the clearnet version" (without any plans for the future), but still, the only price for cloudfare we are sure about is just one website leaving them. You are taking for granted that this is "the complete opposite of 'not too bad' for Cloudflare", while this is doubtful to say the very least, especially given the fact how obviously they damage other websites, as I explained two paragraphs above. What's worse, you put your users safety in dependence of the actual validity of this claim that you just take for granted.

I'm not ignoring anything, it's just you pretend I'm ignoring. As long as cloudfare has 0% false positive, their attack does not contradict your observations you describe here. Once 1% false positive happens, your observations will not anymore be the same as you described here until now. But this alone does not yet mean that 100% accuracy is necessary for cloudfare for all the time in foreseeable future. In simple words: they could have some luck so far.

Unless your server is closely monitored by a third-party, you will not have undeniable proof for anyone except yourself. Cloudfare can claim that it were you who put the damaged files at your physical server, and you will not have evidence it wasn't there. And if someone else independent closely monitors your server and can witness that the files there were not changed, this is even worse, because this third-party access is also a danger for the security of your users.

It is relevant: absence of remote access and distance from your physical location means lower a priori probability for cloudfare that you are testing them, they can rely on this information.

Again, it is possible. At some point cloudfare might get caught, but before that they will have already collected a "large scale" of users' data.

You can call my criticism "invalid" as much as you like, but I still can (and do) warn other users about the risk of their data being accessed by cloudfare.

Of course. To check that cloudfare sends your website the same way to various IP address, you (or someone who you trust) need to have either physical access to that requesting IP address, or remote one. This is not my assumption, misunderstanding, or misinterpretation, this is just how internet works. Speaking of particular ways of checking remote access, the three I mentioned were the most obvious examples (and they often can be checked even without being cloudfare and without controlling the outgoing traffic from your various IP addresses), but cloudfare definitely had more time to think about this detection as well as much more data to analyze, including the outgoing traffic. This way they can check the computer knowledge level of the users at that IP as well.

Again, this is wrong. The price of a "false negative" result of a check by cloudfare (they think you are checking them for spoofing, while this was a third-party user trying to mix his or her bitcoins) is just that they miss the tracking of this particular user and will not be able to reprt him or her to the authoriries in the future. This will not prevent cloudfare from tracing and reporting other users.

And the price of "false positive" (you are checking, but cloudfare doesn't recognize you) is not too bad for cloudfare either. At worst, they will lose your webiste if you decide not to use their "ddos-protection" ever again (and even this you don't say, you just say "automatically shut down the clearnet version", but you don't say how long you are going to keep it down). As for the other webistes they MITM/"ddos-protect", your observation of spoofing will not really have much effects with cloudfare's already-terrible reputation. And for your users who already mixed their bitcoins, it will already be too late.

So, 100% accuracy is not necessary for cloudfare. Even 30% false negative with 0% false positive does not contradict the observations you say here, in this thread.

Where did you say it's temporary? If it's temporary, then: as long as you collaborate with cloudfare, this continues to be a battle of shield and spear at best, for all of the period you use cloudfare.

I agree with this. But I don't think it's a good reason to introduce one more attack vector. You could disable https altogether with the same reasoning.

If your server is not on-premises, this is one more attack vector, yes.

A side-remark is that if there is no tampering with distribution of the tor address of your server, and there is no tampering with distribution of tor browser itself, then this is as secure as your own open-source app.

It is possible to organize an attack that will allow cloudfare to know the connection between a certain percentage of incoming and outgoing mixing transactions, even if not all of them.

This I don't know and I think is impossible to know for now. This is a "social" question/"question of trust" rather than a technical one. I think it is impossible to know the answer before either the copyright supporters fight against us much more openly than now, or something really revolutionary or disastrous causes them to lose power. Most terrible activities of the authoritarian regimes of the past typically became known only after the regimes have fallen.

No. This way, an obvious next move for cloudfare is to spoof your website for all requests from IPs that are far away from your server's one and from what cloudfare thinks is probably not remotely accessible (no vpn server, no tor node, no datacenter - they control a huge part of the internet traffic, it's easy for them to collect this kind of statistics). Or they can add one more condition for contents alteration: they alter the contents only if their estimate of the user's computer knowledge is low. Then even verification of your webiste by someone living far away (but without remote access to their computer) will not help. Once you start to collaborate with cloudfare, this will be an eternal battle of shield and spear at best.

If they alter a particular http(s) request so that it looks "correct at a first glance", this will be really hard to detect, and I don't know such cases. But when you open a typical webpage, your browser makes a lot of individual http(s) requests. And what cloudfare is really doing all the time is that they randomly ban a small percentage of these requests (you can see this in firefox's "web developer -> network"), essentially cracking out small pieces of the pages, breaking and altering websites' behavior for the users, sometimes to the extent complete loss of usability.

(Technically speaking, when they show their "standard ban page" instead of the whole website, they also modify the http(s) response conents, but I think you were asking about something not so obvious.)

For me, this sounds like a really outdated idea, unfortunately. Most of the present-day internet is controlled by a very small number of very user-unfriendly companies like cloudfare, google, facebook, etc. It would not be a problem for them to censor out such an outcry. Even if they don't stop the spread of information entirely, it's not a problem for them to limit it to just a small number of sparse complaints at random forums.

If you are collecting the opinions here, I will cross-post my post from your ANN thread also here:

In brief, I think that the approach by whirlwind.money is not a reliable defence against cloudfare's MITM. I already wrote some more details in whirlwind.money's ANN thread, here.

Or do you mean, you are suggesting to repost this detailed opinion from the ANN thread to the thread where they are "collecting opinions"? I am new at this forum, I don't know what is common here.

It seems to me that you underestimate the ability of MITM attacks on your traffic. When cloudfare MITMs your traffic, they can do anything with it. I mean, really, really anything. Generally speaking, nothing prevents them from MITMing your "second layer of encryption as well as the first one" and sending a fake public key for your ECC to the user. They can also remove the ECC encryption entirely. Theoretically, after that they can even send a fake bitcoin address to the user and seize the BTC the user was going to mix (although in reality, I doubt they are ready to act so openly yet).

With your current design, the easiest technological solution for cloudfare is to access your on-premises server via tor after they receive a HTTPS request to their "ddos-protection" MITM server. Nobody will notice anything. The clearnet user will just see a bitcoin address and send BTC there, and you will see in your server logs that someone accessed your server "via TOR". Nobody will notice anything before the user suddenly gets arrested a few years later.

I have checked the webpages of the 4 recently added mixers, and all of them look cloudfare-related.

1. webmixer.io and whir.to show the standard cloudfare's anti-TOR page, the traffic is definitely MITMed by cloudfare.

2. whirlwind.money and puremixer.io don't show the cloudfare's anti-TOR page, but the IP addresses these domain names point to still belong to cloudfare, which raises the same suspects as in part 2 of my previous message.

Summarizing, there is only one mixer in the list left that does not show signs of the traffic being MITMed by a "ddos protection system", anonymixer.com, but now it looks dead, neiter the clearnet page nor the tor page works. All alive mixers show weaker or stronger sings of MITM.

By the way, the link to anonymixer.com's thread at this forum in the opening post does not really link anywhere. It's just plain text, not a real link.

Hi guys,

I'm trying to find a reliable bitcoin mixer, and my concern is the following. If the software of the mixing website is run at a hosting/vps-provider-owned server, not at a home/on-premises server owned by the mixer admins, then the hosting or vps provider has full access to the logs. In other words, we have to trust both mixer admins and the hosing provider that they don't send the pairs "input mixing transaction - output mixing transaction" to the governments. The same concern raises if the webiste is run at an on-premises server, but there is a vps/vpn/hosting provider who MITMs the traffic (officially this is usually called "ddos-protection").

I checked the websites in the straing post, and I see the following.

1. Most of the mixers show the standard cloudfare's anti-TOR page ("checking if the connection is secure...") when I open their clearnet versions through TOR. This is a 100% sign that cloudfare MITMs the traffic or runs the whole website software. And these mixers allow mixing through clearnet, effectively giving away the users' data to cloudfare. These are: https://coinomize.biz/, https://mixer1.money/, https://mixtum.io/, https://mixy.money/, https://sinbad.io/en, https://mixero.io/

2. At three more mixers, I didn't see the cloudfare's anti-TOR page, but when I DNS-resolved their IP addresses and navigated to this bare IP address, I saw one more standard coludfare's page "Direct IP access not allowed". So, cloudfare is still involved. Theoretically, this does not imply MITM so directly as in the previous case, but I'm not sure whether coludfare provides any service at all that redirects TLS traffic after SNI to an on-premises server, I think they are a pure hosing provider (if they redirected TCP/IP traffic to an on-premises server, we wouldn't see cloudfare's pages when accessing the bare IP, and I don't think they offer TCP/IP redirection either). If they indeed don't offer TLS traffic redirection after SNI (does anyone know this for sure here?), then cloudfare still has access to all data of the users of these mixers. (And yes, these mixers still accept bitcoins via clearnet.) These include: https://mixer.blindmixer.com/, https://mixtura.money/, https://unijoin.io/

3a. One more mixer, after a similar check (resolve DNS, navigate to the bare IP), shows some not so common page saying "DDOS-guard". Again, I'm not sure and I want to ask the people here: is there any "anti-ddos" software available that is intended for installation at an on-premise server? Or is such a page at a bare IP address again a sign that the website is run at a hosting provider's server? This mixer is https://cryptomixer.io/, IP address: 185.178.208.139, still allows mixing through clearnet.

3b. One more mixer behaves very similarly, except that instead of a page saying "DDOS-guard", it replies to a bare IP request with a page saying "bad gateway", which has a self-signed SSL sertificate issued by "ddos-guard". This is: https://yomix.io/, IP address: 185.149.120.23

4. There is 1 mixers in the list left that look a bit better than that: https://anonymixer.com/ (IP: 185.193.125.108, with a bare IP access: no response on port 80, port 443 replies with an SSL-certificate of anonymixer.com), so no direct signs of a provider-owned server (or maybe I just don't see one?)

By the way, who do some of the TOR links in the start post point to v2 TOR addresses? They are not supported by the TOR network anymore, unfortunately. Even if you prevented you local tor package from updating, the middle tor noe operators typically didn't do so, so v2 TOR addresses are more or less unreachable now.