Hacker News Reader

Comment by buu700 | Hacker News Reader

Since no one else has explicitly brought this up: https://tonyarcieri.com/whats-wrong-with-webcrypto (also see Matasano's "JavaScript Cryptography Considered Harmful", etc.). There is nothing that a service like this will protect you from that you don't already get while using TLS in just about every insecure/non-E2EE chat service.

If you're looking for actually secure communication that runs as a Web app, my startup Cyph (cyph.com) is the only option that exists. This is because we put in the time to build it correctly; the root page of our application is a permanently pinned (TOFU) bootstrap that validates/executes signed application packages, and the scheme to accomplish this was rigorously vetted in a 12-day audit.

Edits:

* Here's how it works: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...

* Here's Cure53's audit report: http://cyph.team/cure53report

View on HN

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.

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.

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.

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

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?

> the scheme to accomplish this was rigorously vetted in a 12-day audit.

Vetted by whom? It would help build trust if there was a public report on the strength of your implementation available somewhere.

Cure53. The report is public on both their website and ours: http://cyph.team/cure53report.

(That link contains a page of additional context to explain the findings, e.g. some were pre-production.)

And the original, for anyone who wants it straight from Cure53: https://cure53.de/pentest-report_cyph.pdf

I don't know what you mean by, "permanently pinned (TOFU) bootstrap", but the fact that it "validates/executes signed application packages" doesn't sound like it protects the end user from you sending them a "signed application package" which contains something to steal their keys/messages...

If you could post a link explaining how this tech works, I would be very interested in reading about it...

It doesn't protect users from that yet (neither does Signal or any other alternative), but we are about to implement reproducible builds to help mitigate that by allowing users to independently verify that the deployed production build matches up with our source code on GitHub.

That having been said, my cofounder and I are the only two people with the keys to sign releases (and as long Cyph exists they'll only ever be held by either ourselves or an equally small set of individuals deemed worthy to trust with our lives) — so you shouldn't ever expect that kind of deliberate backdoor, even if I end up in prison for refusing. We're also maintaining a strong focus on OpSec of these keys, e.g. we're about to migrate the release signing off of our (full disk encrypted) personal laptops to a dedicated air gapped environment.

As far as how the tech works, we don't have a great explanation on the website yet, so this reddit comment will have to do for now: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp.... There's also a visualisation in http://cyph.team/producthandout, if that's helpful.

Nice to hear that you say you have nothing up your sleeves. I believe you don't, but if you were an agent for a covert agency you would make the same claims, so they mean nothing.

As for opsec on keys... the only thing making key extraction remotely difficult by a state actor is probably some form of hsm - but recalling the xbox 1 crack, I don't know how well even those stand up in practice. For everything else, I assume you're just a sneak-and-peak warrant and some cameras/listening-devices away from sharing your passphrase.

Don't get me wrong, I think it's great that people are working on secure chat applications. I just think one needs to be very careful making claims that end up on the side of being secure against state actors.

Definitely agreed re: the meaninglessness of my promises; if someone's threat model were to include that degree of trust in a complete stranger, then there would be no point in that person using encryption to begin with.

Also agreed on all other counts; if all else failed, I have no doubt that a state actor could certainly extract our keys through targeted physical surveillance and/or force, which I don't think there's really a good workaround for short of raising our own army to protect a private bunker for air gapped release signing.

What this first iteration of the air gapped environment is meant to accomplish is to simply make it that much harder. Sure, the CIA can still probably break into my home and set up a surveillance camera to steal the encryption passwords of my keys without my noticing, but what they will no longer be able to do is steal them by tampering with my laptop while my head's turned in broad daylight.

As Cyph continues to grow as a company, we expect to have the resources to implement increasingly sophisticated OpSec measures.

From your site (attributed to cure53): "Cyph provides security from a broad range of cryptographic attacks"

From the actual conclusion: "Cyph claims to provide security from a broad range of cryptographic attacks"

Whats the deal here?

Good catch. Mario actually provided a marketable quote via email (signed and all). Although that quote is intended as a one-sentence summary of Mario's report, it's not strictly a quote out of the report as much as it is strictly a quote from Mario. Therefore, the source on the quote might more accurately be attributed as "Mario Heiderich in summarizing the Cure53 pentest report."

The thinking there was that there wasn't a good way to quote any single part of the report without introducing unnecessary and/or fishy ellipses, because although the point of the rest of the conclusion is that it confirms the claim made by Cyph, there wasn't a readily available standalone sentence in there which could go on the front page.

Background: I advised Cyph on AppSec topics on behalf of Mach37 as a mentor, and I helped coordinate the Cure53 pentest. I'm the one who sourced the quote.

Give me a few moments (or days; we'll see) for me to find a good way to publicly and non-repudiably present the exact source of the quote.

Edit:

Signed statement: http://pastebin.com/HcL5bneg

Key: https://keybase.io/cure53

Hat tip to Mario (https://twitter.com/0x6d6172696f)

Cyph looks great but there are a number of secure applications that only work on desktop or only work on mobile and I'm yet to see one that does both.

Cyph of course runs in a mobile browser but unless I missed something, it doesn't support notifications, which are important. Is there any chance of Cyph supporting push notifications on mobile devices in the future?

Which browser are you using? I'll have to test to confirm in iOS Safari, but the notifications at least work fine for me in Chrome and Firefox on Android.

However, native mobile apps are definitely on the roadmap.

Reply on news.ycombinator.com