The majority of CloudFlare's IP addresses are blocked by China's great firewall, which means CloudFlare is out of the question if you expect that your website will be visited by Chinese users.
1) That's not actually accurate; and 2) Just wait for the next trick we have up our sleeve ( https://blog.cloudflare.com/one-more-thing-keyless-ssl-and-c... )
Universal SSL
231–240 of 250 posts
Re: Universal SSL
#232Earlier quoted context omitted.
> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more. Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain…
>Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain text emails over the internet to the customer service email? Or online purchasing pages that just sent plain text emails containing the credit card info to sales@domain? Today is still that age unfortunately, I just ran into one the other day.
Re: Universal SSL
#233Earlier quoted context omitted.
>> "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 fr…
"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…
That's new and weird, IMO.
Re: Universal SSL
#234Earlier quoted context omitted.
I think this is a good idea as well. In their blog post they discuss how "Full SSL" is much better security than "Flexible SSL", but by not making it a requirement a lot of people won't bother with it.
"Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM. Only "Strict SSL" does, which makes sure it's a valid CA-signed certificate. What we need (and what myself and others have requested) is Full SSL with fingerprint checking so you can keep security with a self-signed cert. I honestly think CF should remove flexible SSL and full SSL as options - they're just too vuln…
I wouldn't say this is entirely useless, even if there is still risk. Someone can impersonate your site to Cloudflare's reverse proxy server if they control the medium between, but they can't just get instant plaintext. This adds an additional barrier for an intruder into Cloudflare's network: they'd have to not only tap all traffic, but inject their own self-signed cert as well. This increases the chances of Cloudflare discovering the intrusion.
I agree though that a pinning solution of some kind would be preferable.
Re: Universal SSL
#235Earlier quoted context omitted.
I wonder if Canonical could be talked into getting an SNI-enabled wget into 12.04. Though if it were me, my response would probably just be "use curl" (which does work in 12.04. I don't know what the status is in Ruby. Python 3 supports SNI natively. Python 2.x does not with the included libraries, but can be made to. (You're shooting yourself in the foot by using Python 2.x's included libraries with HTTPS anyway --…
Yeah, curl is an option. It just kinda sucks when things that have worked for years break overnight because of an otherwise transparent upstream SSL change. My guess is since introducing an SNI-compatible version is outside the scope of a security release, it won't end up happening.
SNI is fait accompli. It will be adopted. It is being adopted. Without support for it, a rapidly growing number of sites will not be securely accessible, and effective regressions like the one you experienced will be encountered more and more frequently.
And in an age where interconnected systems are the default assumption and those systems change fast, I don't think it's realistic to adhere to an overly strict policy about what updates can be brought in during extended support cycles. I think Red Hat recognized this a while back. Canonical probably needs to.
Re: Universal SSL
#236Earlier quoted context omitted.
It seems to me that CloudFlare is positioning themselves as another Google or Facebook, where a key feature of their business is that they get to track the web history of a large portion of internet users. CloudFlare's business model is not offering a free service and figure out how to make money. It's getting people to pay us money and those people are our actual customers who run web sites: https://www.cloudflare.c…
Do they have a Zero Knowledge policy or anything close to it, though? It doesn't matter if they don't make money from it, if they still collect all the data. I don't know how a service that's meant to cache data is supposed to be "zero knowledge", but hopefully they can do something about that - until it's too late and authorities already have a 1,000 requests lined up for their data.
>Unlike most database applications, the cache stored at each CloudFlare facility has an undefined expiration date—and because of the nature of those facilities, it isn't a simple matter to add more storage. To keep the utilization level of installed storage high, the cache system simply purges older cache data when it needs to store new content.
>The downside of the hash-based cache's simplicity is that it has no built-in logging system to track content. CloudFlare can't tell customers which data centers have copies of which content they've posted. "A customer will ask me, 'Tell me all of the files you have in cache,'" Prince said. "For us, all we know is there are a whole bunch of hashes sitting on a disk somewhere—we don't keep track of which object belongs to what site."
[1] - http://arstechnica.com/information-technology/2012/10/one-bi...
Re: Universal SSL
#237I have very mixed feelings about this. Yes, on the one hand this is great news because a lot of websites who otherwise never would have bothered with SSL can now be protected from snooping or traffic manipulation on your local (possibly very insecure: your neighborhood Starbucks' wifi) network. On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you ar…
The title of this one started off as "free" SSL. Now it is "universal SSL". C'mon. As vader1 points out, the level of potential deception here is getting a wee bit high.
CF is just a MITM. A website owner lets CF control her DNS and this allows CF to route all requests for her website through CF servers; CF stands between the website and the user.
Unless the website owner configures SSL then the user only gets an encrypted connection to CF. That's hardly "universal" SSL.
Re: Universal SSL
#238Re: Universal SSL
#239Re: Universal SSL
#240so how does this differ from the paid plan? I mean the only reason I am paying is because of SSL and now it's free?
The SSL on paid plans is compatible with all clients, such as IE on XP, Android 2.x, and slightly outdated HTTP wrappers for most programming languages.