Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

I don't think it's a good idea to provide secure messaging services that boot from a web page, under any circumstances.

This stuff has to work. The adversary for secure messaging is world governments. If all you're worried about is criminals, Gchat will do a fine job of protecting you. For a vivid example of what I'm talking about, see the Telegram/Iran fiasco.

It's hard enough building secure messaging in a native application; there are lots of details that are not easy to get right (as Cure53 demonstrated to your team).

Bluntly: I feel that it's irresponsible to add to that portfolio of difficulties the added attack surface of content-controlled Javascript.

The reason people build services like this is that users will prefer them to (more secure) native app alternatives. It's easy to see why. The common response to this observation is: "but users won't install an app". They won't install an app because people keep luring the away with insecure web-page based secure messengers.

Hey Thomas, thanks for the comment; I'd been wanting a chance to get your thoughts on WebSign for ages!

While our audit demonstrates that this scheme shouldn't be expected to be cracked without a critical vulnerability making its way into your browser, it does introduce some odd dependency relationships that certainly introduce new attack vectors not seen in the TOFU property of regular standalone apps.

For example, given that the NSA can be assumed to be indiscriminately passively logging all HTTPS traffic, imagine that one day they gain the capability to break 4096-bit RSA: in a targeted attack scenario, suddenly they can now go back through their traffic logs, find whichever public key is pinned in a particular Cyph user's browser, compute the associated private key, and undo method #2 as descried in the linked reddit comment (the "permanent offline" trick), which gets them half of the way toward completely breaking that user's TOFU.

That having been said, I consider it a perfectly acceptable and pretty neat solution to the problem. Is there something else you're seeing that makes you object to it?

Edit: If your objection isn't to WebSign but to the Web / JS as an execution environment in general, I'll throw in a link to this note on how we're mitigating those traditional risks while also benefitting from the sophisticated sandboxing of modern browsers: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...

Cure53's report details a complete bypass of WebSign as implemented, as well as stern warnings against relying on a non-security feature for security.

Not denying the increased attack surface, but that bypass was immediately fixed and verified by Cure53 (so no known vulnerabilities exist); furthermore, as you'll see in both our foreword to that report and the linked reddit comment, the current version of WebSign actually no longer has that general flaw.

Breaking WebSign would require defeating TLS public key pinning (which is a security feature), thanks to the technique that an email I just received so perfectly referred to as "HPKP suicide".

Am I understanding correctly that you consider your adversary to be the National Security Agency, the world's best funded, best equipped, best staffed SIGINT agency, and that you think they're limited to passive observation?

Again: I just think this is a bad idea. I'm sure you're great people, but cryptographic security is hard enough for native apps, without trying to deploy it in the jungle gym of some random browser runtime.

You should stop deploying this app from a web page. Altogether. And soon. Port it instead to be a Chrome extension that users install.

I'm sure you're not hurting anyone right now. But you've built the kind of application that will, if it ever gets to be very successful, probably get people hurt. Better instead to work on something that will help people more as it gets more popular.

Am I understanding correctly that you consider your adversary to be the National Security Agency, the world's best funded, best equipped, best staffed SIGINT agency, and that you think they're limited to passive observation?

No, you aren't; the example was to illustrate an entirely different point.

Again: I just think this is a bad idea. I'm sure you're great people, but cryptographic security is hard enough for native apps, without trying to deploy it in the jungle gym of some random browser runtime.

Do you have a specific criticism, or is your argument more of a general point that solving multiple hard problems is more difficult to do correctly?

If that is what you're getting at, it seems like it would be effectively addressed by frequent audits of the Cyph source code.

There are very specific concerns I have about implementing secure cryptography in a browser runtime. I wrote an article about this a while back. I don't love that article and never did, but one complaint I've heard about it is that it's "dated". In fact: I think the last few years have made it harder to securely deploy crypto in a browser. So one short answer is, for a bunch of fiddly reasons, I think you're building one of next year's Black Hat Briefings talks.

But the broader concern is, in fact, that by offering people a secure messenger, you're accepting some responsibility for securing traffic that can jeopardize lives if you're compromised. You have, I think, a moral responsibility to be as conservative as you possibly can be. When someone gets hurt because this system is flawed --- assuming you ever learn about it --- I think you're going to be surprised by where it happened. People with causes you've never even considered will use this thing in ways that, if you knew about, you'd say "fuck! stop! i like my application but i can't let you bet your life on it!".

It's great that you paid for an audit, but audits aren't magic feathers. If you got audited again by a strong team, they'd find other things you missed. As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces! Crypto is hard even on the "easy" setting. You've got the difficulty setting dialed all the way to "nightmare".

Dial it back down.

There are very specific concerns I have about implementing secure cryptography in a browser runtime. ...

What are your thoughts on our strict uses of asm.js for the actual encryption (libsodium) and static typing for the rest of the code via TypeScript?

I'm aware that asm.js isn't literally native code, but we and, (without putting words into their mouths) I believe, the Cure53 team felt that these were both very effective mitigations to the risks you point out. Combined with a strong CSP and an entirely Angular-based UI (so no silly mistakes like untrusted user input in jQuery selectors, and to date no known XSS), I would say that Cyph is vastly different from a project like Cryptocat.

As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces!

It was an accident, in pre-production code. (And hardly "nightmare"-level; it was one nonce reuse that only occurred during the initial handshake, and notably wasn't obviously exploitable.) That was also the only bug found by 5 experts over 12 days in the entire protocol implementation[1], which I would say is more impressive than not.

The whole point of that audit was to catch those sorts of silly mistakes before we switched away from OTR in prod.

This also has nothing to do with WebSign or the impact the browser has on our attack surface; we could very easily switch back to the asm.js libotr cross-compilation we'd been using if Castle turned out to be unfit for production.

---

1: There were three Castle-related findings, but only one was in the Castle implementation. One was an outdated/no-longer-correct statement in a document and one was a configuration weakness elsewhere in the code.

> But the broader concern is, in fact, that by offering people a secure messenger, you're accepting some responsibility for securing traffic that can jeopardize lives if you're compromised. You have, I think, a moral responsibility to be as conservative as you possibly can be. When someone gets hurt because this system is flawed --- assuming you ever learn about it --- I think you're going to be surprised by where it happened. People with causes you've never even considered will use this thing in ways that, if you knew about, you'd say "fuck! stop! i like my application but i can't let you bet your life on it!".

I agree with you about web crypto, but I disagree with this point. A point that Roger Dingledine (of Tor fame) made a few years ago was that people who are going to say something which their government doesn't want them to say are going to say it anyway. If they can't communicate using the internet, they are willing to make protests in the streets, to shout and scream to try to improve their world. The job of people making cryptosystems to try to keep such activists safe is to minimise risk and do the best they can. You shouldn't think that you're responsible for what happens to those people, you're doing the best you can for them. But at the end of the day, they are willing to die for their goals and it is disrespectful to ignore that fact.

But yes, I agree that the service in question probably needs much more work. And it should probably say "this is still Alpha".

I felt that that was a perfectly fair statement on Thomas's part. It's fine if people are willing to risk their lives for a cause, but they shouldn't be misled into outright sacrificing their lives because someone irresponsibly marketed a tool as being suitable for a particular purpose.

I'm also not sure where you get the impression that Cyph is currently at an "alpha" stage, but I'm going to have to disagree with you there too. Do you have more specific feedback, and/or did you run into a bug while using it?

There are plenty of casual users who want the capability to have one-off conversations without worrying about who might be intercepting and storing the conversations, let alone without having to install anything new and try to convince their friends to use it too. This is made with them in mind.

I see where you're coming from with the added attack surface argument, though I'd counter that browser sandboxing actually makes a web application safer for this use compared to creating a native application on the basis that if the native application is exploited, all user-mode data is now at risk. At least with the containment of the browser, the only things at risk are (potentially) your messages assuming successful XSS.

So long as the proper mitigations are in place, it really makes no difference. The largest future improvement for Cyph in the future would be to incorporate one of the CSP2 changes for more safely allowing inlining, notably hash-src. However, since CSP2 adoption isn't all that widespread quite yet, it's better to hold off until the implementation details between the largest browsers are equalized.

Edit to address your last paragraph: "[Users] won't install an app because people keep luring the away with insecure web-page based secure messengers."

Native encrypted messaging apps have been around for a while and haven't really caught on unless integrated into existing apps a la iMessage. That's where the need for in-browser apps is coming from.

My 2 cents. I'm likely entirely wrong; you've got more experience in general AppSec than I do, so my assumption of risks here might be off-base.

If you want to have a one-off conversation without worrying about someone intercepting and storing your conversation, use Google's IM protocol. You won't have to install anything.

If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a messaging application that boots from a web page.

For those serious adversaries, users need real secure messaging solutions, and today, they need to install software to do that.

> all of them are likely to be able to compromise a messaging application that boots from a web page.

All of them are likely to be able to compromise your OS, the Intel Management Engine (http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...), your flash drives, the baseband on your blackphone... There's so much code, so many layers of abstraction involved in doing even the most basic things and so many things for which the US IC (let alone the 5E) almost certainly has exploits for that this quoted line is entirely moot when put in the context of attack economics.

I was looking for any insight you might have into why a web application with the latest in protections surrounding the execution of unauthorized code and running in a sandboxed browser would still be more vulnerable compared to a native application running in usermode, but then you said...

> and today, they need to install software to do [address serious adversaries].

I guess I can keep looking forward to someone else to address the point you tried to raise, since your position seems to be more of an emotional one. The only way we'll be able to advance privacy is by advancing ease of use. Web applications do a good job of providing that, and the IETF and browser makers are doing an excellent job of creating and integrating security standards to allow developers to bring that ease of use to realms of secure computing which traditionally required extensive manual configuration.

Do you want wider adoption of security and privacy-assuring technologies by the general public? Be like the rest of us in the AppSec community and support the devs who try to advance the state of the art.

That's what people who supported Cryptocat said. It's also what people who supported Telegram said.

Not interested in this argument, sorry.

> That's what people who supported Cryptocat said. It's also what people who supported Telegram said.

> Not interested in this argument, sorry.

You shouldn't have started it then.

I didn't. I was mentioned upthread.

all of them are likely to be able to compromise a messaging application that boots from a web page

So this is really the fundamental disagreement. What makes you think that running a WebSigned app in a browser is significantly more exploitable than a native app?

The way I see it, the worst thing that can be said about WebSign is that it breaks the chain of trust — i.e. that first download is implicitly trusted without any validation from a root certificate preloaded on the OS, whereas an app installed through a well designed package manager wouldn't have that problem. However, downloading a regular old executable through HTTPS is no different, and I don't see you calling that out in the same way.

Beyond that issue, I would argue that the browser sandbox offers a more sophisticated and well vetted layer of protection than you would see in just about any native app framework, which leaves XSS as the primary risk (and Cyph has never had a known XSS bug anyway).

Zero is the number of software security researchers who would agree with you that a program booted from a web page via content-controlled Javascript code running in a browser tab is as secure as a native application.

Beyond that, I'm sorry, I'm just not going to go into further details in an HN thread. I don't think many people here think I'm just making stuff up, but in case you're worried about me saying "I told you so" down the road when someone else publishes, here's a fingerprint:

b2b90c80626b1ba036bd87abc0741e1c69d2f6da398018de00b52a3cb9fe2121

Sure, "zero", except the researchers who actually audited it and concluded exactly that: http://pastebin.com/HcL5bneg

Every reply you've made here seems to have been either an appeal to your own authority or a claim based on a browsing environment circa 2005. You haven't pointed to a single specific flaw in WebSign's architecture, so I can only assume you won't go into further detail because there is no further detail.

This conversation was certainly enlightening (if nothing else, at least on our technical messaging). Thank you for the feedback.

That's not what that message says, but maybe you could email your auditors and ask if they'd stand by the assertion you're making that native apps aren't safer for cryptography than browser apps.

As for the rest of it: I'm sorry you feel that way, but I've reached a point in my message-boarding career where, after many, many years of fighting the good (then marginal then tedious then bad) fight, I'm just not going to litigate this issue anymore. What you're doing is now is a bad idea, and for the sake of your users I think you should port to a browser extension (and, eventually, to a native mobile app) as soon as you possibly can. Maybe you can improve your security before your popularity gets out of hand and avoid the fate Telegram seems to be falling into.

When new web standards make browser crypto viable, I'll acknowledge them. Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.

> I think you should port to a browser extension

Chrome extensions are HTML5/JS... which wouldn't stand to your own argument.

> Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.

You're saying IE6 and Firefox 1.0 were better for cryptography than our environment today? We've got effective standards like CSP and CSP2 for restricting code execution client side, SRI for validating resources hosted beyond trust boundaries, HPKP and HSTS for ensuring trust on TLS connections, and we have cooperation between major browser vendors to implement patterns like HSTS preloading and even certificate preloading for certain sites such as Twitter, environment sandboxing introduced as early as 2007, and your assertion is that the browser environment now is less hospitable to cryptography than in 2005?

You were right a few comments ago; there's no point debating this any further. I have to do some shoveling anyway.

No, I'm saying that web standards were more hospitable for crypto.

The mic drop at the end of your comment would have been more dramatic had you been replying to a comment addressed to you.

I'm just not sure how you expect me to take your position seriously and blindly follow it, when your reaction to the information I've presented is to pretend that there's literally no difference between WebSign/Cyph and something like MEGAChat. I felt that the "HPKP suicide" hack (which is something enabled only by recent Web standards) was a stroke of genius on Cure53's part; in the very least generous interpretation, it obviously still isn't equivalent to the security of a vanilla Web application, which you seem to be suggesting.

As far as Mario's statement, while you're correct that it doesn't explicitly compare WebSign with installing a native app, it was made in the context of a threat model that assumed that level of security. This is why the one WebSign bypass exploit they found[1] was flagged as High — in any other Web app it would simply be a given that the server can serve new code.

re: browser extensions, what WebSign provides is comparable, except without sacrificing the security benefits of the restricted privilege set of a standard Web context. (i.e. A vuln in Cyph wouldn't put more than just your browser tab at risk.)

---

1: This was immediately fixed, and then the HPKP rotation scheme Cure53 came up with was soon added on top of that fix.

So, if you're still reading this thread, I have one last question: what advantage do you think a browser extension has over WebSign as I've described it?

I'm asking explicitly because, since you still maintain that the extension model is objectively more secure, at least one of us is clearly missing something very important.

Reply on news.ycombinator.com