Any rebuttal to Simplified Privacy's article "PrivacyGuides Loves Spyware"?

They already exist:

1 Like

This is seemingly dealt with, but honestly, does some crypto-scam-site’s cry for attention actually need a rebuttal? Simplified privacy posted a lot of lemmy for a while but eventually stopped because literally every single post backfired spectacularly.

Shady sites will always try to bash the “big guys” to get some attention, and while I really admire the responses given here by the team, it feels like these guys might not deserve a response.


Any opsec/seceng who sets up Cloudflare knows that it issues these certs and can issue more seemingly on-demand (not a good thing or a bad thing, but it is a thing).

And yet the claim Cloudflare couldn’t MitM is accepted as a “rebuttal” :person_shrugging:

Gotta look at those arguments on its merits. Cyber security is choke full of people who have repeatedly eaten the proverbial humble pie and know well the limits of their own understanding.

1 Like

There are for the .net domain. Not currently on the .org domain. The org domain doesn’t handle authentication of any kind. We could see about re-adding it, there was some reason why we hadn’t.

Unless Cloudflare went malicious and started changing our configuration, enabling proxying. With that threat model in mind they could just start messing with our DNS records and nothing would help in that situation.

That is really the only solution if you don’t trust any of the providers you use. Again though Cloudflare isn’t our threat model because there is no reason for them to be so.


Fair but that’s not what Jonah said. He claimed Cloudflare couldn’t MitM when in fact they can. Then again, what you’re saying now isn’t a rebuttal but an admission of what’s claimed in TFA.

You don’t have to trust Cloudflare to do the right thing (though, they most certainly do). HPKP exists. PrivacyGuides should consider enabling that.

1 Like

You could argue any domain name registrar or managed nameserver could seize/redirect your domain. That is a very public move that only ever happens in the US with appropriate court order, something of which Privacy Guides is never likely to be the target of. We all know what sorts of sites the FBI likes to seize.

Pretty sure HTTP Key Pinning is in decline. It was removed in Chrome 72 and is not enabled in Firefox by default. We do however have HSTS and Certificate Transparency as pointed out above.


The right thing ™ is subjective. If your issue is with a DNS vulnerability that you specifically impacts your privacy experience here, speak candidly about what you are concerned about.

It all goes back to the simple statement “that isn’t their threat model”. For a security model, the threat would have to be that you don’t trust Cloudfate being compromised (if that’s the case, a huge swathe of the web becomes a vulnerable point). If it’s privacy, then the same mostly applies, and using some sort of DNS proxies request is what you want (if that’s your concern, you’d already be doing that).

The argument seems to be about nit picking. Sure - a government spook or malicious actor can theoretically pwn Cloudfare and now Privacy Guides DNS is vulnerable… but is this a legitimate concern or is it about saying Jonah was technically wrong?

Right or wrong, this whole argument is feeling the same people complaining that Mullvad used Gmail for their customer support.


If a PKIX certificate has been issued by Cloudflare for * and if someone still maintains “it isn’t a legitimate concern”, then to them nothing will ever be a “legitimate” concern.

That’s a valid complaint given Mullvad’s marketing and customer base.

Cloudflare MitMing privacyguides can happen independent of whether Cloudflare is itself compromised.

DNS vulnerability? I’m afraid, you’re reading things I did not write, or are confused by something I wrote?


TIL about Chrome dropping support for HPKP. Cert pinning is finicky (like DNSSEC), so no surprises HPKP is gone.

So, it’s a legit concern because if it’s not legitimate then nothing is legit? Ergo, meaning the legitimacy of all other threat models hinges on this one issue?

Of course, that is possible.

With this, is this a concern on behalf of you, or on behalf of privacy guides? And for learning, what would you consider the probability of this occurring, and what risk are you specifically concerned about on the specific behalf entity? Regarding suggested mitigations on behalf of privacy guides, is there a maintenance cost or UX degradation associated with those suggestions that may have negative implications on mitigation?

The original claim by Jonah was that Cloudflare cannot MitM privacyguides because “reasons”. Which is not true since Cloudflare already has a live certificate with which it can (whether Cloudflare is in the threat model or whether Cloudflare is the second coming of St. Peter is secondary).

And every other question you pose are irrelevant as I’m not discussing nor disputing those at all.

1 Like

Alright, so it’s about refuting Jonah, not really about a true threat model… Very well, he may have technically been wrong on a statement regarding MitM with Cloudfare (do we consider it MitM if there it’s just plain distrusting the entity itself?), which is specifically not in the threat mode of privacy guides. I’m sure Jonah will clarify his position to remove possible ambiguity in his original statement.

This bike shed has now been fully built I suppose.

I feel like we’ve just had our wires crossed here. In my mind there is a colloquial understanding of what it means when someone says “Cloudflare is a MITM”: It means that Cloudflare offers products which intercept traffic in the name of performance, and at the expense of an increased attack surface and potential privacy concerns with having your data being managed by multiple parties.

This website (and any other Privacy Guides site where we expect to handle public authentication) does not use any of these products.

We do use Cloudflare Registrar and Cloudflare DNS though, and if you want to focus on the literal/technical definition of “MITM,” it is certainly within their power to hijack the domain/records and MITM the site, yes.

All of this being said, we did use Cloudflare’s hosting service to redirect the base domain to, and as a result Universal SSL was enabled on the zone, which causes Cloudflare to obtain a wildcard certificate for the domain.

We stopped using that service, had Cloudflare delete the private keys to those certificates, and disabled Universal SSL on the zone before this reply was posted here, but yes it was issued, and we’ll have no iron-clad guarantee of it being gone until its expiry date.

Do I think this is a big deal? No, because the main point I was trying to get across anyways is that a product like Cloudflare CDN which “MITM’s” your traffic inherently is a completely different situation than a rogue platform maliciously inserting themselves as a MITM.

Anyways… none of the mitigations you’ve noted here would be adequate protection against this threat in particular, so while we do subscribe to CT logs already and we do (now) have a CAA record which prevents Cloudflare Universal SSL from loading, it will simply always be the case that the registries, registrars, nameserver hosts, and IP space owners will have the capability of hijacking your website on a whim.

I don’t expect that will ever change, but anyone who is concerned about that is welcome to use our .onion website/forum instead, and maybe other networks in the future :slight_smile:


Let’s see if I got it right:

Cloudflare CDN is MITM-ing already in order to offer their services, as they terminate HTTPS and hold the certificates. They could already be snooping in unencrypted traffic and no one outside of Cloudflare can know.

Cloudflare DNS and registrar could MITM by issuing certificates and serving DNS records to IPs they control. If that were the case, it could be known that that extra certificate exists, and that the DNS record is pointing to an address that’s not the one it was set up.




Read the title of this post.

I tried to engage in good faith despite leading questions, and still you attack me in each of your replies. smh

Shouldn’t have added those CAA records, then? :wink: In seriousness, I agree with your assessment that it isn’t MitM in the “malicious” sense of the term. Though, as “rebuttal” to TFA, some form of mitigation was necessary (which CAA now provides).

Thanks for engaging in a thoughtful manner. Appreciate both you and dngray.

This is hard to prevent unless DNSSEC is used by the zone and the client querying the zone. That said, I’m not a big fan of DNSSEC for other reasons.

Firefox has dropped it too. You have to turn it on with an about:config switch security.cert_pinning.hpkp.enabled. Not even Arkenfox enables this. If you want it the user has to expressly have enabled it. It does seem like they haven’t yet removed it entirely though:

So there are no browsers that actually support it, or even supported it in the first place left.

This will probably happen when they get around to

which largely replaced HPKP.

1 Like

Apologies - I interpreted your replies as trolling, and eventually just wanted a clear answer. That is my bad. It felt like a bike shed drilling into a non-issue, but if you were actually trying to resolve ambiguity then that makes sense.

1 Like