Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Universal SSL

blog.cloudflare.com

Post reply on HN
Print view View original

211–220 of 250 posts

Re: Universal SSL

#211

Post by cyphunk »

vader1 wrote: 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…

thinking that the green padlock > red padlock has been a false positive for trust since forever. Any trust other than the red padlock is just a lie. About time we learn that, and understand the entire CA setup trying to convince you of something else is broken.

Re: Universal SSL

#212

Post by rstupek »

cube00 wrote: post #8
LordIllidan wrote: post #3

This is excellent news - one question though - what would a user on XP see when he accesses one of these sites?

If they are using Chrome they should be OK since that is still supported and is a "modern" browser, however IE under XP would show an error.

Are you sure chrome on xp wouldn't have the issue? Previous tests we've done and documentation from chrome showed on xp chrome used the same network stack that IE used. Has that changed in newer releases?

Re: Universal SSL

#213

Post by tekacs »

jessaustin wrote: post #204
moe wrote: post #196

Earlier quoted context omitted.

pushed forward by browser makers Huh? Which browser alerts me when the cert changes from the previous one that it has seen for a site? That would be the most basic and trivial mitigation for a start. What we see instead is consortium paralysis for decades . Occam's razor much? HSTS does nothing for certificate trust. And the other two you mentioned still conveniently keep us at the mercy of browser vendors and infras…

Which browser alerts me when the cert changes from the previous one that it has seen for a site? This alone would make self-signing much more viable for many uses.

Firefox + self-signed certs forces you to add an exception for the site, which makes the cert work and shouts at you again if that cert ever changes, so fulfilling the above. :)

Re: Universal SSL

#214

Post by [deleted] »

LewisJEllis wrote: post #161
rang wrote: post #149

Good job cloudflare for finally keeping up with the industry. Cloudfront, for example, already supports universal ssl and SNI

Cloudflare has offered SSL & SNI for paid customers for ages. You're missing the point.

[deleted]

Re: Universal SSL

#215

Post by rang »

xxdesmus wrote: post #201
rang wrote: post #149

Good job cloudflare for finally keeping up with the industry. Cloudfront, for example, already supports universal ssl and SNI

yeah, no. We've offered SSL for 4 years now. This is entirely different. Cloudfront, for example, doesn't give you SSL for free.

Customers have to pay for dedicated ipv4 address space. There's no way around that. SNI should be free as they don't require dedicated IPs. But it doesn't look like that was the case for cloudflare

Re: Universal SSL

#216

Post by X-Istence »

peterwwillis wrote: post #119
switch007 wrote: post #92

Earlier quoted context omitted.

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.

Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.

Re: Universal SSL

#217

Post by flaviu2 »

tekacs wrote: post #213
jessaustin wrote: post #204

Earlier quoted context omitted.

Which browser alerts me when the cert changes from the previous one that it has seen for a site? This alone would make self-signing much more viable for many uses.

Firefox + self-signed certs forces you to add an exception for the site, which makes the cert work and shouts at you again if that cert ever changes, so fulfilling the above. :)

Sure, but that is only helpful if you remember that the site had previously worked before. Otherwise, it's just like your first time visiting it.

Re: Universal SSL

#218

Post by nirvdrum »

nknighthb wrote: post #123
nirvdrum wrote: post #42

Earlier quoted context omitted.

The larger problem I had was with non-interactive browsers. E.g., GitHub changed their downloads server to use SNI and overnight a bunch of scripts I had using wget on Ubuntu 12.04 (a distribution supported until 2017) stopped working. Java 6 doesn't support SNI, so you need to watch your API stats. And I seem to recall using versions of Python and Ruby that also didn't support it.

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.

Re: Universal SSL

#219

Post by damonpace »

Congrats to CF on this. The day has come where all domains & subdomains should automatically be SSL encrypted for free. CF is building the Internet as it should have been built in the first place. I love that they are doing this.

Re: Universal SSL

#220

Post by peterwwillis »

comex wrote: post #209
peterwwillis wrote: post #198

Earlier quoted context omitted.

Like I said in my comment, yes, pinning the cert would be better. It wouldn't be PKI at that point, but it would be better than just accepting any self-signed cert. But what is 'safe'? What are you actually trying to secure? If you're trying to ensure that CloudFlare receives an authentic copy of data to deliver to users, a pinned self-signed cert will do that. If you're trying to also ensure that only the intended p…

For the vast majority of websites that do not currently use SSL client certificates, the NSA could also connect to the site normally via CloudFlare, which will happily proxy arbitrary requests to the origin server because that's the whole point. If you want to secure data, any higher level authentication system (HTTP auth, your standard form based account systems) will still work. No?

Correct. If you want to keep the data private, any authentication system would be better than none. It would be nice to encrypt the data too, and provide non-repudiation, which is what a secure connection is for.

Most CDN setups i've seen have never bothered with any of this because they pass no private data; it's all static resources, mostly. Even if they did pass private data, they just use IP filtering and completely ignore mitm. Then they don't address client authentication because IP spoofing is, like, totally hard.

Post reply on HN