4 ms·

>> "On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting." >> Yes, you do. Yo

by alok-g 12y ago

>> "On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting." >> 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?

jerf 12y ago
"how do I know the information served originated from the intended website and not from another one CloudFlare is hosting?" 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.
- alok-g 12y ago
  Thanks. I understand that the original party can misuse the data in any fashion. The question is if having CDNs where anyone can put their site, makes the original intended site more prone to security / phishing attacks? Could it be for example that due to some hack (at the original site, CDN, elsewhere), CDN ends up mixing information from the multiple sites it is hosting? 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.
- RickHull 12y ago
  > the originating party does not have any mystical geas invoked upon it Incidentally, I've never come across this term geas. http://en.wiktionary.org/wiki/geas http://en.wiktionary.org/wiki/geas (Gaelic mythology) A vow or obligation placed upon a person. A curse. A mystical compulsion.
- pbreit 12y ago
  I don't see how you can say nothing weird or new is being done here. 99.9% of the time, https has indicated essentially end-to-end encryption. Now that goes down to around 50%. That's new and weird, IMO.

by alok-g 12y ago

jerf 12y ago

"how do I know the information served originated from the intended website and not from another one CloudFlare is hosting?" 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.

alok-g 12y ago
Thanks. I understand that the original party can misuse the data in any fashion. The question is if having CDNs where anyone can put their site, makes the original intended site more prone to security / phishing attacks? Could it be for example that due to some hack (at the original site, CDN, elsewhere), CDN ends up mixing information from the multiple sites it is hosting? 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.
RickHull 12y ago
> the originating party does not have any mystical geas invoked upon it Incidentally, I've never come across this term geas. http://en.wiktionary.org/wiki/geas http://en.wiktionary.org/wiki/geas (Gaelic mythology) A vow or obligation placed upon a person. A curse. A mystical compulsion.
pbreit 12y ago
I don't see how you can say nothing weird or new is being done here. 99.9% of the time, https has indicated essentially end-to-end encryption. Now that goes down to around 50%. That's new and weird, IMO.