Title: Web distribution signing
Headline: Bringing trust back between software authors and user agents.

*I'm not a crypto expert, nor pretend to be one. These are thoughts I
want to share with the crypto community to actually see if any solution
exists to solve this particular problem.*

One [often pointed](http://www.tonyarcieri.com/whats-wrong-with-webcrypto) flaw in
web-based cryptographic applications is the fact that there is no way to
trust online software distributions. Put differently, you don't actually
trust the software authors but are rather trusting the software
distributors and certificate authorities (CAs).

I've been talking with a few folks in the past months about that and
they suggested me to publish something to discuss the matter. So here I
come!

## The problem (Attack vectors)

Let's try to describe a few potential attacks:

*Application Authors* just released a new version of their open source
web crypto messaging application. An *Indie Hoster* installs it on their
servers so a wide audience can actually use it.

Someone alters the files on *Indie Hoster* servers, effectively
replacing them with other *altered files* with less security properties
/ a backdoor. This someone could either be an *Evil Attacker* which
found its way trough, the *Indie Hoster* or a CDN which delivers the
files,

Trusted *Certificate Authorities* ("governments" or "hacking team") can
also trick the User Agents (i.e. Firefox) into thinking they're talking
to *Indie Hoster* even though they're actually talking to a different
server.

**Altered files** are then being served to the User Agents, and *Evil
Attacker* now has a way to actually attack the end users.

## Problem Mitigation

Part of the problem is solved by the recently introduced [Sub Resource
Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/)
(SRI). To quote them: "\[it\] defines a mechanism by which user agents
may verify that a fetched resource has been delivered without unexpected
manipulation.".

SRI is a good start, but isn't enough: it ensures the assets (JavaScript
files, mainly) loaded from a specific HTML page are the ones the author
of the HTML page intends. However, SRI doesn't allow the User Agent to
ensure the HTML page is the one he wants.

In other words, we miss a way to create trust between *Application
Authors* and *User Agents*. The User-Agent currently has to trust the
*Certificate Authorities* and the delivery (*Indie Hoster*).

For desktop software distribution: *Crypto Experts* audit the software,
sign it somehow and then this signature can be checked locally during
installation or runtime. It's not automated, but at least it's possible.

For web applications, we don't have such a mechanism, but it should be
possible. Consider the following:

  - *App Authors* publish a new version of their software; They provide
    a hash of each of their distributed files (including the HTML
    files);
  - *Crypto Experts* audit these files and sign the hashes somehow;
  - *User Agents* can chose to trust some specific *Crypto Experts*;
  - When a *User Agent* downloads files, it checks if they're signed by
    a trusted party.

## Chosing who you trust

In terms of user experience, handling certificates is hard, and that's
where the community matters. Distributions such as
[Tails](https://tails.boom.org) could chose who they trust to verify the
files, and issue warnings / refuse to run the application in case files
aren't verified.

But, as highligted earlier, CAs are hard to trust. A new instance of the
same CA system wouldn't make that much differences, expect the fact that
distributions could ship with a set of trusted authorities (for which
revocation would still need to be taken care of).

> \[...\] users are vulnerable to MitM attacks by the authority, which
> can vouch for, or be coerced to vouch for, false keys. This weakness
> has been highlighted by recent CA scandals. Both schemes can also be
> attacked if the authority does not verify keys before vouching for
> them.
> 
> \-- [SoK : Secure
> Messaging](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf);

It seems that some other systems could allow for something more
reliable:

> Melara et al proposed CONIKS, using a series of chained commitments to
> Merkle prefix trees to build a key directory \[...\] for which
> individual users can efficiently verify the consistency of their own
> entry in the directory without relying on a third party.
> 
> This “self- auditing log” approach makes the system partially have no
> auditing required (as general auditing of non-equivocation is still
> required) and also enables the system to be privacy preserving as the
> entries in the directory need not be made public. This comes at a mild
> bandwidth cost not reflected in our table, estimated to be about 10
> kilobytes per client per day for self-auditing.
> 
> \-- [SoK : Secure
> Messaging](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf);

Now, I honestly have no idea if this thing solves the whole problem, and
I'm pretty sure this design has many security problems attached to it.

However, that's a problem I would really like to see solved one day, so
here the start of the discussion, don't hesitate to [get in
touch](/pages/about.html)\!

## Addendum

It seems possible to increase the level a user has in a Web Application
by adding indicators in the User-Agent. For instance, when using an
application that's actually signed by someone considered trustful by the
User-Agent (or the distributor of the User-Agent), a little green icon
could be presented to the User, so they know that they can be confident
about this.

A bit like User-Agents do for SSL, but for the actual signature of the
files being viewed.
