Re: Security bounties on Web bugs

On Sun, Feb 22, 2015 at 4:39 AM, Ekaterina Gerasimova 
<[email protected]> 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

_______________________________________________
epiphany-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/epiphany-list