epiphany-logo.png

GNOME Web

A simple, clean, beautiful view of the web


This page contains my thoughts regarding future security/privacy features for Epiphany. I have ordered this list based on what I personally think our priorities should be: roughly highest priority at the top, roughly lowest at the bottom. I give some hints on which dependencies will need work for each task. -- MichaelCatanzaro

HTTP Strict Transport Security (HSTS)

https://bugzilla.gnome.org/show_bug.cgi?id=628298

HTTPS is not very useful against an active network attacker who prevents you from ever being redirected to HTTPS pages. HSTS fixes that. It could be implemented in libsoup, but it would probably be best to do it entirely in WebKit because it's primarily useful for browsers and other apps that display web pages. (Other applications probably want to pin manually rather than use HSTS.) I don't think this needs work anywhere other than WebKit, so it's a fairly self-contained task. Note that the Mac port already has HSTS support; we may or may not need/want to share code with them.

An important point is that certificate verification failure is a transport error for any site that has opted in to HSTS: the user must not be allowed to click through and view the site.

Optional and desirable: an HSTS preload list, ideally identical to Google's or Mozilla's. This should live in a brand new package so that it can be updated independently of WebKit. https://hstspreload.appspot.com/ exists.

HTTPS Everywhere

Update: Mostly done, but experimental. Needs to be enabled by default.

Scarier Unacceptable Certificate Interstitial

Update: Done

Automatic Privacy Blocking

Update: Done

Certificate Verification Tests

Update: this is a lost cause. We should obviate the need for more tests by moving certificate verification fully down into GnuTLS.

Web Process Sandbox

Update: our previous attempt at a web process sandbox turned out to be unmaintainable. We should just use the Flatpak sandbox instead.

Certificate Revocation

https://bugzilla.gnome.org/show_bug.cgi?id=728141

We don't currently check for revoked certificates. The problem with certificate revocation is that standard methods for revocation checking are arguably worse than performing no revocation checking at all. CRL causes the browser to take an eternity to download a potentially 40 MB CRL before loading a web page: that's not acceptable. No browser hard enforces OCSP responder failure and there's little value in OCSP unless we do. Plus, OCSP is a big privacy violation, which dramatically outweighs the benefits of using it if it's not hard enforced. OCSP stapling exists, but it's not useful unless we enforce OCSP.

We should ship -- guess what -- a preload list of revoked certificates! It should be checked by glib-networking; this shouldn't need any work anywhere else. Guess what: it should be in a separate package, so it can be updated separately from glib-networking. Note that a revoked cert *anywhere* in the chain must invalidate the entire chain.

Update: Look into using OneCRL for intermediate certificate revocation. We might have to give up on checking for revocation of individual certificates, though, since every option sucks. :(

TLS Client Authentication

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

We're a decade behind other browsers here. Browsers always authenticate the server when performing a TLS connection, but servers can ask the browser to authenticate as well! When you visit https://koji.fedoraproject.org/koji/login in Epiphany we should display a certificate chooser so you can pick a certificate to authenticate with. (Never mind that the Koji server uses a self-signed cert currently; that is a misconfiguration we should fix.) The certificate should be remembered so the dialog doesn't appear the next time you visit the site. There needs to be a dialog to display remembered client certificates and "remove" or replace them. Probably the dialog should be in Preferences -> Privacy, since that is where we keep related things now, but it is not preference-related so this irks me. Work with the GNOME designers to get UI mockups. Consider also UI for certificate pinning (see below) when working with the designers on mockups.

This work will need to occur in the Soup backend of WebKit, in the WebKitGTK+ API layer, and in Epiphany. Carefully consider what new API to add to WebKit. There should probably be a default which applications can override only if desired. See how WebKit handles HTTP authentication with a default WebKitAuthenticationDialog that applications can suppress with their own dialog via a signal, for example. There will need to be new API to ask the browser for a client cert, and for the browser to associate or deassociate a client cert with a given site so that a "preferences" dialog can be created. Luckily, all the work in libsoup has already been done: just use the tls-interaction property of the SoupSession.

Future, lower-priority work: Other browsers are experimenting with allowing web sites to generate and store client certificates with Javascript, as an alternative to password and cookie authentication. Investigate what they're doing and decide whether to implement. This would need to be implemented primarily in cross-platform WebKit code, with cross-platform layout tests, with some work in the Soup backend of WebKit. Standard TLS client authentication, described above, must come first regardless.

Stop using G_TLS_GNUTLS_PRIORITY

https://bugzilla.gnome.org/show_bug.cgi?id=745637

Right now we have to set the G_TLS_GNUTLS_PRIORITY environment variable to control the GnuTLS priority string manually. Right now that looks like this: "NORMAL:%COMPAT:%LATEST_RECORD_VERSION:!VERS-SSL3.0". We do this separately in WebKit, Geary, gnome-initial-setup, and gnome-control-center for a stupid technical reason (setenv is not thread-safe) (edit: I just had the privilege of removing that code from g-i-s and g-c-c since we switched them to WebKit2, but we still shouldn't need to change the environment). This is crazy and unsustainable. Ideally glib-networking would just be secure for browsers by default (no SSLv3, no RC4, ...), but that's not likely to happen, so we need control of protocol versions, ciphers, and other aspects of the priority string through real API, not an environment variable. Requires new API in glib, glib-networking, and libsoup.

Consider that this would conflict with Fedora's new crypto policy, but using G_TLS_GNUTLS_PRIORITY already conflicts with that policy. We need to get that sorted out too. If it's not secure by default and cross-distro (it's not) we can't use it.

Use the Insecure Lock Icon More

We should take the insecure lock icon idea much further. Currently we, like other browsers, display that secure lock whenever you have an HTTPS connection and the certificate checks out. But there are plenty of checks we can run to see if the security of the connection sucks, e.g. if Diffie-Hellman primes are less than 2048 bits, if RSA key exchange was used (no forward secrecy), if a non-root cert has a SHA-1 signature, if any cert in the chain has an RSA 1024 key, if libsoup performed voluntary protocol version fallback, if the server didn't send the safe renegotiation extension, if we negotiated RC4.... If we implemented all of those checks, very few servers would get the secure lock, but we can start with a subset of them and add more over time.

But getting all that information up to Epiphany will not be easy. This needs new API in glib (implemented in glib-networking), libsoup, and WebKit. Tests would need to be written for glib-networking, libsoup, and WebKit. Really the only issue here is the number of layers involved, but we'll have to think carefully about API every step of the way. We also need to work with the design team to develop a UI that advanced users can use to see what is actually going on, that won't disrupt normal users. (Probably by modifying the certificate dialog you currently get to through the security popover: that's sufficiently out of the way it won't be disruptive, and it's already full of technical data.)

HTTP Public Key Pinning (HPKP)

Sites can use HPKP to pin their own public key, or their CA's public key, so that when the browser connects in the future it won't load the page if their pin is not present. This would need to be implemented in WebKit. (I don't think we need to modify glib-networking's certificate verification at all; just layer this on top.) New API will be required since the browser *must* be able to delete pins, and really should also be able to add pins. This might be slightly complex since HPKP provides several different types of pins.

Some work is required in Epiphany: we cannot implement HPKP without also adding UI to allow the user to delete pins, since sites are inevitably going to DoS themselves with bad pins. CryptoCat has already done this with Chrome's preloaded pin; sad them. Work with the GNOME designers to figure out what the UI should look like. Make sure the UI will also allow the user to delete custom pins (see Less Annoying Unacceptable Certificate Interstitial, below), and consider allowing the user to add custom pins as well (but that may be too advanced for Epiphany).

Optional and desirable: A preload list. Chrome's preloaded key pins prevented Iran from reading Chrome users' gmail, and is the only reason Iran got caught at all. This would again need to be in a new package, so it can be updated separately from WebKit. See https://bugzilla.gnome.org/show_bug.cgi?id=736171

Less Annoying Unacceptable Certificate Interstitial

https://bugzilla.gnome.org/show_bug.cgi?id=745351

If you do decide to click through the interstitial, the decision should be remembered indefinitely for the current combination of host and public key: i.e. the public key presented to you should be pinned. There needs to be a dialog somewhere for deleting these pins. Oh hey, we can reuse the dialog that needs to be added for HPKP! And we can reuse whatever API we add to WebKit to support HPKP! So implement HPKP before starting on this! What genius!

Mixed Content Blocking

https://bugzilla.gnome.org/show_bug.cgi?id=733038

Update: The most important bits are all implemented now. Some details are missing, though, and there are bugs.

Security popover

Do something like https://people.mozilla.org/~fqueze2/slides/fosdem2015/#28.0?

Extended Validation Certificates

https://bugzilla.gnome.org/show_bug.cgi?id=721179

EV certificates provide much greater assurance than DV and OV certificates, but they're worthless if the browser UI does not prominently display the organization name in the certificate. Work with the GNOME design team to get a mockup before starting work on this.

  • This needs new API in glib (implemented in glib-networking), libsoup, WebKit, and Epiphany. Tests would need to be written for glib-networking, libsoup, and WebKit.

  • Note that only a few CAs should be permitted to issue EV certs. Figure out how to handle this.

Apps/Web/Roadmap/Security (last edited 2017-05-10 16:01:32 by MichaelCatanzaro)