Web crypto distribution signing - update article.

content/crypto/webcrypto-distribution-signing.rst

@@ -2,9 +2,8 @@ Web distribution signing
 ########################
 
 :lang: en
-:date: 2015-06-29
+:date: 2015-10-12
 :headline: Bringing trust back between software authors and user agents.
-:status: draft
 
 .. note:: 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
@@ -16,58 +15,65 @@ 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 Richard Barnes last week about that and he suggested
-I publish something to actually discuss this further, so here it is!
+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!
 
-Attack vectors
-==============
+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. *Indie Hoster* installs it on their servers so
-that a wide audience can actually use it.
+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
-*Evil Attacker* or *Indie Hoster* which can already alter these files because
-they're distributing them.
+an *Evil Attacker* which found its way trough, the *Indie Hoster* or a CDN
+which delivers the files,
 
-Trusted *Certificate Authorities* (read "governments") can also trick to
-User Agents (i.e. Firefox) into thinking they're talking to *Indie Hoster* even
-if they're actually talking to a different party.
+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 being served to the User Agents, and *Evil Attacker* now
-has a way to actually attack the end users.
+**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
 ==================
 
-I hope it's clear by now that we miss a way to create trust between
-*Application Authors* and *User Agents*. The User-Agent has to trust
-*Certificate Authorities* and *Indie Hoster*.
+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.".
 
-I believe this specific problem had been solved, at least partially, for
-desktop software distribution: *Crypto Experts* audit the software, sign it
+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.
+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;
-- *Crypto Experts* audit these files and sign the hashes with their private
-  key;
-- *User Agents* have a way to add the certificate for *Crypto Experts*;
-- When a *User Agent* downloads files, it checks if they're signed.
+  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
 =====================
 
-.. note:: And now is the time I start talking about things I don't know. But
-          maybe you trust me?
-
 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
@@ -105,7 +111,9 @@ It seems that some other systems could allow for something more reliable:
 
   -- `SoK : Secure Messaging <http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf>`_;
 
-Now, I honestly have no idea if this thing is practicable, and I'm pretty sure
-this design has many security problems attached to it. But 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>`_!
+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>`_!

pelicanyan/templates/article.html

@@ -23,6 +23,9 @@
     <h1 class="post-title">
       {{ article.title }}
     </h1>
+    {% if article.headline %}
+    <h2 class="post-title">{{ article.headline }}</h2>
+    {% endif %}
     <span class="post-date">{{ article.locale_date | capitalize }}</span>
 
     {{ article.content }}