Right, I did not mean to imply they are perfectly grouped together. It is a relatively minor information leak.
(Also, perhaps we should rename the title of this thread to something less inflammatory).
Since Cloudflare also (usually?) gives all of an account’s domains the same nameservers, correlating the certificates and nameservers is likely to match one account('s group of domains).
What does either of these concerns have to do with either the use of wildcard certs, or with combining multiple domains on the same cert?
Because it erodes trust. Which I've said repeatedly already. Your confusion suggests to me that you don't think trust matters in SSL, and as I have already stated if that were the case, then we would all use self-signed certificates and do away with the CA system entirely. Without trust, the only purpose of a Certificate Authority is to tax encryption.
Why not both? Why is it not both the browsers responsibility to watchdog for suspicious activity and the CDNs responsibility to serve proxied content in a responsible manner? Reading your question I imagine a scenario where one guy at an office says "Well Bob is doing his job so I don't have to bother with mine". Is it too much to ask that all participants contribute to a secure internet?
And in my opinion it doesn't "erode trust".
Why do you disagree?
1 Like
With all due respect, that means nothing. Opinions do not shape reality.
To the best of my knowledge, it does not "erode trust" in any way. What evidence do you have that contradicts that?
So, the purpose of a Domain Verified certificate is to tell the browser that the data you're receiving is from the origin it claims to be from.
$Cloudflare hides the origin of the data and discards the original SSL information, decrypts the encrypted data, and then re-encrypts it using their own SSL certificate which is shared with dozens of unrelated domains which all have their own origins.
That is enough to say trust is gone.
However, there is more. Let's say you own popular-store.com and I own malicious-hacker.com and we share a $Cloudflare certificate. I can build a phishing site which clones popular-store.com and there is no reasonable way that a user could know that my phishing site isn't your online store. Sure $Cloudflare would eventually take down the hacker account, but by that time hundreds or thousands of people could be victimized. This is probably a lot easier than you think. A hacker needs to only visit their own site and examine the certificate to see who they share their SSL with.
This could be solved relatively easily. $Cloudflare needs to end the practice of shared SSL certificates on their service. And frankly, if that adds 0.1ms of overhead or whatever to their operations, so what? This project, and the security health of the internet, are way more important than any $Cloudflare.
I don’t understand how that affects security.
If I visit https://malicious-hacker.com/ I know it’s not https://popular-store.com/ because the domain is in the location bar in the most prominent place my browser’s UI team could find. If I fail to spot the obvious when it’s right in front of me, it’s extremely unlikely I’ll carefully investigate the certificate’s SANs and determine anything from them.
2 Likes
…pushState lets you impersonate any other site in the SSL certificate without any validation?
As Cloudflare's customer you wouldn't have access to the private key for the shared certificate. So you can't pretend to be popular-store.com - only Cloudflare can, and when they receive traffic destined for that domain it's their responsibility to route it to the correct customer's origin. To successfully impersonate them you would have to intercept the traffic from Cloudflare to their origin, and if they've enabled the "Full SSL (Strict)" option in Cloudflare as they should, then even that should be impossible.
Not according to History API - Web APIs | MDN
The new URL must be of the same origin as the current URL; otherwise, pushState() will throw an exception.
5 Likes
Since "eroded trust" is a matter of opinion, in this case, they do.
...in your opinion.
Then you have a very poor understand of what I'm writing. Of course trust matters. A DV cert shows that the party presenting it has demonstrated adequate control over the domain(s) in question to be issued the cert, or that the party(ies) who does have such control has given the cert to the party presenting the cert. Whichever way you want to look at it, Cloudflare's certs are appropriately issued in this regard.
Cloudflare, or any other CDN, of necessity acts as a man in the middle. If traffic from the origin is encrypted, they decrypt it, and then re-encrypt it for transit to the client. They decrypt encrypted traffic from the client, and (if the origin supports it) re-encrypt it for transit to the origin. Cloudflare provides origin certificates, so there's no excuse for traffic to/from the origin to be unencrypted, but the MITM is still. That's a conscious decision for the site owner, but not necessarily for the end-user.
...other than the fact that the URL bar in the browser would still say malicious-hacker.com, not popular-store.com--the fact that you share a certificate doesn't give you the ability to hijack traffic for popular-store.com. You don't think that's enough of a giveaway?
2 Likes
No, it isn't. You just don't understand the context or technology.
Wrong.
Foolish. "We don't have to do things the right way because every user on the internet should know what they're doing!"
Missing the point.
I believe the discussion in this thread has run its course. Since the tone is rapidly degrading (Let’s all take a minute to review the community guidelines), I’m going to lock the thread.
Thanks all,
10 Likes