Certificates with Cloudflare, Inc. in subject

[Michel Le Bihan]

Hello,

I noticed that Cloudflare sub CA is issuing certificates with "Cloudflare, Inc." in the subject to websites using their web proxy (example https://crt.sh/?id=5759164956).

I think that this is quite misleading. A user visiting the website of a fake shop could check the certificate and if they don't know what Cloudflare is, they could believe that the shop is operated by an existing company registered in the US and therefore trust the (fake) shop.

A user on a phishing site targeting Cloudflare could check the certificate, see Cloudflare in the subject and believe it to be an official Cloudflare website.

A user using a website that is using Cloudflare proxy could check the certificate and remember that it has Cloudflare in the subject. Then when he will be on a phishing website, he will check the certificate subject, see the same value and believe it to be oferated by the same entity and enter his credentials.

I think that either the subject field should be more restricted to only allow entering details of the end owner/operator of the website or various recommendations explaining how to check certificate details to asses whether a website is trustworthy should be changed.

[Daniel Veditz]

Disclaimer: I work for Mozilla, but not on certificate policy. This is a personal observation.

On Thu, Sep 8, 2022 at 3:08 AM Michel Le Bihan <michel.le...@gmail.com> wrote:

A user visiting the website of a fake shop could check the certificate and if they don't know what Cloudflare is, they could believe that the shop is operated by an existing company registered in the US and therefore trust the (fake) shop.

On the other hand, if it didn't say "Cloudflare" people might think they --were-- talking directly to the shop, and they are not. They are talking to a Cloudflare server which could do anything at all with the traffic before passing it along. You need to know it's Cloudflare before you even realize you're trusting a proxy to faithfully transmit the traffic. Besides, all the shop's actual certificate proves is that they were able to get a certificate for that domain. It does not mean you can trust the shop because it could well be fake either way.

 

A user on a phishing site targeting Cloudflare could check the certificate, see Cloudflare in the subject and believe it to be an official Cloudflare website.

That's a problem for Cloudflare to worry about. They *do* put "sni.cloudflaressl.com" in the common name which does not match the domain you've reached and should be a clue.

A user using a website that is using Cloudflare proxy could check the certificate and remember that it has Cloudflare in the subject. Then when he will be on a phishing website, he will check the certificate subject, see the same value and believe it to be oferated by the same entity and enter his credentials.

Couldn't you say the same about any other cert?  One day you go to https://mozllla.org by mistake, and when you look at the certificate the common name matches that and there's no Subject Name at all -- like most certs. Other than giving you a second chance to catch the typo, how does that help protect against phishing?  Actually, if you go to the real https://www.mozilla.org and look at the cert it will say "www.mozilla.moz.works" which looks totally fake. Names are a terrible basis for trust.

 

... or various recommendations explaining how to check certificate details to asses whether a website is trustworthy should be changed.

What recommendations are those? You can't judge whether a site is trustworthy or not by its certificate. Scammers get certificates all the time. "Legitimate" companies pay huge fines for having defrauded the public all the time.

I take your point that it wouldn't hurt if they picked a more descriptive name. On the other hand, if someone is trying to trust a site "by name" I'd expect them to look up the name and find out what "Cloudflare, Inc" does. Either way it doesn't seem like a policy issue that this group deals with.

-Dan Veditz

[Buschart, Rufus]

This discussion is a prime example why OV / EV TLS certificates should be phased out. They are promising more to the end user than they can deliver and the community wasn’t able to make them truly work in 25 years…

 

/Rufus

 

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADYDTCCXUm_P0x%2BnUHAcVEh_gHS8JXvoeh3Skd3nRH9kv5gZkA%40mail.gmail.com.

[Michel Le Bihan]

> On the other hand, if it didn't say "Cloudflare" people might think they --were-- talking directly to the shop, and they are not. They are talking to a Cloudflare server which could do anything at all with the traffic before passing it along. You need to know it's Cloudflare before you even realize you're trusting a proxy to faithfully transmit the traffic.

I don't think it matters to the end user what Proxy/DDoS protection, hosting provider, VPS or "cloud" provider the website is using (all could intercept data). Even if it did, this isn't the right way to show it. It would only depend on the will and technical possibility to add it to a certificate (a VPS provider can't do that).

> Besides, all the shop's actual certificate proves is that they were able to get a certificate for that domain. It does not mean you can trust the shop because it could well be fake either way.

OV and EV certificates contain the name of the organization besides the domain name.

> That's a problem for Cloudflare to worry about. They *do* put "sni.cloudflaressl.com" in the common name which does not match the domain you've reached and should be a clue.

> Actually, if you go to the real https://www.mozilla.org and look at the cert it will say "www.mozilla.moz.works" which looks totally fake. Names are a terrible basis for trust.

The commonName is just a DNS Name. One of the names in SAN. It's deprecated, but CAs still add it there probably for compatibility reasons. I agree that it might confuse users and should probably be entirely removed. I was talking about the organizationName that contains the name of the entity.

[Daniel Veditz]

On Fri, Sep 9, 2022 at 3:12 AM Michel Le Bihan <michel.le...@gmail.com> wrote:

OV and EV certificates contain the name of the organization besides the domain name.

I'm sure Cloudflare is not going to do the verification work required to issue OV and EV certs on behalf of the sites they protect, and their issuing cert is almost certainly not given that authority (I didn't check, though). In fact, it's even possible the contract under which they got their sub-CA requires them to put their name on certs so people don't mistake those certificates for ones issued from other CAs to a site owner to be deployed directly on that site.

The commonName is just a DNS Name. One of the names in SAN. It's deprecated, but CAs still add it there probably for compatibility reasons. I agree that it might confuse users and should probably be entirely removed.

Oh, I was saying the opposite. I think Cloudflare put that there intentionally as a signal and should not remove it. Of course we won't know their intention for sure unless someone from Cloudflare speaks up.

-Dan Veditz