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
