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.)