From 1d647a6e4e52bb3311e7316a2694bdfe96c50001 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexis=20M=C3=A9taireau?= Date: Mon, 12 Oct 2015 19:57:14 +0200 Subject: [PATCH] Web crypto distribution signing - update article. --- .../crypto/webcrypto-distribution-signing.rst | 74 ++++++++++--------- pelicanyan/templates/article.html | 3 + 2 files changed, 44 insertions(+), 33 deletions(-) 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 }}