Signed pages

[rugk]

Maybe you could consider adding support for this signed pages browser add-on.

The idea is simple:

• Devs sign the page with PGP and use subresource Integrity (SRI) in order to assure all resources loaded from that site are valid. (thus indirectly also signed)
• Browser extension verifies this.

That can protect against the "server trust" problem you still have with Threema Web – actually, with every web application. (as discussed in #52) At least it would protect against a server compromise, not against you (dev/Threema) acting evil, of course. So it's a bit limited threat model here, but it is certainly better than without that verification.

And BTW as another advantage, it would also allow anybody to verify third-party self-hosted instances of Threema Web.

[dbrgn]

Generally this looks interesting. But how does key management work? It seems that the public keys are simply bundled with the extension... https://github.com/tasn/webext-signed-pages/blob/master/src/default-items.js That does not sound like a scaleable solution. Furthermore, how would they prevent an attacker from simply sending a pull request that replaces the public key, claiming to work at that company?

[rugk]

I think their plan is to make it user-configurable , so that users can add their stuff by themselves and only need to verify a fingerprint (see tasn/webext-signed-pages#1).

[rugk]

As for the other question, I've opened an issue (tasn/webext-signed-pages#9).

[tasn]

It's already user configurable (check out the options page). The preloaded list of keys that you see there was added in the last two weeks to just make it easier for users to have working configs out of the box.

As for who gets added to the preloaded list: that's a good question. I haven't had to deal with such a case just yet, as the extension is quite new (though following my FOSDEM talk, there have been a few discussions in projects). This process should be decided and documented, and thanks to @rugk there's now tasn/webext-signed-pages#9 which will be used to track this effort. Please add any suggestions there.
It's important to note though, that due to the delay between accepting a PR and releasing a version of the extension, there should be enough time to properly verify public keys are non malicious and come from a trusted source.

As for a more general roadmap: I want the extension to be able to verify a PGP key against e.g. keybase, or maybe PGP keyservers to help verification to when users add their own keys, to reduce the usefulness of preloaded servers.

[rugk]

there should be enough time to properly verify public keys are non malicious and come from a trusted source.

Or, the reverse: Enough time for the company to find out their server was compromised/one added a PGP key to the addon, so they can still complain and delete that issue.

[tasn]

Yeah, that too!

[lgrahl]

Apparently, the proposed solution is limited to just the HTML page for Chromium based browsers and we load all the important bits from external scripts.

It is definitely a nice feature and I don't want to be disrespectful... but this is something I'd prefer to be resolved by a standardised effort and then implemented from browser vendors. Once that exists, we'll certainly jump on it.

@dbrgn if you agree with me, we can close this issue.

[tasn]

This extension is a WebExtension which works in every browser that supports it (Chrome, Firefox, Edge, Opera? and more), so it's not limited to just Chromium.

As for the limited to just HTML: it's not the case. Yes, the extension only verifies the HTML but that's because browsers already support verifying external resources (such as scripts) using SRI (subresource integrity). This means that if the HTML file uses SRI to verify all of the scripts it uses, and the extension verifies the HTML, you essentially have a tree of trust and the page in its entirety can be trusted.

As for waiting on browser vendors: that's up to you to decide, but I see things a little differently. It's our responsibility as developers of secure software to push for what we need to help our users stay safe rather than wait for some committee somewhere to prioritise it. Thanks to the extension we have the ability to offer this to users now and when it becomes a de facto standard have the browsers follow suit.

Disclaimer: I wrote it.

[lgrahl]

Thanks for the clarification. In that case, it seems a lot more feasible. (TIL: SRI is a thing.)

[tasn]

SRI is great! :)

I believe it was originally meant for use with CDNs and in general serving resources from 3rd parties (this way you can make sure the file is what you think it is), but the extension piggy backs on this mechanism to build a tree of trust.

[rugk]

BTW, actually Firefox has even "better" support for it, as they have a proper API for getting the plain-content as it (without required minification). See tasn/webext-signed-pages#16 for details.

[dbrgn]

It's definitely an interesting idea, but so far the Firefox addon seems to have 75 users and the Chrome plugin seems to have 48 users. Yeah, I know, chicken-and-egg-problem, but for this to be useful we can't just add a signature and be done with it, we'd first have to invest some time to set up SRI on all our local resources, for which we don't currently have a workflow. (Is there a tool that parses the HTML and adds hashes for all resources?)

Also, how does the plugin currently ensure that the output of the minifier stays stable over time? Does the signature contain the version of the minifier used to generate the canonical output?

[tasn]

I find the number of downloads quite impressive given that it's only used by EteSync at the moment and most people don't use the EteSync web client... Yes though, it's a chicken-and-egg thing.

There's a webpack plugin for SRI for all I know, though you can even do something as simple as:
sed -i "s#\(<script type=\"text/javascript\"\)#\1 integrity=\"sha384-$(shasum -b -a 384 build/static/js/main.*.js | xxd -r -p | base64 -w0)\" crossorigin=\"anonymous\"#" build/index.html
if you only have one main javascript file, or a bit differently if you have a few.

Output of the minifier stay the same: we fixed the minifier version and don't plan on changing that unless we must (because of security issues), and once we do that we'll start versioning. Though I hope to avoid that if possible. Hopefully Chrome will implement its missing APIs (like Firefox has) so we won't need any minification soon enough.