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. Last update: July 2018. See the page history for older versions. -- MichaelCatanzaro

Web Process Sandbox

Our previous attempt at a web process sandbox turned out to be unmaintainable. We should use bubblewrap to create a web process sandbox. All major browsers currently have a sandbox, and it's really bad that we don't.

Certificate Revocation


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. :(

Certificate Transparency

If a certificate is not on the certificate transparency audit logs, then we should refuse to load the webpage, same as Chrome. See https://www.certificate-transparency.org/.

TLS Client Authentication


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.



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.)

Less Annoying Unacceptable Certificate Interstitial


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!

Security popover

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

Extended Validation Certificates


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 2018-07-17 23:31:19 by MichaelCatanzaro)