Re: security of a client-side JS API?

Hi Ryan,

I truly appreciate your extraordinary patience and open-mindedness in
continuing this discussion!

> The security model of the API does not attempt to defend against the
> site the user is interacting with being hostile

I'm glad we agree on this point -- already I think just making this
explicit in the specification would go some way to protecting
developers and users.

> - that's not an
> achievable goal within the security model of javascript or the web.

As I've discussed, I think it is achievable to provide security for
web users, if crypto is provided as to a built-in feature of the
browser (or a browser extension), under the user's control, and
isolated from the web app.

>> 2.2. Protected Document Exchange & 2.3. Cloud Storage
>> Attack: The web app indicates to the user that a document is being
>> encrypted, and requests a public encryption key, but retains an
>> unencrypted copy of the document.
>
> Yup. Totally possible - unless of course the user is using a
> multi-party exchange system, whether through SysApps or redirection or
> iframe or any of the other various ways that the origin-based security
> model is still relevant for.

That's very interesting -- I would need to study it more. But it
sounds very difficult for the user to verify (not to mention
understand).

> As a counter-point for why I don't think the above threats are
> particularly damning, is that any web server today could send a form
> that, in terms of display text, said "I authorize site X to deduct
> $100 from my account", but in terms of <form> content, communicated a
> deduction of $1000. So the disconnect between presentation and
> practice has existed and will continue to exist, regardless of this
> API or not.

That's right. Indeed, with the proposed Crypto API, the user might
intend to digitally sign "I authorize site X to deduct $100 from my
account", but the web app surreptitiously signs "I authorize site X to
deduct $1000 from my account" with the user's key, on their behalf!
The Crypto API thus gives the false impression of stronger
authentication, and thus paradoxically makes it harder for the user to
contest the fraud. Here the false appearance of security is worse than
a clear lack of security. Whereas, a truly user-controlled digital
signature feature (isolated from the web app) would provdie much
better protection against this kind of fraud.

> Now, it's certainly possible for there to be an API proposed that
> moves more and more into "unspoofable" chrome (that is, outside the
> purview of content script), but so far, none of the use cases imagined
> or actively worked on by participants has found such an API
> particularly necessary.

One doesn't need to imagine it -- HushMail actually used a backdoor in
a web-based java applet to steal user data:
http://www.wired.com/threatlevel/2007/11/hushmail-to-war/

> Further, when combined with sysapps and/or
> inter-origin communication methods, it may not even be necessary.

I don't see how these techniques prevent the original server from
stealing data as HushMail did.

> Since you suggested you object to this API as is - can you describe to
> me: Does this API make it any worse than what people are doing today -
> implementing algorithms in JavaScript (perhaps with timing or
> correctness issues)?

It's not worse in a strict technical sense, because this API and
existing custom solutions share the same security problem. But, yes, I
think it's worse in a practical sense, because it lends this practice
(content script crypto) a legitimacy I think it shouldn't have.

> Can you agree that this API suitably *improves*
> the situations for those site authors?

Not really, because they are still exposing a major security hole.

To compare the two alternatives, point-by-point:

1. The currently propsed WebCrypto API, as used in client-side JS
 a. Doesn't provide security beyond TLS for most of the use cases
listed (the web app provider must be trusted)
 b. Requires users to make decisions about using keys and thus
encourage the expectation of additional security
 c. Must be understood by developers for each separate web app
 d. Encourages numerous, effectively closed-source scripts using the crypto API
2. A user-controlled, open source, browser crypto extension or a
built-in browser crypto feature would
 a. Provide substantially better user security for all use cases
considered by the WG (web app providers need not be trusted)
 b. Give the user a true picture of, and control over, what
cryptographic operations are performed and what data is provided to
the server
 c. Work on all existing websites, and require little or no web-app
developer involvement
 d. Enable open-source crypto usage in browsers or browser extensions

> As per our charter, those are
> our current goals, and were discussed extensively during chartering
> discussions.

Perhaps you'll let me summarize the overall web security problem, as I
see it. The web is, of course, one of the most important mediums of
communication in many developed nations (particularly if we include
webmail and webchat). For technical and historical reasons, the web
model has severe privacy leaks, and this means that people who are
politically active are vulnerable to eavesdropping. Taking advantage
of this vulnerability, a number of governments around the world are
comprehensively wiretapping millions of people. Telecoms and web app
providers are assisting this online spying. Democracy is in danger as
a result. Corporations are also using personal communications for
targeted marketing in a way that many people find very invasive. And,
of course, criminals exploit web vulnerabilities of various kinds.
Many of these attackers have the wherewithal to compromise web app
scripts to steal user data. At the same time, there are no accessible
encryption options for the typical, technically naive, web user.

Now, I understand that this overall problem may not be the original
motivation for your charter. But if your charter forces you to ignore
these big issues, then perhaps the charter needs to be amended. I
think it requires only a minor shift in viewpoint to change the
proposed API from one that at best provides little advantage over pure
TLS (and moreover encourages bad practice and will likely confuse
naive users) to a standard (user-controlled, end-to-end encryption
isolated from individual web app scripts) that robustly solves all of
the use cases specified in the charter and draft, as well as addresses
the privacy crisis I am talking about. It would be a great pity to
miss this opportunity to significantly change the world for the
better, just because of narrow wording in the charter. Who would be
more qualified to work on this problem than the members of the Web
Crypto Working Group?

The simplest tweak might be to require that the proposed API be used
only in browser extensions (outside web app JS). Even better would be
to propose a built-in browser UI standard, enabling users to easy
encrypt and decrypt, and sign and verify, text and files in a manner
completely under their control.

Thanks for considering my suggestions!

Best regards,
Arthur

Received on Monday, 5 November 2012 04:31:50 UTC