GNOME 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: August 2019. See the page history for older versions. -- MichaelCatanzaro

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.

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

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

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!