Re: Javascript integrity concerns

 Dear Ryan and Mark!

 Thank you for your prompt replies!

 Mark, if I understood correctly, the method you suggested is capable to
demonstrate to the host, that the message sent by the UA is produced by a
verified script. Although this can be really useful in some cases, my
concerns are about the verification method in question, because I believe
that it is not enough to prove that the script is identical to the one on
the host - as it can be modified by an offender - but it should be
gauranteed that it is the same as the one, that the developer had written.
However, sorry, if I misunderstood you.

 Eventually, as Ryan recommended, I'm going to ask the members of
WebAppSec WG too, because this topic seems to be much more related to this
WG, indeed.

 Thank you again, and good luck with the development of Web Crypto API. I
hope that we can see it in the browsers soon.

 Best regards,
 Bence Ágg

 On Fri 20:07 , "Mark Watson" watsonm@netflix.com sent:

 On Fri, May 17, 2013 at 10:33 AM, Ryan Sleevi  wrote:
  Thanks for the comments bence - response inline.

 On Thu, May 16, 2013 at 5:05 PM,   wrote:
 > Dear Members of Web Crypto API Team!
 >
 > Firstly I am really pleased to read about the great achievements done
by the
 > Web Crypto API team, because it has the potential to eliminate most of
the
 > wide spread concerns with browser based cryptography. Also I really
looking
 > forward to the implementations in browsers.
 >
 > However, as an amateur web developer I think there is one important
weakness
 > of this API, that is as follows. Several "weekend developers" - for
example
 > me - will start to use this API serving their javascript code from
cheap,
 > shared hosts. Even if they provide a web application with a secure
 > connection (https), they can not guarantee that the integrity of the
served
 > javascript files is not compromised by curious employees of the hosting
 > provider, or attackers who gain access to these loosely protected
servers.
 > In the meantime the above mentioned developers - not knowing these
problems
 > - would advertise their web application as super secure and they may
claim
 > that "customers can provide their most confidential data without the
risk of
 > abuse". If users do provide their confidential data curious employees
and
 > attackers may feel much temptation to simply modify the javascript code
and
 > gain access to the raw unencrypted data.

 (Un)fortunately, we cannot prevent people from making false claims.
 That's the nature of human conversation since time immemorial. Plenty
 of sites still claim that XOR/ROT-13 is a "security solution", or
 their "clever" schemes of AES-ECB with a CRC32 = cryptographically
 protected.

 It's a non-goal to prevent the false claims, but it is a goal to
 enable real claims to be made, and the current API does permit a
 number of strong applications to be developed in a space that they
 cannot be today.

 >
 > So I think there should be some signature method to guarantee the
integrity
 > of the javascript code, in the sense that the script downloaded by the
 > browser is the same as the one which was written by the developer, and
not
 > the one on the host, because the latter may be broken.

 That signature method already exists. It's called HTTPS. It can
 further be enhanced with CSP and certificate pinning.

 If you don't trust your host, you have more fundamental problems.

 While the naieve response would be to suggest that the problem you're
 describing is addressable with "signed scripts" (something Netscape -
 note, pre-Mozilla Co/Fo - had attempted), the reality is that it's
 much more complicated than that. Simply delivering signed scripts
 wouldn't be enough - since an attacker would simply strip off any
 signed scripts and replace them with unsigned scripts, particularly if
 they have physical access to the server.

 Instead, you're problem space would (minimally) also need some form of
 key continuity scheme, such that clients that received signed scripts
 would continue to expect signed scripts. This would be the conceptual
 equivalent of perfect forward secrecy for TLS - even after the
 compromise of the key (or, in this case, the server), *existing*
 sessions would still be protected.

 While crypto would almost certainly be involved in such a discussion,
 I would suggest it's a much better conceptual match to the work of the
 WebAppSec WG, since the model of the threat and attack really have
 less to do with cryptography than they do with a hostile server.

 >
 > I was thinking about this problem for a long while, and concluded that
it
 > can not be solved without integrating a sanity check into the browser
(or
 > into a plugin, which could be much more cumbersome).
 >
 > However, I might be wrong, as I am only a weekend developer, and also I
am
 > not sure whether this issue stays in the scope of Web Crypto API. Also
there
 > may be as much as a thousand letters in the public mail archive which I
did
 > not read through, so I am sorry if this is an already known or solved
 > problem, or a duplicate of an existing issue.
 >
 > Best regards,
 > Bence Ágg
 > http://suopte.com/en/ [1]
 > bence@suopte.com

 There has been some discussion in WebAppSec regarding "script
 signature validation" or hash validation of some kind, so I suspect
 you'd find a receptive audience there. No guarantees, however.

 This WG primarily focuses on APIs that enable the use of cryptography
 once you have bootstrapped your 'secure environment' (eg: via HTTPS,
 CSP, some-future-web-security-method, etc). This allows you to
 continue operating securely - and to enable more robust applications.

 +1 to Ryans point above.
 There is a possible WebCrypto angle, though. In the case where the UA has
verified the script in some way (whether HTTPS or some future script
signing mechanism), WebCrypto could offer the script the possibility to
obtain some attestation to this fact. ekr suggested a "signed-by-origin"
method in which signs a message provided by the script using a WebCrypto
key but also attaches, within the signed portion, the origin of the script
and the certificate chain that was used to verify it. 
 Like the extractable attribute and the key wrap/unwrap methods, this is
only useful if you have some reason to trust the UA and to believe that the
key being used is genuinely in the UA.
 ...Mark  
 Cheers,
 Ryan

 

Links:
------
[1] http://suopte.com/en/