> 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.

Le vendredi 9 septembre 2022 à 00:02:43 UTC+2, Daniel Veditz a écrit :

> 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 <[email protected]> 
> 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
>

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/76c885eb-e07c-4f33-ae62-04e5bc69b178n%40mozilla.org.

Reply via email to