Re: Security bounties on Web bugs

[Michael Catanzaro <mcatanzaro igalia com>]

On Sat, Feb 21, 2015 at 3:16 PM, Ekaterina Gerasimova <kittykat3756 gmail com> wrote:

Hello maintainers, and everyone else too,

Hi Kat!

Good to see you're considering a chunk of the funds for Epiphany.

Hubert, Federico, Spider and I have been working on finding suitable issues for the Privacy Campaign[1] funds and we came up with two issues in Web which fall under the privacy domain. The first of the two is to have HTTPS-everywhere by default (see the EFF plugin for Firefox for an idea[2]). Optionally, it could also refuse mixed-page content (https site loading http content) with an overwritable warning or similar. We would like to propose a bounty of USD 500.00 for full implementation and merging of the feature. So our questions are: is this something which you would be willing to accept in Web? Do you consider the bounty to be suitable based on the difficulty of the issue?

Mixed content blocking is really a completely separate issue. I've already implemented blocking for the most significant types of content at [1]; the patches are just languishing in review queue now. So let's remove that from consideration here. (I guess an HTTPS Everywhere plugin could attempt to automatically convert certain mixed content URIs into HTTPS URIs, though.)

Now, regarding HTTPS Everywhere. I would really hesitant to enable this by default. The problem is that, by definition, HTTPS Everywhere only affects web sites that do not expect you to visit via HTTPS, which I would expect to dramatically increase the chance of certificate validation failure, blocked mixed content, and general breakage. How big an issue this is depends on EFF's maintenance of the list. If someone who uses HTTPS Everywhere on a daily basis could chime in regarding the severity of compatibility issues? If breakage is fairly rare, then it might make sense.

It would work well as an option on the privacy page in preferences, for sure. $500 is probably a reasonable bounty for this issue, since it's really just a matter of checking URIs against a whitelist. The other thing we should consider before posting a bounty is that the EFF might be willing to fund this itself.

The second is the addition of certificate management and TLS issues (bug 721283). We would like to propose a bounty of USD ~2500 split into a few parts based on discrete tasks. Some ideas for the breakdown are:

* Untrusted certificate (self-signed or untrusted issuer: https://ca.modio.se/)

I'm actually not really sure what this bullet point is proposing! We already have an interstitial to protect the user against these sites, with improvements for 3.18 in [2]. If the goal is to allow such sites like we did prior to 3.14, no thank you.

* Certificate changed / authority changed between visits

Mmmm... the thing is, this is perfectly normal. We don't want to bother the user with a confusing warning just because a web site got a new cert. Is that what this bullet is proposing? I heard some thoughts about trust-on-first-use for web browsers, but I remain to be convinced that would not be a terrible idea. :)

An implementation of HPKP would help here, but that standard is still evolving, so it might not be a good use of funds at this point. At the same time, this is extremely important to guard against Iran reading your gmail, and it's a shame our users have no protection against this right now.

* Import client certificate

Yes, this would definitely be good. The plumbing landed in libsoup last year; we just need it hooked up in WebKitGTK+ now for it to be used by Epiphany. That is [3]. Now, this only matters for *very* few sites and 99% of users will never notice, but we're 10 years behind other browsers here and I think that justifies spending on it at this point, since I expect it would be fairly easy to implement.

* Certificate overview / details about trust

* Good error messages and dialogues

* Inspect or export certificate

I think think could all be lumped under improving EphyCertificateDialog, the thing you see when you click the View Certificate button in the security popover. It only shows one certificate rather than the entire chain, with only a vague explanation of what's wrong, and there's no way to export the certificate. Now, I think it's very important that this dialog is the only place where any technical details are presented. Users should never encounter any UI that hints at the existence of certificates during the course of normal browsing (unless a site asks for a client certificate), since nobody knows what certificates are or how to handle prompts regarding certificates. Our main UI should be as simple as "site is secure," "site is kind of secure," "site is insecure." But EphyCertificateDialog is something you have to go out of your way to look for, so we can put stuff for advanced users there.

Now, this isn't really an issue I would prioritize, but that probably makes it a better target for the campaign because it's something I'll never get around to doing on my own. This will require work in several dependencies to get the chain of trust up to epiphany and to provide more details about certificate failure, so it should be a larger bounty. See also [4] for related UI considerations.

Spider would be happy to be the contact for usefulness assessment of the dialogs/UI changes as this is an area in which he is very knowledgeable. As before, the questions to the Web maintainers are whether this is something that you would accept? And is the suggested bounty sane given our assessment of the work involved?

I think we need further discussion on this so that we wind up with a more specific set of expectations, since the current list is rather vague. Let's identify areas of agreement and focus the funds on those. I guess everyone who worked on the list is already CCed?

One big oversight here is HSTS -- that is the most important missing feature right now, I think. That should be implemented in WebKitGTK+. I would suggest setting aside money for HSTS before we look at anything else.

I will throw out a few more ideas, since brainstorming never hurt anything:

* It would be nice to have API in GTlsConnection and libsoup to determine more details about the security of the connection, so that we can be much stricter about which sites qualify for a secure lock icon. We could use this to decide to use an insecure rather than secure lock icon for servers with certificates that use 1024-bit RSA or which have a SHA 1 signature, servers that use weak Diffie-Hellman parameters, servers missing the safe renegotiation extension, or servers that required protocol version fallback. And in the (distant) future, we can get even stricter, e.g. using the insecure lock for RSA key exchange (which has no forward secrecy), for example. There is no way to get any of this information up to libsoup at this point, let alone WebKitGTK+.

* It would be nice to perform certificate revocation checking. Not CRL, because that will make Epiphany seem slow (unusably slow for users with poor connections), and not OCSP, because that's a significant privacy concern. We should have a hardcoded list of revoked certificates (preferably identical to Google's) that glib-networking will download and check automatically.

* Similarly, it would be nice to have a hardcoded list of certificate pins for top sites (preferably identical to Google's). Probably Epiphany would be the right layer at which to download and check these automatically.

* It would be nice to display the owner of an EV certificate in the UI when visiting a site that presents an EV certificate. Low priority because users don't understand what EV certificates mean, but it could help an experienced user to notice when something is up.

The format of the bidding is that we will take care of all the administrative overheads, while the Web maintainers would need to review the code until it is complete and in a satisfactory state for merging/long term maintenance. This will need commitment from the maintainers to offer patch reviews in a timely manner (or even implement the features themselves).

Since I'm not a maintainer I can only commit to providing unofficial reviews (which I will be happy to do). Hopefully someone else will take this up.

Thanks everyone! I've been the only person working on Epiphany security features for a while now, and it will be nice to get more help.

Michael

[1] https://bugs.webkit.org/show_bug.cgi?id=140625

[2] https://bugzilla.gnome.org/show_bug.cgi?id=744063

[3] https://bugzilla.gnome.org/show_bug.cgi?id=618429

[4] https://bugzilla.gnome.org/show_bug.cgi?id=744064