Topic: Mixers using cloudflare's SSL certificates (Read 736 times)

I noticed the missing images last week. May I recommend TalkImg.com - Image hosting for BitcoinTalk?

I'll delete this post next time I see it.

@Faisal2202: an interesting thread you have there... I currently have quite a lot on my plate, but i'll try to contribute to it in a while (no promises tough).

This topic was written after reading techical documentation about cloudflare and by asking questions (and reading other people's replys) in the cloudflare forums. Also, some of the things are just knowledge i acquired over many (many) years.  As you can see, the topic already a tad bit older (but everything is still valid), and after i stopped renting a dedicated server, the images are down aswell (i still have them somewhere on disk, but i'd have to upload them to another server sooner or later). To be honest, i didn't bookmark the exact pages i studied to write this topic, the images that used to be on this page are mine (i created them myself), so they're not on any other page either (at least, i don't think they are, unless somebody downloaded them and uploaded them to their own server).

About the mixer that was recently banned (i guess you mean chipmixer?)... Well... What can i say... I personally think good mixers are an important and valid service in our community. They provide me with security against a $5 crowbar attack, as well as from begging and they provide privacy when i'd ever want to use legal services that are frowned upon by some. It's my money, and it's nobody's business how much i own and where i keep it (nor how i spend it, as long as i spend it on legal things)...  

That being said, *some* governments see privacy as something evil they have to combat. Instead of trying to capture and punish criminals, they decided to go after privacy tools that are sometimes used by criminals, and they don't care if they hurt innocent people that just want privacy for their own protection in the process. I'm very much against this kind of thinking, but i don't think i can change it...

Crypto users are still a niche, and attacking them seems to score big popularity points for populist politicians from the general population, so i don't think they'll stop any time soon.

Personally, i'm not a lawyer, and the laws by itself might be completely different from country to country. I hope "BOB" doesn't get in trouble, but there's no way of telling... I, however, am a big fan of mixers as long as they're used for privacy protection, but i probably won't be promoting any particular mixer or mixing process in the near future. Even tough i completely disagree with the governments stance against privacy tools, i have a job and a family, and i'm going to try not to end up in jail by doing stuff my government deems illegal (even if it's just populist dribble).

Dear op, i just want to admire the efforts that you had made on this compilation, i mean like you really cleared up many things that were confusing me, and now i can check which website is using CF and GA,  this whole experience of reading all of your posts and replies was great even, tomorrow i have to submit an assignment of " c++ code for DES and Caesar cipher encryption and decryption" i have known the procedure but DES is a little bit difficult but here i am reading your posts,(haha) first i thought i should make my assignment but this attracts me more.

I have also made a topic of All you need to know about Mixer before using it but i think i should put your thread in mine as to give other more idea which i will add.

I am just curious, what are your thoughts, about a mixer which recently banned and what if a person was unintentionally received rewards from a mixer and that person was "BOB", will he be questioned, as he received BTC from a mixer? I mean, if yes? then how one (whose address is publicly available) can avoid such incoming transactions. (i am not an expert but just a pro learner) So, please ignore my childish words.

And, can you point me out to some more cool reading about how cloudflare actually decrypts and encrypt data from both sides and make keys, and how we can know which to trust, as i think your sources will save my time (just a request, you can ignore it too).

yes... I didn't think about this attack vector... But it's true... Every package you sent is encrypted using a symmetric key shared between the client and cloudflare, then cloudflare decrypts the packages and re-encrypts them using a symmetric key shared between cloudflare and the host.

Cloudflare can, in theory, inject malicious code into any website that uses their proxy... Including but not limited to the code used to generate keypairs.

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

Would it be possible for the MITM to change the code that is being used to compromise the client's private key? I'm no expert on this, but in my understanding, the code that generates the private key locally can be read by the MITM, right?

Using Tor browser becomes more and more annoying because of Cloudflare, far too many websites website nowadays show the Cloudflare loading screen.

Isn't the real problem the millions of compromised computers that are part of those DDOS networks?

I didn't know it was possible to do this. As for to slow down the experience, we're talking in milliseconds, it is negligible for the UX

But in 2023, I'm still puzzeled to see Cloudflare having the majority of the market. CF is everywhere, it's like a mafia lol.
Incapsula for exemple is far better with performances. Sure it's a costly solution, but I'm just saying there are alternatives doing the same job.

Thinking about it:
- the structure of a DDOS attack is decentralized
- the architcture of a DDOS protection is centralized
- these big fat centralized anti-DDoS companies rule the web. Some companies can't survive without them

https://ieeexplore.ieee.org/document/8436643

So it basically boils down to creating an asymmetric keypair client-side, sending the pubkey to your server and receiving the pubkey from the server's keypair, then completely encrypting every package inside your browser before sending it to you and only receiving encrypted packages from you which can be decrypted using your privkey.

If it is set up correctly, i guess that approach would be ok... It's still a tad bit early for me, but for now i don't see any real problem... It does feel like it's going to slow down the experience, and you'll probably have to make sure to respond to any vulnerability that's discovered anywhere in the complete stack... But it's defenately a lot better than just using cloudflare.


Convenience... Lazyness... Incompetence maybe?...
I don't get it either, but still, a lot of them are using cloudflare and their main reason seems to be "other are doing it to, so i don't see a problem"
As far as i can tell right now, it seems like whirlwindmoney might have found a way to combine convenience with security, but i do wonder if it'll come at a price (usability, speed, maintainability,...). Time will tell

I really wonder, a company that calls itself Mixer, should expect illegal activities too, it's just inevitable but by implementing CloudFlare and Google Analytics, how can the mixer owner feel safe? You are cutting the tree where you are, you are making guillotine ready for you and your customers. So, why? I just don't get it.

I like you guys, you really come up with unique ideas, with something that others haven't done. That can be a good solution for this forum too because it uses cloudflare and as far as I know because of CF, our PMs are not actually private.

Apologies for bumping this old thread but we are curious to know your opinion on our approach, I'll quote the message from our ANN thread explaining the details:

theymos explained us several times why he is taking the service of cloudflare and I think we all came to this understanding that we are okay with that.

I personally use TOR for every possible service I can, so I am not much worried, but we were talking about mixing service explicitly in here. For them it's a NO NO without any doubt. Anyone who is using the mixing service but do not know the damage adding cloudflare can do, after reading this post I do not think they will use the service who has cloudflare. At-least not me bud.

I think now it makes sense why chipmixer is spending too much money in their signature campaign every week. It's all about sending your brand in front of the potential group of people. A bitcoin mixer can not rely on traffic coming from a search engine who are dominating the entire web. I really hate google, sorry.

I am not sure why you are so against Cloudflare, probably theymos can tell us how much they have saved bandwidth of trash traffic has on this forum, just because of Cloudflare. I agree that is no sense to use such a service where anonymity is expected. but it pretty good doing their job.



You will spend too much time to check every page, do they have CF SSL and Google analytics, it can turn into paranoia. OK, I agree to check, where is privacy expected.
I guess 95% of all serious websites use GA. it has become a mandatory part for any further page optimization.

Thanks, I found both (checking cloudflare and Google Analytics) and discovered that bitcointalk is not using Google Analytics which is a good thing.

It seems I was wrong judging them earlier. Good to know.

It's not used only to handle high traffic but BTC mixers are targeted with DDOS attacks perhaps more often than Bitcointalk is, especially if it's popular service. The more popular it is, the more DDOS it gets. I think they also use it to hide server IP
Between blackmail extorsions, I even suspect that some Mixers attack other Mixers, among other methods they use

Thanks

Don't worry about the merit, i mainly wrote this post because i was getting sick and tired of the discussion with mixer operators. I wanted to write a big, complete writeup, so i could refer them to this post the next time i got into a discussion with one of them.

As for the cloudflare ssl, it's pretty easy:






Google analytics is a little bit harder:
open the developer tools of your browser, go to source (layout and wording might differ between several browsers)

I realise this picture show my own site, and i'm far from perfect... I also use google analytics on mocacinno.com, because it's basically a site hosting some free tools and a blog... I don't handle anything "sensitive", so i decided to take the "easy" road.

The main reason people use cloudflare and google analytics is convenience... Cloudflare gives you easy tools for managing your dns records, it helps you setup your nameservers with your registrar, it holds your hand while setting up SSL (if you use the flexible option, they even hide the fact that in reality you're a non-https site, and make it look like you're an ssl site), it gives you all these plug and play tools, it's cache saves you bandwith, to a certain degree they offer some DDos protection,...

Google analytics on the other hand, is one of those cloudflare plugins... Just enter your id in cloudflare, and GA will be enabled on each and every page... You get insight in your data in just a couple of clicks, you don't even need "real" analytic knowledge, everything is spoonfed to you.


On the other hand, if you want to do things "right", you'll have to use letsencrypt to get an X3 certificate, you have to setup cronjobs, you have to make sure your setup is done properly (or the letsencrypt bot won't work). You'll have to set up matomo (previously piwik), you have to enable privacy plugins, you have to clean up your database, you have to truncate logs, you have to find your own way in DNS zone management, you have to purchase DDos mitigation (if needed). It's hard work, it's defenately more expensive than the one-click-sollution cloudflare offers, but if you run a privacy-centered service, i don't think you should trade in your user's privacy for your own convenience... As a matter of fact: the mixing fee you charge is the payment you get for NOT making a tradeoff.

This says everything. This is stealing IMHO. I always hated cloudflare and services like this. I also do not like theymos to use cloudflare for the forum but that's a different story.

For a mixer site, I do not see they really need to worry about DDOS attack much. The sites do not need to handle much traffic as busy sites like this forum or some blogs or e-commerce sites but still I have no idea why a mixer site needs cloudflare's SSL? If privacy is the one and only goal then adding this layer is killing everything.

You deserve a big shot for this topic I mean a lot of merit. Even 50 merit is not enough but I ran out of my sMerits and it's a shame that I had to give you only one because that is what I had left.

Now, my question is - how to I find a site is using cloudflare's SSL and Google Analytics?

Cheers,

Part 4: A fictional example of somebody in a country where crypto is banned, using a cloudflare-ssl-using mixer with google analytics included,  and some general conclusions

Meet Bob, Bob is an IT expert that lives in Algeria. Bitcoin is illegal in his country, but it seems Algeria has strong relations with the US.
Source: https://www.state.gov/u-s-relations-with-algeria/

Bob's family is poor, he has no money to buy food or medicine. One day, Bob has the opportunity to do some legal work online, but the only requirement is that the job will be payed in bitcoin.
Reluctantly, bob creates address 1BobDirtyXXX offline and receives enough bitcoin to buy half a year off food (let's say 0.5 BTC) . However, he's paranoid cause bitcoin is illegal in his country and he's afraid of ending up in jail. Offcourse he doesn't want to throw away such a huge amount of money, maybe one day the rulers of his country will revisit their laws and change bitcoin's status in his country, and on that day he has enough money to buy food for his family.

Bob decides to mix his coins for safekeeping, and creates address 1TotallyAnonymousxxx to hold his mixed funds. Nobody should be able to tie this address to him, if his governement finds out he's in big trouble. He goes to bitcointalk and find mixer i-am-a-mixer-that-uses-cloudflare-ssl.com (perfect tld isn't it). The mixer has moving images, bright flashy colours, an affiliate program, ajax, jquery, using the laravel framework, has naked pictures of his favorite celebrity,... you know, the works.

Bob opens i-am-a-mixer-that-uses-cloudflare-ssl.com in his browser. In the background, a handshake between him and cloudflare is initiated, a symetric key is generated and everything looks perfect to him (mind you, he's an it expert, not a security expert). The index page is served to him from cloudflare's very own cache. Speedy as a bullet and supposedly DDos protected (altough cloudflare doesn't offer guaranteed DDos protection to their free tier   ). Luckily the owner of i-am-a-mixer-that-uses-cloudflare-ssl.com was smart enough to include google analytics (how can you live without those stats) and a remotely hosted jquery aswell... Maybe he trew in some other remotely hosted scripts, who will tell?

Bob gets a rendered version of the data he received from cloudflare, sees the form to start a mixing session, and enters address 1TotallyAnonymousxxx as an address where he wants to received his mixed coins, and posts this data back (to the mixer's server, at least that's what he believes... In reality, the data is sent to cloudflare).

The package including address 1TotallyAnonymousxxx is encrypted with the key shared between his browser and cloudflare. Cloudflare decrypts the package and stores it in it's cache (hooray). Cloudflare then contacts the server that's actually hosting the mixer and creates a new symetric key with him, the package containing 1TotallyAnonymousxxx is re-encrypted with this second key and sent to the mixer.
The mixer replies with data containing address 1DepositYourDirtyFundsHereXXX. This package is encrypted with the symetric key shared between the mixer's server and cloudflare. Cloudflare decrypts the package, stores its content in it's cache (in case they need the data), re-encrypts the package with the key shared between cloudflare and Bob and sends the re-encrypted data to Bob's browser.
Bob funds address 1DepositYourDirtyFundsHereXXX with the unspent output funding 1BobDirtyXXX. After an hour he receives 0.49 BTC (mixers are not free ) on 1TotallyAnonymousxxx.
Offcourse, the pages opening in his browser also request content from google analytic's server and the servers hosting jquery. So google now has his ip, timestamp, the pages that are illegal in his country that he visited, his browsers fingerprint, the site he visited before visiting i-am-a-mixer-that-uses-cloudflare-ssl.com, the site he visited afterwards,... You know, everything.

One day, Algeria's secret police decide they don't like Bob. An IT expert is not good for national security, maybe they can find something they can use to arrest and torture him and his family? They turn to uncle Trump and ask him if he has some juicy inside info on Bob. They have already demanded Bob's ISP to turn over at which timestamps which ip leases were given to Bob's modem, and they pass this ip info over to an unnamed US 3 letter agency.
This 3 letter agency asks google and cloudflare if they can do some digging in their caches. Since it's a 3 letter agency, both companies answer within the hour..
Cloudflare is able to tell the 3 letter agency that Bob's ip was used to create a session on i-am-a-mixer-that-uses-cloudflare-ssl.com. In their cache they find that i-am-a-mixer-that-uses-cloudflare-ssl.com created deposit address 1DepositYourDirtyFundsHereXXX and that the mixed coins should go to 1TotallyAnonymousxxx. On blockchair they find that 1DepositYourDirtyFundsHereXXX was funded with an unspent output funding 1BobDirtyXXX.
Google is able to tell them exactly which timestamp, which browser, which pages, some clicktracking, which pages he visited before visting i-am-a-mixer-that-uses-cloudflare-ssl.com and which ones afterwards,...
The 3 letter agencie give this data to Algeria's secret police, they torture and kill Bob's complete family... Ooops.

Conclusion: i-am-a-mixer-that-uses-cloudflare-ssl.com has royally screwed Bob. They taught that because everybody was making the mistake of implementing a MITM and including outside scripts, they could make the same mistake, but by doing so they actually, literally killed their client. As a matter of fact, the client would have been much safer if he didn't mix his hard-earned coins.
Ethically, Bob did nothing wrong... He didn't use his due diligence and figured out a MITM is a bad idear, he followed advice he found on bitcointalk and the naked pictures of his favorite celeb.

Mixers: use a free x3 certificate, and locally host matomo WITH privacy plugin and regular truncates for your tracking needs... Buy DDos mitigation hardware if you can't live without this, but don't kill your customers by exchanging the convenience of a one-click-sollution for the privacy of your customers.

Part 3: A https site behind cloudflare (where security goes wrong)
1) you contact your DNS and resolve mixer.tld. Instead of getting the ip of the mixer's server, you get the ip of cloudflare... Tricky isn't it?
2) you send unencrypted data to the CLOUDFLARE server, this data includes some random data, some (more or less) boilerplate stuff and a list of cyphers your browser supports

3) the CLOUDFLARE server sends unencrypted data back, this data includes some random data, some (more or less) boilerplate stuff and his public key

3.a) you can verify if this CLOUDFLARE key was issued by a CA you trust, and the browser can show a warning message (which you can disregard) if this isn't the case
4) a symetric key is generated between you and cloudflare
5) if you actually request a page, or post data, it is encrypted with the key from step 4. CLOUDFLARE decrypts your data and looks if he can reply with content from it's cache (yup, cache). If not, cloudflare acts as a client and requests data from the mixer's server. semi-ideally, they run in full or strict mode and they repeat step 2-4 to generate a new, symetric encryption key between their server and the mixer's server. In flexibel mode, they even request data over non-https!!!
So, semi-ideally, it would look more or less like this:


You see what's wrong with this picture? Even in the best-case scenario (cloudflare-wise), cloudflare decrypts EVERY package that's meanth for the mixer's server, it caches everything and it re-encrypts the request if it cannot reply with data from it's cache. Eventough the node operators cannot decrypt your packages, cloudflare has a big datacenter filled with UNENCRYPTED data that can link "dirty" and "clean" wallet together. This data was meanth to be seen only by you and the mixer, but because the mixer chose convenience over security, your most intimate and private financial data is now stored somewhere in the datacenter of a big, us-based company.
Even worse, eventough the network node operators cannot decrypt your packages, they can still capture them. Cloudflare has the symetric keys, so if they get their hands on those keys (due to law enforcement getting involved, hacking, social engineering,...) they can still decrypt any historical packages they captured.

Cloudflare is a US based company, the US is known to be very lenient in privacy-matters when 3 letter agencies get involved. Cloudflare is also a big company, with many employees and many attack vectors... Social hacking, stealing employees, security flaws,...?

Part 2: A https site using it's own certificate (aka, best case scenario)
1) you contact your DNS and resolve mixer.tld
2) you send unencrypted data to the server, this data includes some random data, some (more or less) boilerplate stuff and a list of cyphers your browser supports

3) the server sends unencrypted data back, this data includes some random data, some (more or less) boilerplate stuff and his public key

3.a) you can verify if this key was issued by a CA you trust, and the browser can show a warning message (which you can disregard) if this isn't the case
4) i'm going to omit some technical data... But the client and server now exchanged random data, the client has the server's public key and the server has his private/public keypair. With this data, a symetric encryption key is generated, the server's public key is used to encrypt the communication from client to server, so this symetric key is not sent in cleartext
5) from now on, every package sent between the client and the server is encrypted with the key from step 4. Once again, this symetric key (generated in step 4) was NEVER sent in plaintext. It was encrypted with the server's public key before it was transmitted from the client to the server. If a node operator captured these packages, there was no way for him to extract the symetric encryption key from the packages he captured. (Once again: grossly oversimplified)

6-x) analogue steps as in part 1 (non-https)... BUT, the big difference between part 1 and this part is that every package that's being routed over all those different nodes is now encrypted, and can only be decrypted by YOU or by the mixer's server. You'll request pages, get pages containing deposit addresses, post your withdrawal address,... But every package going over all those network nodes is encrypted using a symetric key only known by you and the mixer.

You see why this is better? Eventough law enforcement or datacenter operators can still capture the packages containing the deposit or withdrawal addresses, these packages are now encrypted. They cannot read their content. Only you and the mixer know which wallets are linked together. As long as the mixer is honest, you're relatively secure. This does NOT mean your ISP doesn't know you visited a mixer tough! They can still track your surfing habits, they just don't know the actual data being exchanged between your computer and the mixer's server. If you want to hide this from your ISP, i'd probably start looking for reliable VPN providers, start to use the tor bundle, or a combination.

Part 1: A non-https site
In the olden days, you'd see a lot of non-https sites... If you visited them, this is what happened on a deeper level (some steps happen in the background, so you don't notice them... Once again: oversimplified).
1) you contact your DNS and resolve mixer.tld
2)You send a request to the mixer, it goes trough a lot of network nodes to reach the server hosting the mixer. This request is an unencrypted piece of "text" requesting the index page of the mixer

3) The mixer sends you their index page, as an unencrypted piece of text. This piece of text goes trough a lot of network nodes to reach you. The index page contains a form where you can enter your address where you want to receive the mixed coins

4) you fill in your address, and post the result back to the mixer's server. The data you send back to the mixer is packaged in an unencrypted text and it goes trough a lot of nodes to reach the mixer

5) The mixer send a page to you that contains the address where you need to deposit your "dirty" coins for them to mix. The page also contains a link to their letter of guarantee. Once again, the page is basically sent as a long piece of text, completely unencrypted, and it passes trough a lot of nodes

6) you request the letter of guarantee. Once again: piece of text, unencrypted, lots of nodes.

7) you receive the letter of guarantee. Once again: piece of text, unencrypted, lots of nodes.


Does anybody see the problem? No?
Well, any network node can capture these packages and can read, in clear text, what you've requested from the mixer, and what the mixer replied. If you'd use a mixer over a non-https connection, everybody between you and the mixer knows that funds deposited to the deposit address will be sent to the withdrawal address and can now link your "dirty" and "clean" wallet together. If you ever spend funds out of your "clean" wallet, and it contains even one input that can be linked to your "dirty" wallet, your privacy is gone... Multiple inputs can be used together, change addresses get generated, and every law enforcement agent, many data center operators and loads of hackers now know your complete wallet's content.

Do you think i'm paranoid? Read this and wheep: https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/