Live data from Hacker News

Universal SSL

blog.cloudflare.com

231–240 of 250 posts

Re: Universal SSL

#231
post #48

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

There are plenty of cloudflare IPs that are blocked. Is cloudflare aware of this? A few were being used for cdnjs which causes problems for anyone using cdnjs.

Re: Universal SSL

#232
post #39

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

I'd like to think we've made some progress since then.

Re: Universal SSL

#233
post #172
post #165

Earlier 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…

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.

Re: Universal SSL

#234

Earlier 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…

>"Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM.

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

#235

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

I think there's a strong argument to be made that not supporting SNI is a security problem, and will become quite a serious one over the next few years.

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

#236

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

There was an article[1] from a few years ago about Cloudflare's infrastructure and from the sounds of it they can't link customers to data. Data does exists because that's the nature of a cache, but its defined with an undefined timestamp and is purged regularly in order to have enough disk space.

>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

#237
post #23

I 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…

What is it with Cloudflare marketing posts making page 1 on a daily basis? Is there some business relationship between HN and CF?

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

#239
So they put a lot of effort into promoting SNI. A potential gotcha to consider, especially for peeps on HN; SNI isn't supported by a lot of Android, including the default download manager and parts of the networking stack—that bit me recently in development. At least as far back as 4.4.0.

Re: Universal SSL

#240

so 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 free plans is only compatible with newer clients.

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.

Post reply on HN