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

191–200 of 250 posts

Re: Universal SSL

#191

Post by ancarda »

psykovsky wrote: post #169
ancarda wrote: post #122

Once IPv6 is a bit more popular, will CloudFlare use a unique IP per customer to get around SNI or will it still be used on IPv6? It seems a bit like NAT; something that can safely die once IPv4 is gone.

So, you want NAT to die, but apparently you forget that NAT is what protects most domestic computers from intrusion, not anti-virus or software firewalls. It will be fun...

I'm aware a lot of people use NAT as a cheap firewall. I suspect decent home routers will have a basic firewall for IPv6, even if it just works based on ports.

Re: Universal SSL

#192

Post by general_failure »

This is silly. SSL is supposed to be a secure conversation between the website and the end user. No one else is between. Encouraging these things is detrimental to internet.

In fact, I would go ahead and say: * Make browser self-signed certs less scarier * Make users more accustomed and knowledgable of self-signed certs.

Browser vendors and corporations need to work together to make the above happen.

Re: Universal SSL

#193

Post by itistoday2 »

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…

There's also the small issue whereby DNS MITM completely bypasses all of CloudFlare's protection...

And no, DNSSEC won't help here:

https://twitter.com/taoeffect/status/516650413987467266

Re: Universal SSL

#194

Post by JoshTriplett »

psykovsky wrote: post #169
ancarda wrote: post #122

Once IPv6 is a bit more popular, will CloudFlare use a unique IP per customer to get around SNI or will it still be used on IPv6? It seems a bit like NAT; something that can safely die once IPv4 is gone.

So, you want NAT to die, but apparently you forget that NAT is what protects most domestic computers from intrusion, not anti-virus or software firewalls. It will be fun...

That use of NAT can trivially be replaced by an everything-out nothing-in firewall.

Re: Universal SSL

#196

Post by moe »

rictic wrote: post #185
moe wrote: post #124

Earlier quoted context omitted.

seeing the padlock will only tell you Seeing the padlock has never told you much interesting to begin with. You have to click the padlock and compare the fingerprint to a known good one. Yes, nobody does that. And that's why SSL in the browser is a red herring (as far as 3-letter agencies are concerned). Why no browser vendor ever tried to fix this basic design flaw is left as an exercise to the reader.

Browser makers and others have been trying to fix this, it is actually harder than it looks. HSTS, certificate transparency, and shipping pre-pinned certs with the browser are all approaches pushed forward by browser makers. As an example of how this is harder than it looks one need only look to DNSSEC.

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 infrastructure owners.

Don't drink the snake oil.

Re: Universal SSL

#197

Post by alok-g »

jerf wrote: post #172
alok-g wrote: 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…

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.

Re: Universal SSL

#198

Post by peterwwillis »

driverdan wrote: post #150
peterwwillis wrote: post #121

Earlier quoted context omitted.

What good would that do? A self-signed cert is about as secure as no cert at all. (Unless they implement their own form of certificate pinning for the origin, which would cause problems for sites with multiple certs on the same host, which is quite common)

So long as CF pins the cert it's perfectly safe.

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 parties get the origin's data, this is not "safe".

In the current model, CloudFlare is the 'client' that requests resources from the origin 'server'. The client verifies its connection to the server is valid before requesting content, which is where a self-signed pinned cert would show that the client is who they say they are. But the server has not verified the client! The client could be anybody, like the NSA for example, and the origin server would hand over data happily. To fix that you'd need to also do client-authentication in the handshake. I don't know that they support that currently.

You're basically implementing public-key crypto using PKI infrastructure using two nodes. Can it work? Sure. Was it designed for this? No. Are they doing it 'securely' right now, for all uses of 'secure' or 'safe'? Not to my knowledge. Will they support client authentication in the future? Who knows.

Re: Universal SSL

#199

Post by peterwwillis »

ceejayoz wrote: post #163
peterwwillis wrote: post #155

Earlier quoted context omitted.

This is the nail-clipper defense. For cases where a terrorist might take over a plane by threatening to give people tiny cuts or jabs, taking away nail clippers 'protects enormously'. How often have you encountered read-only network access? It doesn't happen in reality; even the middle hop in a route has total control over the flow of traffic and thus can terminate it and mitm on reconnect. In any case, confidentiali…

> How often have you encountered read-only network access? Public wireless points (i.e. Firesheep), any network with a hub instead of a switch...

None of those are read-only.

Re: Universal SSL

#200

Post by vtlynch »

jerf wrote: post #148
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…

"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. Other replies have already gone into how HTTPS never guaranteed anything about what happened after that, but I think that's the wrong POV. What HTTPS guarantees is that one of the…

I agree with most of your statements, except that I like to think of HTTPS primarily as an indication of encryption not trust. If you dont have end-to-end encryption whats the point of trusting the involved parties when its so easy for an un-involved party to take a look at what you are doing?

I agree that HTTPS has NEVER guaranteed end-to-end encryption nor displays any indicators when thats not the case So this isnt a new issue, however Cloudflare's policy has indeed highlighted this issue and elevated it to an entire new level.

The more I work with PKI/SSL the more it becomes obvious that there are no perfect decisions. At its core, I like what Cloudflare has done. It impacts the SSL market in many ways and I want to see what comes of it.

Post reply on HN