Re: Verified Javascript: Proposal

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
>>
>>
>