Add an easier way to add configuration from a website

[tasn]

At the moment we ask users to manually add the pattern and the publickey. It'd be much better to just let them paste a link to a json config file which we'll print the sha256sum of, so users can be sure its what they expect.

This will be better for the users without compromising security.

[rugk]

Ugh, what?

So they should add a link to some random JSON on a server. The extension would download it and then just import the settings?
Note that this is:

1. TOFU – trust on first use. An attacker could modify the JSON.
2. Should require seem basic security, i.e. HTTPS.
3. May be better tied to the domain exactly, i.e. to import a config for example.com a JSON has to be placed at https://example.com/signed-page.json.

So the add-on could then even automatically look for that file, or you could introduce another meta tag, so it does not need to try to fetch non-existent resources. It could then offer to automatically import the data, but it should not offer overwriting the config if visited later. That would be TOFU, at least.

[tasn]

Sorry, it wasn't obvious from my original description because I wrote the task for myself.
The idea was that the extension will start showing the fingerprints (or other easy to compare hash) of configurations. This way a user could add a configuration, even from an untrusted source over http, and verify the authenticity through a secure channel. The users will need to copy the configuration from somewhere at some point. So I just wanted to make it easier, so you only open a file, and compare a short signature, rather than having to compare the much longer public keys and site configs.

I alluded in #5, that I plan on improving the format. One of the things I wanted is to maybe include the recommended default config, so a user can easily do TOFU (TOFU is not optimal, but not horrible either) and then compare the hash manually against a secure/alternative source to make sure it hasn't been tampered with.

Think for example: adding a config with one click upon entering a website, and comparing the hash against a printed pamphlet, github, twitter, irc or any other source or combinations of sources.

I'd rather not have an hardcoded path that is automatically searched because I want to be able to have different sources for the same domain. So for example:
https://www.myblog.com/~tasn/ and everything below could be signed with my key, and ~rugk/ and below could be signed with yours.

A meta tag, like you suggested, is much preferable, and I plan on essentially doing the same as part of the PGP comment format.

[rugk]

Okay, you only have one big problem here: The user. It's hard to get users to compare some random hash, and even harder for a user to let them check whether the source for the hash is valid.

That's why I'd say you need to automate as much as possible. You should blame the user then, you should find technical solutions, which are secure. That's why I still advise:

• to not allow one to import data for a domain from a different domain
• require HTTPS, just as browser vendors do for many other new features even when they are not security-related; that's just basic security

The same problem is there when you print file hashes next to your download button on a website. How many users would really care to check these? Yeah, too few.

[tasn]

Okay, you only have one big problem here: The user. It's hard to get users to compare some random hash, and even harder for a user to let them check whether the source for the hash is valid.

Even harder than that is to copy and paste a few configuration fields. I'm trying to make this easier. The suggestion above is already significantly better than this, and checking the fingerprint is an essential part of that. Even if the users are adding the configuration manually, they'd need to compare the key somehow, a fingerprint makes that easier. So at worst, it's already much better than now.

Cross-domain addition: I can see the value there, but it'd be much easier to have a popup saying: "the site is about to add a configuration for www.example.com, are you sure you want to accept it?".
HTTPS: yes, it's useful, prevents MITM on the way, and I encourage developers (not users, it's up to the devs) to use it, but given the threat model here, it doesn't help anyway. Users should verify the fingerprint.
So yes, I want https, but I don't think it's my responsibility to force it. It'd just clash with development environments and other setups where http makes sense. Following this line of thinking, I should also enforce CSP, and a million of other things I think are important, but I don't, because it's out of scope.

The same problem is there when you print file hashes next to your download button on a website. How many users would really care to check these? Yeah, too few.

I assume you meant signatures (not hashes), and yeah, probably very few. Though I don't see how this relates to the topic at hand, because what I'm suggesting will make Signed Pages easier to use, not harder.

[rugk]

Cross-domain addition: I can see the value there, but it'd be much easier to have a popup saying

Okay, if it is obvious enough, that's also possible. Maybe just make the cross-domain addition look a bit "scarier", so one notices the difference.

Your point is:

Users should verify the fingerprint.

My point is: You cannot force them to do so. And many, won't.
This is a big problem considering UX, security by default and things like that.

HTTP does not make sense. In any modern browser you are never going to have any proper website with HTTP. So a even (as for HTTPS) loosely security-related extension like your's should follow the same path.

Following this line of thinking, I should also enforce CSP, and a million of other things I think are important, but I don't, because it's out of scope.

It's not. CSP is a security enhancement. HTTP is no security at all, i.e. HTTPS is basic security.
Again, remember that browser vendors nowadays force websites to use HTTPS. The big plan is to depreciate HTTP altogether, because it is just insecure.

I'm suggesting will make Signed Pages easier to use, not harder.

Sure, just don't trade convenience for security. And as I said, you can make it in an easy way.

So to conclude: You can easily strengthen the security for all users, even if they fail to do manual verification. And you should do so.

[tasn]

Okay, if it is obvious enough, that's also possible. Maybe just make the cross-domain addition look a bit "scarier", so one notices the difference.

Yeah, I agree.

Your point is:

Users should verify the fingerprint.

My point is: You cannot force them to do so. And many, won't.
This is a big problem considering UX, security by default and things like that.

They should verify the fingerprint even before this change, so I don't see how this change makes it worse. It only makes it better.

HTTP does not make sense. In any modern browser you are never going to have any proper website with HTTP. So a even (as for HTTPS) loosely security-related extension like your's should follow the same path.

If the browsers are going to do it, the extension be following this path by the nature of them doing it because it lives in the browser. While I'm at it, should this extension also block HTTPS if the the server is using SSLv2?
This is the same line of thinking, and it's not part of what this extension does. I don't see how it'll help, I only see how it'll possibly hurt in cases where I haven't considered yet, or with website devs testing their installations locally.

Following this line of thinking, I should also enforce CSP, and a million of other things I think are important, but I don't, because it's out of scope.

It's not. CSP is a security enhancement. HTTP is no security at all, i.e. HTTPS is basic security.
Again, remember that browser vendors nowadays force websites to use HTTPS. The big plan is to depreciate HTTP altogether, because it is just insecure.

Again, following the same logic, HTTPS with insecure crypto is also not security, TLSv1.2 is basic security. HTTP will get deprecated in this extension when it's done with the browsers.

I understand where you are coming from, and it's tempting to fix more issues with this extension, I'm also tempted! But I really don't think it's in scope.

Anyhow, there's still time. I'm not implementing it just yet, and even after I do, enforcing HTTPS is an easy addition. Furthermore, I could make it an on-by-default option, and let users (e.g. devs) turn it off from the settings. Or again, show a big fat warning.

I'm suggesting will make Signed Pages easier to use, not harder.

Sure, just don't trade convenience for security. And as I said, you can make it in an easy way.

So to conclude: You can easily strengthen the security for all users, even if they fail to do manual verification. And you should do so.

I agree.

[rugk]

Hmm, okay, so you purely rely on the browsers... Well... okay, let's wait until it is implemented.

[steamraven]

With the new format, I was going to take a stab at Trust on First Use

For security reasons, I think the pattern should be very restricted, be derived from the current page, and the current page should list its own address (or addresses if there are aliases) in the meta tag.

Rules

• The page must be an index page (url end with a slash)
• The pattern will be the current index page and all pages under it
• It will not include more subdomains or less subdomains
• It will Https
• Pattern will be supplied in the webpage

served from: https://subdomain.example.com/steamraven/
pattern: https://subdomain.example.com/steamraven/*
Non-acceptbale pages

• https://example.com/steamraven/
• https://sub.subdomain.example.com/
• https://subdomain.example.com/
• https://another.example.com/steamraven/
• http://subdomain.example.com/steamraven/

This is highly restrictive, but I think more secure. We cannot allow parents in the domain or the path as we may not be the authority of those domains. Although we may be authority over all additional subdomains, granting access to all of them could be an easily overlooked security risk.

Allowing only index pages makes the logic a lot simpler.

While I agree that https may be out of the scope of this extension, it is a simple requirement that grants a good amount of security. We can have a developer option to turn off in the settings page.

[rugk]

Yep, you possibly also need to account for things like ….github.io. Obviously the signature may not be valid to other GitHub Pages sites, and one should only import it for one only…

it is a simple requirement that grants a good amount of security.

And it's also easier top just hardcode it… 😉

[tasn]

I was thinking having a special file with the config, e.g. "/.well-known/signed-pages.json" or "/signed-pages.json". Though I guess just deriving it from the current file should be enough. Though I would change one thing, instead of restricting it to index files, just derive a different pattern from files.

E.g:

https://www.example.com/tasn/ -> https://www.example.com/tasn/*
https://www.example.com/tasn/file.html -> https://www.example.com/tasn/file.html

In each case, you should show the derived pattern in the UI before adding the rule, and maybe a word about how it's derived, and if it's not inclusive enough, they should change the pattern. I'm specifically thinking about cases where:
https://www.example.com/ is all controlled by the same signed, but we just happen to be viewing https://www.example.com/about/

[rugk]

I think that can be derived from the place, where the file is being saved, i.e. example.com/.signed-pages.json would apply to example.com/all_subdirs and example.com/onlysubdir/.signed-pages.json would only allow example.com/onlysubdir/….

[tasn]

Yeah, that's for the case when you have this file. Though I think I like, at least for now, the suggestion that it's embedded in the file itself. It's simpler, and there's no need for a separate file for now.
Just have a meta tag that includes the public key, or heck, even use the same meta tag, and just add data-pubkey. Needs some more thinking, and better to do it closer to when it'll actually be implemented. I'd also love to hear what @steamraven has to say.

[RokeJulianLockhart]

I think that this problem is ultimately what prevents adoption, despite this extension being such a simple solution to such a prevalent problem.

Consider how many websites oneself visits each day. I believe that trusting on first use is somewhat necessary to browse the internet. If the certificate is somehow automatically added during that first visit, it allows users to gain the certificates necessary without spending half of their lives manually adding and verifying them.

However, isn't a better option something like a public keystore, but merely one that contains an associated URI and/or domain for each key?