[hedora]

Presumably, cloudflare is up to its ears in NSL's, illegal wiretaps, etc. If you care at all about mass surveillance, censorship, oppressive governments (in the US, or the location of the cloudflare proxy) you probably should look elsewhere.

It's probably controversial, but I'd love to see a yellow security icon in browsers when sites are using well known https relays that can see plaintext (or are doing other obviously bad things, like running software with known zero day exploits, etc)

[beardog]

I've seen this argument made a lot lately, and I agree Cloudflare is bad for user privacy, however, adding this warning to browsers by default wouldn't make a lot of sense. Heres why:

Most websites are on virtual servers (hardware in general) that is not owned by them. For example, Amazon could easily let the NSA look into your AWS server directly. IMO, the url lock should just be an encryption auditor. The end website is using acceptable algorithms and has a currently valid certificate? That's good enough.

Almost any HTTPS site can be forged/"broken" (unless they're using preloaded HPKP), if the attacker has root certificates (or even just a bug in a CA website), which the NSA certainty does.

Nation state adversaries just aren't really within the typical TLS threat model. I do concede that it does make agencies jobs much harder if used correctly, however.

[lmm]

I agree that CloudFlare with correctly configured HTTPS is no more vulnerable than AWS or really any popular host. All the lock icon confirms is that data is encrypted while it passes over the public Internet; what's happening inside the server at the other end is out of scope.

CloudFlare's "Flexible SSL" offering means a CloudFlare "https://" site is quite likely to not even have that level of security though. They send supposedly HTTPS data unencrypted and unauthenticated across the open Internet; if that doesn't warrant a yellow/red icon then I don't know what does.

[jacquesm]

A mini audit along the lines of 'builtwith'.

Hm. Good idea, why not go a step further and turn the 'no server signatures' advice on it's head: full disclosure, server signatures on, in fact, list each and every component in the stack so that end users can (through some plug-in) determine whether or not a site is safe to use.

Of course nothing bad could ever come from that. /s

I'm all for making the use of for instance Cloudflare less transparent so that users know who they are really talking to, but I'm confused about how you'd want to establish what a site is running without giving a potential attacker a lot of valuable information.

[hedora]

It would have to work without the site's permission, so the browser (or maybe a third party service) would do a basic vulnerability scan. Maybe orange could mean "a script kiddie could pwn this site in under an hour", and yellow would mean "we don't see how your ISP could mitm this, but server side providers (aws, google, azure cloudflare) definitely could."

FWIW, my personal website uses let's encrypt, so it would be yellow or worse.

Anyway, I like the idea of tying the security color in the url bar to an attacker model, since it at least gets people to think about attack models.

[220]

> FWIW, my personal website uses let's encrypt, so it would be yellow or worse.

This shouldn't effect your security stance.

There's a common misconception that you trust your private keys with your CA and they can somehow transparently MITM you. But they only have your public key, not your private keys, so they can't do that.

The security threat from trusted CAs is that they can MITM anyone, regardless of if you use them or not. BUT the attack isn't transparent, and things like cert pinning are effective in the real world from preventing attacks.

[StavrosK]

The attack is definitely transparent if you trust the CA that issued the MITM cert.

[220]

If you use cert pinning, like the DigiNotar/Iran/Gmail, you're still protected against a trusted CA, assuming you've communicated in the past, which is realistic for a real world attack.

It's an attack that's difficult to deploy because it's easy to detect if you're looking in the right places, and as soon as it's detected, you know the CA has been compromised, and the attacker loses a large investment.

[StavrosK]

It's not as difficult to deploy if you can only target specific users, but I agree with you. The problem with cert pinning is that it's hard to do, because, if you make a mistake, nobody can access your site for quite a long time...

[chatmasta]

Wait, why does letsencrypt allow mitm by server provider?

[rocqua]

Domain validation only requires an HTTP response. They can easily MitM that specific response to fake a certificate for your domain.

[hedora]

Yes. This.

In particular, the company operating the data center your server is in can reliably do this, and so can the backbone provider they use, and probably the server's local government. The DNS provider that controls your domain can mitm the ca process too (though with a higher chance of detection).

The argument for making domain validation yellow (and not red) is that domain validation protects against attacks from residential ISPs / coffee shops, and it would also be hard for a foreign government to launch the attack against their own citizens. They basically have to compromise the CA, tamper with your browser, or just randomly break https with "bad certificate warnings".

Over time, I'd hope more bad security practices (crypto related or not) would lead to yellow bars.

For instance, intel secure enclaves help cloud security a lot, but they are still exotic. If they catch on, and you're at a vps that doesn't offer something like that, then you get a yellow bar starting in 2027.

[pfg]

It's hard to say if you're implying this is any different with other validation levels like OV and EV. The validation methods that CAs may use for OV/EV are the same ones they may use for DV. The only difference is that they also validate the organization's information of the certificate requester. In other words, someone with the ability to MitM traffic between the CA and the target's domain could still obtain an OV/EV certificate for that domain, they'd just have to verify they are who they claim they are on top of that (and they don't have to be the domain owner - there's nothing that says "only the legal entity owning the domain may acquire a certificate for that domain").

[rocqua]

Most of these issues aren't there with DNS based validation (presuming DNS-sec).

Though, that just shifts the potential problem towards anyone in the DNS-sec chain of trust. Most notably, the controller of the TLD (most often a government) and the registrar.

Thing is, those are also an issue with normal (http based) DV. After all, they could also change the A record for the domain they want a cert for.

I believe the current solution to all this is focused on detection rather than prevention (through certificate transparency and similar proposals). The idea being that any organization that isn't trustworthy will only get to pull of this hack once, in a short time frame before having their trust revoked.

[220]

Is there a risk model where you control the network enough to fake domain validation but only if the target initiates the request to Let's Encrypt?

Otherwise it doesn't matter if you use Let's Encrypt as the attacker could just initiate the validation regardless of your CA and end up with a valid certificate (which would still fail cert pinning)

Edit: Oh I see, it's a more about if DV should ever be green.

[chatmasta]

Got it. But this only happens once when you apply for the cert (or renew it), correct?

[rocqua]

I'm not sure if letsencrypt (or other CAs) are willing to give out multiple DV certs for the same domain. I'd guess they do, so anyone that can MitM you and the CA can get a DV cert.

[throwawaysed]

Cloudflare is unquestionably a source of pure, unencrypted traffic for the govt.

Does anyone remember a few years ago when Google found out through leaks that the govt was wiretapping it's private traffic between datacentres?

What makes you so naive to think that the govt isn't sniffing every single page on cloudflare?

[Bartweiss]

A 'counterpoint', such as it is. What makes you think that isn't happening to any 3rd party host you can name? Why single out Cloudflare as adding risk to sites that are hosted on AWS already?

The risk here is real, but it's much more pervasive than one data handler.

[jacquesm]

You seem to mis-understand how cloudflare works. They allow an insecure host to pose as a secure one and the traffic between cloudflare and the insecure host is not encrypted.

That problem would not exist on 'any 3rd party host'.

[manigandham]

CF is the same as any other CDN with TLS termination. Every host that provides a load balancer, or a server, or some other internal network connection like a VPN, can be compromised. Cloudflare is nothing special in this regard.

[manigandham]

The entire internet is built upon thousands of layers. There are so many vectors of entry that no "default warning" would ever suffice.

If your risk profile is outside the boundaries of normal internet use then you likely already know what to do - and we now have a multitude of tools for more private communications.

[apeace]

> Presumably, cloudflare is up to its ears in NSL's, illegal wiretaps, etc. If you care at all about mass surveillance, censorship, oppressive governments ... you probably should look elsewhere.

This analysis seems flawed. If you care about mass surveillance, you want their top-tier security and legal teams working for you.

[dublinben]

Their security and legal teams don't work for you, they work for the company. The company can be drafted to work for the government. Just because you pay them, does not mean they actually work for you.

[dickbasedregex]

Or even that their interests and yours are even remotely aligned.

They sell you a widget/service. That's where your relationship ends.

[dickbasedregex]

That really seems like wishing.

In an ideal world you'd want Youtube's (Google's) legal teams working for you, protecting you against DMCA abuses and alike... but they don't. Not unless you're a top-tier YouTuber and even then it's laughable dice roll as to whether they feel the bad press is worth their time to do anything.

And I don't believe from a bottom-line perspective the shareholders believe it's worth their time to do anything more than provide a platform (no matter how problematic) and market it.

Will Cloudflare do everything they can to keep your content accessible? Sure. Anything above and beyond that? lol. Good luck with that...