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â
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.
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.
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.
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 *.privacyguides.org 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?
Fair.
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.
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 privacyguides.net domain to privacyguides.org, 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
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.
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? 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.
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.