Hacker News Reader

Comment by eganist | Hacker News Reader

Well, the keywords there are next to. Like @remy_ implied, you need a mechanism for guaranteeing that the logic you're executing in-browser is protected from server compromise. That's where the Cyph example came in, since as far as I can tell, Cyph is the team to have hacked together a solution to that dilemma, though Cyph also is not using the Signal Protocol right now.

Anyway, there's an upcoming defcon talk which'll lightly touch on how web standards were mangled and viciously abused to make that happen, but since the talk is deliberately not vendor-specific, the focus on it will be brief. Disclaimer on my end is that I was involved in the initial review of their code-signing implementation. https://www.defcon.org/html/defcon-24/dc-24-speakers.html#Za...

View on HN

Cyph's solution for this, last I saw it, is a Rube Goldberg machine of rolling HPKP pins used in attempt to keep the application from reloading itself from its own servers. It's incredibly complicated. And no matter how much asm.js you use, it's still crypto running in a browser instance. There are other very significant problems with browser crypto --- problems that even affect Chrome Applications.

You and I+Cure53+others will probably always disagree on this topic since you've always been the primary catalyst for dissent on this, but it's not at all complicated nor deserving of the analogy to a Rube Goldberg machine.

It's been well vetted enough. It might be a hack, but it's a sufficiently effective hack. We can agree to disagree :)

You coming to either Black Hat or DEF CON? Let me at least connect the two of you after the AppSec Glory talk.

I can't tell if you're talking about browser crypto (in which case my perspective is shared by a large number of crypto engineers) or Cyph's weird caching scheme, in which case a couple people from Cure53 are the only ones who have ever tried to evaluate it.

I think he was only (or mostly) talking about the latter, which I would agree isn't very complicated at all (it's just deleting and regenerating keys/certs on an interval).

As to the former, are you referring to specific known side channel attacks against asm.js/wasm, or just the usual XSS risk?

One would hope that the founder of the company trying to bring that weird secure caching attempt to market would believe that it wasn't very complicated. :)

Of course, if you've filed for patents on this, as was suggested upthread, that somewhat cuts against that argument, doesn't it?

lol, I'm definitely biased given that I'm long since familiar with the idea and wrote the implementation, but I think it's more conceptually counterintuitive/clever/weird than it is actually complicated in terms of having many moving parts.

WebSign does have a patent pending on it (I think it's fair enough to say that the whole system of accomplishing in-browser code signing this way was non-obvious), but HPKP Suicide itself doesn't. Bryant (eganist) and I are actually disclosing and open sourcing implementations of a few non-code-signing applications of HPKP Suicide at Black Hat and DEF CON next month.

> WebSign does have a patent pending on it (I think it's fair enough to say that the whole system of accomplishing in-browser code signing this way was non-obvious),

Yay, another technology to boycott entirely.

What is the difference between compromising a web server that serves js library vs the one that serves device-native app binary?

This always s gets brought up when discussing in-browser crypto and could never get a satisfactory answer.

For one, device-native binaries have to be signed in order to actually run on the phone (well, without introducing some other tweak such as explicitly permitting unsigned applications).

Implementing this with JS is far, far, far more difficult, and the only solution known (touched on in my other comments) still pisses people off because it's running in a web context that, if improperly mitigated, can still facilitate disruption via code injection i.e. XSS.

That said, we're all conveniently ignoring the fact that all of this assumes that the devices themselves haven't been owned. If you think you're a target of entities capable of getting into a fully patched phone, you've got bigger problems.

So this is "whomever is signing the app gets compromised" vs "whomever is hosting js gets compromised". Right?

Facebook could afford a security team just as capable as Apples security team, and make sure the js server remains secure. And if they can't, their own signing procedure can get compromised before the app is uploaded to Apple for review.

I'm still not seeing the difference. Anyone?

Because the binary is served from a marketplace that works with an app that you trust and that will verify the package signature. Or, the web browser does not behave like a package manager.

So it would need a browser plug-in instead of just a web page? That seems fair enough. Extra kudos if they manage to use a standard plug-in for several websites. Maybe we can even get some kind of standard for this.

Reply on news.ycombinator.com