W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2017

Verified Javascript: Proposal

From: Daniel Huigens <d.huigens@gmail.com>
Date: Mon, 24 Apr 2017 12:25:01 +0200
Message-ID: <CAL14OeEy+=9FqBMqfEesK5CUHLJf8fs51ib6FJ_tokjUiogrig@mail.gmail.com>
To: public-webappsec@w3.org
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

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 Monday, 24 April 2017 10:25:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:00 UTC