>> Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that.
Total newbie here.
Since CloudFlare (and likewise any other CDN) is hosting many websites, how do I know the information served originated from the intended website and not from another one CloudFlare is hosting?
We have been told to look at the browser's address bar to make sure domain belongs to the intended website (e.g., citibank.com and not citibank.another.com). With browser pulling information from CloudFlare, and often over twenty others listed by NoScript and Ghostery on practically every website today, what precautions should I be taking?
You don't, really. The target website has indicated that they trust CloudFlare, and if CloudFlare turns out to be unworthy of that trust you're pretty much out of luck. From SSL's point of view it is exactly the same as if the originating party is unworthy of your trust.
I think there's a bit of a mental model update that people may need to process... the originating party does not have any mystical geas invoked upon it by SSL to be trustworthy itself. There's nothing stopping the other end from being untrustworthy for any reason. Nothing in HTTPS prevents the other party from posting your transaction on an electronic billboard on the nearest highway. Yes, it sounds obvious when I say it, but it's very important and clear many people aren't operating under this model. CloudFlare isn't doing anything weird or new here... you've always had to trust the judgment of the other end of the HTTPS connection, and it has always involved the trustworthiness of other parties as well. There's no change here. Among the many ways in which a remote party could be untrustworthy is for them to delegate that trust to an untrustworthy party. Nothing strange about that.
For the original sites, I use NoScript and Ghostery to block 'third' parties to capture the data (e.g. I would not want Facebook to register my activities on 'other' sites I am visiting). I am clueless on how to set these tools up when information is being served from a common CDN. And get confusing messages from security folks who tell us to check the domain name of the information source.
Incidentally, I've never come across this term geas. http://en.wiktionary.org/wiki/geas
(Gaelic mythology) A vow or obligation placed upon a person.
A curse.
A mystical compulsion.That's new and weird, IMO.
I agree that HTTPS has NEVER guaranteed end-to-end encryption nor displays any indicators when thats not the case So this isnt a new issue, however Cloudflare's policy has indeed highlighted this issue and elevated it to an entire new level.
The more I work with PKI/SSL the more it becomes obvious that there are no perfect decisions. At its core, I like what Cloudflare has done. It impacts the SSL market in many ways and I want to see what comes of it.
Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that.
Other replies have already gone into how HTTPS never guaranteed anything about what happened after that, but I think that's the wrong POV. What HTTPS guarantees is that one of the central certificate authorities have authenticated that the entity they have granted the cert to is indeed that entity, and the entity can then do whatever they please with that certificate. (Which may be wrong, in which case you have already lost.)
If the entity chooses to grant CloudFlare the authority to speak in their name, then it is a statement on their part that they trust CloudFlare to do so. It is not particularly different than any other bit of internal traffic. It is and always has been the responsibility of the certificate-owning entity to decide what to do with their certificate.
This isn't new. This isn't even remotely new. The concept of allowing designated others to speak in someone's name is ancient, and even in the SSL world it has been going on forever. How many HTTPS sites are being served by Amazon or Rackspace or Linode, which are all technically capable of intercepting the plaintext request at will, or forging the response, or just plain stealing the certificate? It's bizarre to me to see people flipping out as if CloudFlare is doing something new, when it isn't new in the slightest. HTTPS has never been an assertion that the certificate holder is the only participant in the transaction. It has always been a statement of trust by the cert holder that everyone involved in the transaction is trustworthy, and it has always been the case that that statement could be in error, and it has always been the case that if that is so, you've already lost anyhow.