Re: Verified Javascript: Proposal

Hi Brad,

> It does not address how to isolate an instance of a web application from other unsigned code

This is intentional. If the web app decides to run unsigned scripts
(by including it as a <script>, or eval()ing it - XSS is another
matter and out of scope for this proposal), it is up to the web app to
make sure that that's secure, for example (in the case of eval) by
manually checking the hash with some trusted source. mega.nz already
does exactly that - see [1], even though without HCS, it provides no
real added security, because there is no trusted source. However, with
HCS, the whole web application suddenly becomes secure.

The way you phrased it also makes it sound like you're worried about
some kind of external code (in another tab?) coming in and interfering
with the web app. Is that true? Subdomains are already isolated
origins, so if you host the "trusted" web app on a subdomain, you're
good to go, AFAICT.

> A mandatory CSP policy is applied that prevents eval and inline script and sets an object and embed src of 'none'

It sounds like you're trying to protect the user against the source
code. However, that's impossible. For example, you cite E2E messaging.
The #1 threat in E2E messaging is leaking the user's key. You
absolutely *have* to trust the source code not to do that, there's no
way around it. The only thing we can do is verify that the source code
is the same version every one else is running, and (with some extra
work) the same version as is hosted on GitHub (which is what this
proposal is trying to do), so that you can find out *whether* you
trust the source code. In other words, the only thing binary
transparency is trying to do is trust the *server* less, not trust the
source code less.

So, if you're going to trust the source code anyway, you might as well
leave it up to the source code to set a suitable CSP (in a meta tag).

> all further HTML, script and CSS loaded must be statically SRI tagged

Yes. I can see you're trying to answer the necessary second question
after binary transparency, namely: "how do I make sure that the whole
web app is included in the binary transparency". However, there are
many different ways to do that, and, given that we trust the source
code anyway, we might as well leave it up to the web app. I've already
cited one other way that one web apps does it (eval after verifying
hashes), here's another: make one portion of a web app signed and
trusted, and run another portion (the front-facing UI, for example) in
a sandboxed iframe and communicate with postMessage. Here's another:
store frontend code in localStorage, and give users a manual update
mechanism. The point is, there are infinitely many ways to make a web
app like that secure, and while forcing everything in SRI is certainly
an easy way to verify that it is so (although - how are you going to
verify the integrity of Service Workers and Web Workers?), it's
probably a very laborious way to actually accomplish it, and likely to
discourage developers from trying. Easier is to say "make a list of
all resources in your web app, and run this script to get their hashes
and update your certificate". Then, if you're worried about developers
forgetting a resource, we could show a red warning in the console, but
it should not be forced upon them.


> putting the contents of resources into a very static spot like the HTTPS certificate doesn't scale and doesn't allow the appropriate agility necessary for security

A HTTPS certificate is a very static resource now, but there's no
particular reason why it must be so. In fact, very short-lived
certificates have some advantages over long-lived ones, because they
obviate the need for revocation lists. Let's Encrypt is automating the
process of requesting a certificate. Gandi has a certificate API. I
don't see a reason why a non-EV certificate should take any
significant of time to update. certsimple.com is even issuing EV
certificates in three hours on average. Now, I admit that for most
CA's, the tooling is not there yet, but it's moving in the right
direction, and requesting a new certificate manually should also not
take that much time if you do it regularly. Then you also need an API
and tooling to upload your certificate to the server or reverse-proxy
CDN. AWS, CloudFlare, Heroku and KeyCDN have such an API. Now, again,
in many cases the tooling is not there yet, but it's possible and
people are working on those API's regardless of what I'm doing.

> Further, requiring transparency proofs in the certificate is a nearly impossible model to develop and test under.

While developing something unrelated to HCS, you can just use
localhost, or a test certificate without HCS on a test domain, or no
certificate at all (with --unsafely-treat-insecure-origin-as-secure in
Chrome if you need it), as usual.

[1]: https://github.com/meganz/webclient#secure-boot

-- Daniel Huigens

P.S. I have applied for I.E.


2017-04-25 23:34 GMT+02:00 Brad Hill <hillbrad@gmail.com>:
> Daniel,
>
> I would also like you to ask to please apply for a W3C account
> (https://www.w3.org/accounts/request) and apply to be an Invited Expert in
> the group.  Process here:
> https://www.w3.org/Consortium/Legal/2007/06-invited-expert
>
> We can't adopt any ideas you propose, and really shouldn't be discussing
> them as possible standards, without a contributor IPR agreement from you.
>
> thanks,
>
> Brad Hill (as chair)
>
> On Tue, Apr 25, 2017 at 2:31 PM Brad Hill <hillbrad@gmail.com> wrote:
>>
>> I must say, I don't think the threat and deployment model of this is very
>> well thought out, with regards to how real web applications need to work.
>> It does not address how to isolate an instance of a web application from
>> other unsigned code, and putting the contents of resources into a very
>> static spot like the HTTPS certificate doesn't scale and doesn't allow the
>> appropriate agility necessary for security.  Further, requiring transparency
>> proofs in the certificate is a nearly impossible model to develop and test
>> under.
>>
>> I've floated some strawman proposals around this idea previously, based on
>> Facebook's desire to build E2E encryption into a web version of Messenger,
>> similar to what we do with apps, where a primary goal is to have
>> transparency and proof of non-partition for the main application code. (if
>> not all resources)
>>
>> My very rough proposal for provably transparent and non-partitioned apps
>> that still work like webapps and don't have huge holes according to the web
>> platform security model is roughly the following:
>>
>> Utilize suborigins as an isolation mechanism.
>>
>> Define a special suborigin label prefix for which which a resource must
>> meet certain conditions to enter, and accept certain conditions upon
>> entering.
>>
>> To enter a labeled suborigin:  The suborigin is identified by a public key
>> as a special label prefix.  The primary HTML resource must supply a
>> signature over its body and relevant headers using that key.
>>
>> Upon entering that labeled suborigin: the effective suborigin becomes a
>> hash of the public key plus the hash of the bootstrap HTML resource, so that
>> it is not same-origin with anything else.
>>
>> A mandatory CSP policy is applied that prevents eval and inline script and
>> sets an object and embed src of 'none', and, upon entering that labeled
>> suborigin, all further HTML, script and CSS loaded must be statically SRI
>> tagged, recursively, such that the bootstrap resource hash uniquely
>> identifies the entire tree of reachable executable content. This can be the
>> basis of a binary transparency proof.
>>
>> In order to maintain continuity and the ability to upgrade the
>> application, certain pieces of state, namely local storage / indexed db /
>> cookies may be shared among all applications signed with the same key, so
>> that getting the latest version of the app that fixes a bug or adds a
>> feature in an E2E messaging product doesn't mean you lose your identity and
>> all previous messages.
>>
>> When encountering a new bootstrap HTML hash, the user would be given the
>> option to choose whether to trust and execute it if previous state exists
>> for that signing key.  User experience TBD, but this is the point at which a
>> transparency proof and gossip about partitioning could be checked, if
>> desired.
>>
>> -Brad
>>
>>
>>
>> On Tue, Apr 25, 2017 at 9:24 AM Daniel Huigens <d.huigens@gmail.com>
>> wrote:
>>>
>>> Hi Jeffrey,
>>>
>>> We're not trying to put the contents of web applications in the log.
>>> We're trying to put *hashes* of the contents of web applications in the log.
>>> Those are much smaller.
>>>
>>> Also, keep in mind that web applications themselves are also incentivized
>>> to keep certificates small, since large certificates mean longer load times.
>>> So if they have a web application with a thousand files, they might opt to
>>> use HCS for just 1 of them (the root html file) and SRI for everything else.
>>>
>>> Finally, here's a summary of all logged certificates last week [1]. Let's
>>> Encrypt alone has issued over 4 million certificates this week. Even if a
>>> few hundred web applications start requesting a certificate every hour
>>> because of HCS (which Let's Encrypt does not allow, but some CA's do),
>>> that's a drop in the bucket.
>>>
>>> -- Daniel Huigens
>>>
>>> [1]: https://crt.sh/?cablint=1+week
>>>
>>> Op 25 apr. 2017 16:53 schreef "Jeffrey Yasskin" <jyasskin@google.com>:
>>>
>>> The goal of binary transparency for web applications makes sense, but
>>> implementing it on top of the Certificate Transparency logs seems like it
>>> introduces too many problems to be workable.
>>>
>>> Have you looked into a dedicated transparency log for applications, using
>>> the system in https://github.com/google/trillian#readme? Then we'd need to
>>> establish that only files logged to a particular set of log servers could be
>>> loaded. A certificate extension might be the right way to do that, since the
>>> certificate would only need to be re-issued in order to add log servers, not
>>> to change the contents of the site.
>>>
>>> Putting every Javascript resource from a large application into the log
>>> also might introduce too much overhead. We're working on a packaging format
>>> at https://github.com/dimich-g/webpackage/, which could reduce the number of
>>> files that need to be logged by a couple orders of magnitude.
>>>
>>> Jeffrey
>>>
>>>
>>> On Mon, Apr 24, 2017 at 3:25 AM, Daniel Huigens <d.huigens@gmail.com>
>>> wrote:
>>>>
>>>> Hi webappsec,
>>>>
>>>> A long while ago, there was some talk on public-webappsec and public-
>>>> web-security about verified javascript [2]. Basically, the idea was to
>>>> have a Certificate Transparency-like mechanism for javascript code, to
>>>> verify that everyone is running the same and intended code, and to give
>>>> the public a mechanism to monitor the code that a web app is sending
>>>> out.
>>>>
>>>> We (Airborn OS) had the same idea a while ago, and thought it would be a
>>>> good idea to piggy-back on CertTrans. Mozilla has recently also done
>>>> that for their Firefox builds, by generating a certificate for a domain
>>>> name with a hash in it [3]. For the web, where there already is a
>>>> certificate, it seems more straight-forward to include a certificate
>>>> extension with the needed hashes in the certificate. Of course, we would
>>>> need some cooperation of a Certificate Authority for that (in some
>>>> cases, that cooperation might be as simple, technically speaking, as
>>>> adding an extension ID to a whitelist, but not always).
>>>>
>>>> So, I wrote a draft specification to include hashes of expected response
>>>> bodies to requests to specific paths in the certificate (e.g. /,
>>>> /index.js, /index.css), and a Firefox XUL extension to support checking
>>>> the hashes (and we also included some hardcoded hashes to get us
>>>> started). However, as you probably know, XUL extensions are now being
>>>> phased out, so I would like to finally get something like this into a
>>>> spec, and then start convincing browsers, CA's, and web apps to support
>>>> it. However, I'm not really sure what the process for creating a
>>>> specification is, and I'm also not experienced at writing specs.
>>>>
>>>> Anyway, please have a look at the first draft [1]. There's also some
>>>> more information there about what/why/how. All feedback welcome. The
>>>> working name is "HTTPS Content Signing", but it may make more sense to
>>>> name it something analogous to Subresource Integrity... HTTPS Resource
>>>> Integrity? Although that could also cause confusion.
>>>>
>>>> -- Daniel Huigens
>>>>
>>>>
>>>> [1]: https://github.com/twiss/hcs
>>>> [2]:
>>>> https://lists.w3.org/Archives/Public/public-web-security/2014Sep/0006.html
>>>> [3]: https://wiki.mozilla.org/Security/Binary_Transparency
>>>>
>>>
>

Received on Wednesday, 26 April 2017 01:39:49 UTC