Re: security of a client-side JS API?

On Wed, Oct 31, 2012 at 4:54 PM, Arthur D. Edelstein
<arthuredelstein@gmail.com> wrote:
> Again, Ryan, thanks for your time and effort in answering my questions.
>
>> > What sort of legal reasons do you have in mind? I think if legal protection
>> > for providers is the most notable motivation for providing the Crypto API,
>> > that should be explained in the draft, as well as any other important
>> > motivations.
>>
>> I think you misunderstood what I meant.
>
> Sorry about that, I did indeed.
>
>> If a provider is wishing to accept some form of signature as being
>> provided by a user (say, for document signing), then the provider is
>> typically legally (via appropriate government standards) prohibited
>> from key escrow, which is effectively what you are suggesting.
>>
>> So no provider will want to, or necessarily be able to, keep the
>> private key that is supposed to identify the user *on the server*.
>
> I had the impression from the API spec that crypto operations would
> use private keys without exposing to the web app the actual value of
> those private keys. Nonetheless the user would still be exposed to
> signing the wrong document. So I still think stating in the spec that
> legal protections are required for this part of the API to work, is
> very important.

No work within this WG is attempting to guard against malicious script
of that nature. You are absolutely correct that the user may be
induced to sign the wrong document, but within the current security
model of the current API, that is acceptable and not part of the
threat model.

>
>> > But I think it's also important to mention the issue of hostile web bots --
>> > it's really impossible for the server to trust crypto results from the web
>> > client.
>>
>> And that's not a goal of the API.
>
> Why is signature verification included in the API, then?

Just because it does not solve a single particular problem, does not
mean it does not solve any such problem.

A user, using a user agent, to interact with a trusted site, may use
the signature verification operation to verify data received from
third-parties through any variety of means - directly from the trusted
site, from an API such as WebSockets or the like, from external
resource loads from (untrusted) third-party sites, etc.

The security model of the API does not attempt to defend against the
site the user is interacting with being hostile - that's not an
achievable goal within the security model of javascript or the web.

>
>> To put it differently, "it's really impossible for the server to trust
>> form results from a web client over TLS" - no matter how much client
>> JS validation they put in.
>
> Exactly.
>
>> >> But even more broadly, how does this at all differ from native
>> >> applications? They're just as dependent on the platforms cryptographic
>> >> stack. Servers have no control over that end.
>> >
>> >
>> > Yes, I agree. Which is why server-side crypto is necessary for the securing
>> > the provider's data. Platform vulnerabilities are a problem, but that
>> > doesn't excuse vulnerabilities in user agents.
>>
>> I apologize, but with the context with your earlier remarks, I'm still
>> not entirely sure the point you were originally trying to make or
>> where the gap is, but would be happy to try to better understand.
>
> Sorry, perhaps I don't understand your point about native apps. I
> agree that native apps have similar vulnerabilities, but I don't
> understand why that is relevant to the question of whether this API is
> useful for providing security.
>
>> >> Perhaps I'm mistaken, but we're not trying to necessarily provide new
>> >> security guarantees over existing native applications - we're
>> >> attempting to bring (some of) the same security model to the web -
>> >> which suggests improving the web security model.
>> >
>> > I'm arguing that you're not improving the web security model.
>>
>> That is correct. We are not trying to improve the web security model
>> and that is not part of our charter. WebAppSec is the general W3C WG
>> for focusing on such security issues.
>
> I'm sorry, I misunderstood your phrase "suggests improving the web
> security model."
>
>> > Web browsers
>> > already support secure communication between a provider and a user agent (by
>> > TLS), but users are forced to trust the provider with their (user) data.
>> > This API, even with CSP, similarly requires that the web app provider be
>> > trusted by the user not to leak data.
>> >
>> > So all the additional cryptographics primitives, because they are untrusted
>> > by both users and providers, don't plug any holes that weren't already
>> > plugged by TLS.
>>
>> This is true for some use cases, but is not true nor applicable to the
>> broad set of use cases already collected. My suspicion based on this
>> response is that you're looking at this API with a particular use case
>> in mind, and deeming it unable or unwilling to address that use case.
>> This is quite possibly true, and it would be good to understand that
>> use case.
>
> No, I have in mind the use cases in your draft. Here's the attacks I
> see (Forgive me if I'm misunderstanding something fundamental. I think
> these concrete cases really illustrate my concerns and help to clarify
> what I have been attempting to express.):
>
> 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.

>
> 2.4. Document Signing
> Attack: The web app presents the user with a document to sign,
> requests a key from the keystore for signing, and then invisibly uses
> that key to sign a different document.

Yes.

>
> 2.5. Data Integrity Protection
> Attack: The User Agent provides a false verification of stored data.
>

Sure.

> 2.6. Secure Messaging
> Attack: The web app steals plaintext OTR messages after they have been
> decrypted for display to the user.
>

Absolutely.

> 2.7. Javascript Object Signing and Encryption (JOSE)
> Attack: The User Agent provides a false verification, or the web app
> steals decrypted user data.
>
> Two I'm less sure about:
>
> 2.1. Multi-factor Authentication
> I admit this may be secure (I'd need to study it more), but I don't
> see any advantage over TLS + server-side multi-key verification.
>
> 2.8. Out-of-Band Key Provisioning
> I'm not sure I understand what crypto operations the web app client
> side is performing here.
>
> So, what prevents these attacks from happening? Isn't this a serious
> problem for the API design?

No. The web trust model inherently has to have at least one site (the
source of the JS about to execute) as part of the trust model. That
said, just because *one* site has to participate in the trust model
does not require that all sites participate in the trust model, and
there is still useful benefit exposed by this API.

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.

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. Further, when combined with sysapps and/or
inter-origin communication methods, it may not even be necessary.

>
>> That said, and as I mentioned earlier, you can use this, **in addition
>> with other APIs**, to implement exactly what you propose [end-to-end encryption]. For example,
>> using system apps/extensions/webapps/whatever your browser vendor or
>> standards body of choice calls them, you could implement a secure (eg:
>> NOT part of the target origin) application that provided input
>> methods, and output encrypted text.
>
> Exactly, and if the Crypto API were limited to this usage, I would
> have no objection. I'm concerned about its exposure and use in web
> apps.

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)? Can you agree that this API suitably *improves*
the situations for those site authors? As per our charter, those are
our current goals, and were discussed extensively during chartering
discussions.

>
>> You can already see this model in extensions like CryptoCat, to some
>> degree. The utility of this API, in such a scenario, is that it makes
>> it *easier* to develop such applications, and ideally, *more
>> efficient*, and does not require such extension/app authors to be
>> fully versed in the implementation details of how SHA-1 is
>> implemented, and can instead be aware that SHA-1 should be used (for
>> example).
>
> I agree, absolutely.
>
>> > Browsers could provide a means for users to encrypt the text the wish to
>> > enter in a TextArea, to display decrypted text, and to encrypt and decrypt
>> > files, all safely outside the page's JS runtime. This enhancement would give
>> > users of existing web services, such as web-based email, chat and file
>> > storage a major security boost. PGP and OTR modes would both be useful.
>> >
>> > Is there any chance the Web Crypto WG could recommend this kind of browser
>> > end-to-end crypto design? I think this alternative offers huge advantages
>> > over the proposed API for addressing the use cases you describe in the
>> > draft.
>
>> And thank you for your feedback! It's provided an excellent
>> opportunity to provide a better explanation of what we're (currently)
>> trying to do, and hopefully provides some context as to where this
>> fits in the overall web platform. Hopefully we'll be able to provide
>> more high-level details (eg: not directly in the spec) that may help
>> better demonstrate where the current spec sits, and where the overall
>> work in the WG fits within the web platform. I think you'll find that
>> we're actually working towards the same thing,
>
> Yes, I'm sure we are. I am looking forward to hearing more details at
> your meeting.
>
>> just at different
>> levels and with the understanding and assumption that some of the
>> problems you raised are either already addressed or being addressed
>> elsewhere within the W3C and the web community.
>
> If you have any hints on who in W3C might be working on a proposal for
> an end-to-end encryption standard for the browser, I'd be very
> grateful! I haven't found it yet. :)
>
> I hope your meetings go well and that you're enjoying Lyon in between
> answering my emails!
>
> Best regards,
> Arthur

Received on Saturday, 3 November 2012 20:40:12 UTC