Live data from Hacker News

Universal SSL

blog.cloudflare.com

111–120 of 250 posts

Re: Universal SSL

#111
post #106

Enabled this, but when visiting website over https have error. "You attempted to reach YYYY, but instead you actually reached a server identifying itself as ssl2000.cloudflare.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of YYYY." Looks like things are still in progress…

We are in the process of issuing 2 million certs. Your cert hasn't been issued yet so you are hitting a sort of 'default cert'. Once that error goes away you are set.

If i choose to ignore SSL warning I get ERROR 522. But I guess its better now to sit and relax while CF catches up with all this migration.

Re: Universal SSL

#112

Will users be able to download their private keys for the provisioned cert? If not, would CloudFlare ever consider provisioning free SSL certs for non-CloudFlare customers (i.e. let us uploade our crt file and you have your CAs sign it)? We desperately need an alternative to StartCom, since many devs don't trust them[1]. I've suggested AOL in another thread[2], but so far I can't find anyone who works there to talk t…

I believe the CEO said in their last post here that certificate pinning and custom certificates (even EV ones) would be supported by their new plans. (Can't remember if you have to pay $$$, though)

I imagine it will take a short amount of time after this change to realize that.

Re: Universal SSL

#113

This was indeed a pleasant surprise when I logged into my CloudFlare account. What intrigues me is that CloudFlare missed an opportunity to allow secure self-signed certificates. The new CloudFlare SSL setup allows the origin server to present to CloudFlare's servers either (i) an unverified self-signed certificates; or (ii) a certificate signed by a CA. Neither provides great security. In the former case, a MITM can…

I recall reading here on HN recently something about CloudFlare having their own internal CA infrastructure. I would expect them to allow customers to start generating certificates (signed by their internal CA) that they can deploy on the origin server.

Re: Universal SSL

#114
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…

The centralization argument still has merit. If this catches on big time, there's only one company to coerce/compromise, to backdoor a bunch of services at once. Arguably the CA/ISP structure is like this already, but this may be worse.

Totally true, but on the other hand, the first mile will be encrypted for a lot more connections:

"Yesterday, there were about 2 million sites active on the Internet that supported encrypted connections. By the end of the day today, we'll have doubled that."

That's kind of spectacular.

I think the first mile is one of the key places where data gets stolen. OF course the final millimeters-on the server- is another.

Re: Universal SSL

#115
post #39
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…

> 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

#116
I wonder what happens to certificates if a customer leaves Cloudflare?

What keeps revocation lists from ballooning as customers "try out" the service?

Re: Universal SSL

#117

I just got the popup, clicked "okay" and when I go to "Cloudflare settings", it's still only available to select SSL options for the paid plans. For those who haven't yet seen the popup there's a bit more info here: https://www.cloudflare.com/ssl#universal_ssl It's a pity that I got the message saying it was available on my account, when the setting is not yet activated :)

Working on that. Lots and lots of certs to issue. Seeing about making message "smarter" (checking your individual status) if possible.

Re: Universal SSL

#118
post #9

Great initiative, minor drawbacks such as up to 20% of the traffic wouldn't apply due to their use of SNI: "Globally, more than 80% of requests come from modern browsers, and that percentage is growing quickly." EDIT: Mixed content on that page (within the embedded map at https://cloudflare.github.io/sni-visualization/ )

SNI isn't the only problem either. Apparently they're using ECDSA-based certificates which aren't generally used and aren't supported by older browsers.

People who are behind the times browser-wise tend to be very behind (IE on XP, Android 2.x/3.x) - so I don't think ECDSA will be much of a limiting factor once you take people who can't access SNI based certs out of consideration.

Re: Universal SSL

#119
post #75

Earlier quoted context omitted.

Of course using HTTPS is no guarantee that the site doesn't leak your data in any other way. But never before has it been this easy to create a false sense of security: give the impression that connections to your site are encrypted, while in reality it's plaintext for half of the route. I think this will ultimately dilute the value of HTTPS as we know it, and can only hope that it will lead to the adoption of better…

I would bet there are many, many load-balancers terminating SSL and then proxying plain HTTP to web servers over a VLAN.

Actually, that's a good model. It would have kept the memory (and code execution domain) of the application server independent from the memory of the SSL terminator during Heartbleed. If you terminate SSL on the same box as your app server you're putting many eggs into one basket.

Re: Universal SSL

#120
post #33

Earlier quoted context omitted.

What they should do is require that the server has at least a self-signed certificate. They already support that but don't require it.

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 vulnerable to be valuable.

Post reply on HN