diff --git a/content/crypto/webcrypto-distribution-signing.rst b/content/crypto/webcrypto-distribution-signing.rst
index 076e1e6..98e99a9 100644
--- a/content/crypto/webcrypto-distribution-signing.rst
+++ b/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 `_
+(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 `_
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 `_;
-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 `_!
+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
+`_!
diff --git a/pelicanyan/templates/article.html b/pelicanyan/templates/article.html
index 8dc061b..4cceb1d 100644
--- a/pelicanyan/templates/article.html
+++ b/pelicanyan/templates/article.html
@@ -23,6 +23,9 @@
{{ article.title }}
+ {% if article.headline %}
+ {{ article.headline }}
+ {% endif %}
{{ article.locale_date | capitalize }}
{{ article.content }}