Re: Security bounties on Web bugs

[Michael Catanzaro <mcatanzaro igalia com>]

On Sun, Feb 22, 2015 at 4:39 AM, Ekaterina Gerasimova <kittykat3756 gmail com> wrote:

There are two issues with this: firstly epiphany would depend on seahorse

Epiphany isn't meant to be used outside of GNOME, and Seahorse is an uninstallable core GNOME app, so I don't think this is any issue at all. This is actually part of our manifesto:

Epiphany's main goal is to be integrated with the GNOME desktop.
We dont aim to make epiphany usable outside GNOME. If someone will like
to use it anyway, it's just a plus. Ex: Making people happy that
don't have control center installed is not a good reason
to have mime configuration in epiphany itself.

Epiphany is just not the right place for system-level configuration like certificate management.

and the second is that seahorse needs a lot more love than it's been getting for a while.

Yes, that is true. The whole app could definitely stand to be rewritten. That would be a good use of GNOME funds, since it's the sort of thing that's not likely to happen on its own, and it would not be a small task. You should really consider spending on Seahorse, if not with privacy campaign funds then as the subject of the next fundraiser.

I'm not sure how possible it is, but if seahorse is used, it would still be best if the certificates could be added without leaving epiphany.

OK, so we are talking about broken web sites. I was content to leave these be, since we've gotten to the point where these sites are very likely to be broken in other browsers as well and I don't care if we discourage users from visiting them, but we could handle them a bit better, yes. Anyway, there are three theories on this. The first is "when visiting an untrusted site, do not allow the user to trust the certificate because he will screw up his trust store and be vulnerable forever." That's the approach taken by basically all browsers, including Epiphany, with the notable exception of Firefox. These browsers let the user proceed anyway, then the next time he visits the site he's up against the same certificate warning again. I guess that's what you don't like, right? Anyway, Firefox follows the second theory: "when visiting an untrusted site, do not allow the user to proceed without modifying his trust store because he will just click through the warnings unless there are permanent security consequences to his decision." In practice, the Firefox approach significantly reduces the clickthrough rate, which is the primary reason this strategy is worth considering, but it's obviously bad for the people who proceed anyway (unless they are doing key pinning instead, which might be the case but isn't clear from their UI). The third approach would be to treat the untrusted certificate as a transport error and provide no way to proceed. Unfortunately it's not really politically possible for us to do this unless Firefox does so first, since we would lose users to Firefox, but it's far and away the right thing to do.

Anyway, I guess you want us to switch from the first approach to the second approach, so back to that. Remember that Firefox has its own private trust store. That is explicitly out of scope for Epiphany; we use the system trust store in /etc/ssl. To be able to modify your system trust store, you're going to need to write a polkit helper and prompt the user for an admin password if he's not in the admin group. So then unprivileged users will be completely stuck. On the other hand, p11-kit and glib-networking could be upgraded to check the home directory for certificates in addition to /etc, but I'm not sure if it would be advisable. There's also the huge disadvantage that this would allow a rogue site to backdoor all of the user's connections on other sites, so I'm pretty firmly convinced we should not adopt this approach. So we should really avoid modifying the system trust at all, but we COULD add an application-specific pin instead. i.e. implement a key pinning backend in WebKit (that can also be used by HPKP or TACK!), then Epiphany could pin a certificate for the given site without changing the system trust in any way. We would need then need UI to expose and modify which certificates are pinned to each site.

If we use privacy campaign funds for this, I would probably use all of the funds on this and lump it in with HPKP since it's so closely-related: set aside most of the funds for an implementation of HPKP in the soup backend of WebKit and API to expose this in WebKitGTK+, since HPKP has much more complex requirements for how pinning should work and it would suck to do this in a way that can't be reused by HPKP, and wouldn't it be nice to tie a project Michael is ambivalent about to a major security feature he'd like to see. Then a smaller amount of the funds would be a bonus for UI in Epiphany to view and modify the list of pins, and of course a similar amount for UI to allow users to use a pin to skip the untrusted certificate interstitial. The UI should strongly discourage users from adding such a pin, like Firefox does. And we would need to think about how much of HSTS we should expose in the list of pins: I'm pretty sure we need to be able to display pins so that the user can delete them when sites accidentally DoS themselves with a pin, but HPKP has various types of pins and how and how much to expose would be an interesting question for our designers.

This way we're not just throwing money at making Epiphany work with broken sites, we'd also be the first major browser with HPKP, which will be a huge security improvement for [the few] sites that use it.

/brainstorming

Michael