Time to use header bars in Unity?

My employer, Igalia, recently purchased a Gazelle Pro from System76 for me to use. So far, it seems like a great laptop, but time will tell. It came with Ubuntu 15.04 preinstalled, so before replacing that with Fedora Workstation, I decided to check out how some of our applications look under Ambiance, the GTK+ theme that Ubuntu uses instead of Adwaita.

For the most part, Ambiance looks great. The overlay scrollbars leave much to be desired compared to upstream’s, but that’s my only real complaint. I found that Ambiance makes better use of space in general, using much less padding than Adwaita to fit significantly more content into application windows. (This is the reason behind complaints that “everything is bigger” in GNOME.) On the whole, that seems like a big advantage over Adwaita to me, though I’m concerned that might make it harder to use a touchscreen.

But I found some of the applications I maintain did not look so great, due to no fault of Ambiance, but to some non-ideal use of GtkHeaderBar.

When we started using GtkHeaderBars to replace system title bars a couple years ago, many GTK+ themes needed some time to catch up, as they were suddenly responsible for themeing title bars to look similar to the window manager’s title bars. One disadvantage of this is that it’s no longer possible to mix-and-match GTK+ themes with different window manager themes and get a good result, but if the GTK+ theme matches the window manager’s theme, there is no problem.

This approach worked well enough for us with most distributions, but Ubuntu, rather than improving their theme (which is not easy work, to be sure) and using the provided settings to put the proper window decorations in the right place, started patching our applications to set the header bars as the title bars only in GNOME. These patches took various forms: in some cases, like Calculator, the header bar was removed and its contents replaced with a menu bar (a strategy I dislike: we’ve been getting rid of menu bars because they are difficult to use), but generally the header bar was kept and simply packed underneath the title bar, instead of replacing the title bar. Since this made things worse in environments with updated themes that used the new window decoration settings, I decided to start accepting these patches upstream (in most cases), but tweaked so that the header bar would be used as the title bar in all desktops except Unity, rather than only in GNOME.

The problem is, Ubuntu’s handling of header bars as title bars has since improved considerably, and it seems applications look better now with the header bars used as title bars than with the header bars underneath the title bars. Compare Font Viewer (which uses a header bar as the title bar) to Disks and Sudoku (which pack the header bar underneath the title bar, but only when running in Unity):

Disks and Sudoku pack header bars underneath the title bar when running in Unity. Font Viewer sets the header bar as the title bar unconditionally.
Disks and Sudoku pack header bars underneath the title bar when running in Unity. Font Viewer sets the header bar as the title bar unconditionally. Which looks better?

Seems to me that Font Viewer is looking much nicer than Disks and Sudoku. Sudoku is also suffering from redundancy, since the application title is included in both the title bar and the header bar. That’s fixable, but since this is a non-default configuration that developers never test, similar problems are just going to return.

The same applications running under GNOME. (Look at Disks to see how Ambiance uses less space than Adwaita, though it's more noticeable in other applications.)
The same applications running under GNOME. (Look at Disks to see how Ambiance uses less space than Adwaita, though it’s more noticeable in other applications.)

So my inclination is to drop our special handling of Unity. Ubuntu might patch it back in — it is free software, after all — but maybe not, and in any case I’d feel better about the code we have upstream. Which approach looks better to you?

Your _get_type() function is not G_GNUC_CONST

It’s not uncommon in GNOME to annotate the _get_type() function declaration of a GObject with G_GNUC_CONST. Like so:

GType ephy_download_get_type (void) G_GNUC_CONST;

What does this do? It expands to __attribute__((__const__)) if the compiler is GCC (or a compiler that pretends to be GCC, like Clang); otherwise, it expands to nothing. What does that attribute do? I could point you at the GCC documentation, but GLib’s documentation is simpler: “Declaring a function as const enables better optimization of calls to the function. A const function doesn’t examine any values except its parameters, and has no effects except its return value.” That’s really all there is to it. What’s important to keep in mind is that if your function doesn’t meet the preconditions for the attribute, the compiler is free to make optimizations that break your code.

Since G_DEFINE_TYPE defines our _get_type() functions for us, it can be easy to forget what’s actually in there. Here’s the canonical example, from the GObject documentation:

GType maman_bar_get_type (void)
{
  static GType type = 0;
  if (type == 0) {
    const GTypeInfo info = {
      /* You fill this structure. */
    };
    type = g_type_register_static (G_TYPE_OBJECT,
                                   "MamanBarType",
                                   &info, 0);
  }
  return type;
}

The first thing you should notice is that it examines a value (type) that’s not a parameter. Next, you should notice that it has an effect other than its return value: it modifies type, and then registers with the type system. Obviously G_GNUC_CONST is not appropriate here. Fix your headers. Update: If you scroll down to the first comment below, Giovanni recommends using G_GNUC_CONST anyway and also g_type_ensure as a workaround for if you don’t use the return value of the function.

Note that the new, highly-recommendable G_DECLARE_FINAL_TYPE and G_DECLARE_DERIVABLE_TYPE macros declare this function for you, so future code should be immune to this problem. Update: Those macros do not use G_GNUC_CONST, but maybe they will in the future? Who can say!

P.S. I’m not the one who noticed this — it was brought up by somebody (Christian?) at the Boston Summit last year — but I don’t think anybody has blogged about it yet. Update: It was pointed out in the comments that this was noticed long ago. Here’s a GLib bug report about breakage in Glade, and my colleague Andy Wingo has a blog post about a GStreamer bug this caused.

Useful DuckDuckGo bangs

DuckDuckGo bangs are just shortcuts to redirect your search to another search engine. My personal favorites:

  • !gnomebugs — Runs a search on GNOME Bugzilla. Especially useful followed by a bug number. For example, search for ‘!gnomebugs 100000’ and see what you get.
  • !wkb — Same thing for WebKit Bugzilla.
  • !w — Searches Wikipedia.

There’s 6388 more, but those are the three I can remember. If you work on GNOME or WebKit, these are super convenient.

Stop using RC4

A follow up of my previous post: in response to my letter, NIST is going to increase the CVSS score of CVE-2013-2566 (RC4) to match CVE-2011-3389 (BEAST). Yay!

In other news, WebKitGTK+ 2.8 has full support for RFC 7465. That’s a fancy way of saying that we will no longer negotiate RC4 connections and you will now be unable to access the small minority of HTTPS sites that offer nothing but RC4. Hopefully other browsers will follow along sooner rather than later. In particular, Firefox nightly has stopped negotiating RC4 except for a few whitelisted sites: I would very much like to see that whitelist removed. Internet Explorer has stopped negotiating RC4 except when it performs voluntary protocol version fallback. It would be great to see a firmer stance from Mozilla and Microsoft, and some action from Google and Apple.

Security and Privacy Roadmap for Epiphany and WebKitGTK+

I’ve laid out some informal thoughts on where we should be heading with regards to new security and privacy features in Epiphany. It’s in the form of a list of features we really ought to have. (That is, it’s a wishlist.) Most of these features would be implemented in WebKitGTK+, so other applications using WebKitGTK+ would benefit as well.

There’s certainly no shortage of work to be done, so except for a couple items on the list, this is not a list of things you should expect to be implemented soon. Comments welcome on the wiki or on this blog. Volunteers especially welcome! Most of these tasks on the list would make for great GSoC projects (but I’m not accepting more applicants this year: prospective students should find another mentor who’s interested in one of the tasks).

The list will also be used to help assign one or more bounties using some of the money we raised in our 2013 security and privacy campaign.

RC4 vs. BEAST: which is worse?

RFC 7465 has been published, and in a perfect world it would spell doom for the use of RC4 in TLS. But, spoiler alert, the theme of this blog is that there are tons of problems with TLS that your browser either cannot or willfully will not protect you against — major browser vendors love nothing more than sacrificing your security in the name of compatibility with lousy servers — so it’s too soon for optimism.

This guy who sounds like he knows what he’s talking about and who I’ve blindly decided to trust says that PCI-compliant sites must disable CBC-based block ciphers so that they’re not vulnerable to the BEAST attack against TLS 1.0. But CBC is the only mode for block ciphers that provides a reasonable level of security in TLS 1.0, so these servers are limited to negotiating only stream ciphers. And RC4 is the only stream cipher in TLS, so that’s the only thing these poor servers are left with. But nobody is actually vulnerable to BEAST anymore — web browsers have been able to prevent the BEAST attack for several years — so this makes no sense.

So what it a PCI-compliant site? In theory, it’s any site that processes credit card data. For instance, check out the SSL Labs report for www.bankofamerica.com. (In case you’re not yet thoroughly convinced of the truth of the second sentence in this post, take note of the eight bold WEAK warnings and also the bold DANGER. Even major banks don’t care.) Scroll down to the handshake simulations and note how AES is only sometimes used with TLS 1.2, and RC4 is always picked with TLS 1.0. In practice, I’ve checked SSL Labs results for sites that do use AES with TLS 1.0, like www.amazon.com, that do take credit card data, so I’m not sure if guy-who-sounds-like-he-knows-what-he’s-talking-about has the full story, but maybe audits come less frequently than I would expect.

Hopefully browser vendors will push forward and disable RC4 anyway, but that doesn’t seem sufficiently probable, and these poor sites are hardly going to disable RC4 if it means they will fail their next security audit. So what better way to spend a Friday afternoon than write a letter to NIST?

Hi,

The CVSS score for CVE-2011-3389 (BEAST) [1] relative to the score for CVE-2013-2566 [2] may discourage efforts to implement RFC 7465 [3], which prohibits use of RC4-based ciphersuites with TLS. Delays in the implementation of this RFC will harm the overall security of the TLS ecosystem.

The issue is described succinctly at [4]: PCI-compliant servers may not enable CBC-based ciphersuites because CVE-2011-3389 has a base score of 4.3, leaving RC4-based ciphersuites as the only possible options for the server to use with TLS 1.0. CVE-2013-2566, the RC4 vulnerability, has a lower CVSS score. However, CVE-2013-2566 is a much more serious issue in practice. CVE-2011-3389 has been long-since mitigated on the client side in major browsers using the 1/n-1 split technique [5], allowing CBC-based ciphersuites to be used safely. In contrast, no client-side mitigation for CVE-2013-2566 is available short of disabling RC4. Note also that a more serious attack against RC4 will be published next month [6].

In summary, a properly-configured TLS server *should not* attempt to mitigate CVE-2011-3389, as this discourages clients from mitigating CVE-2013-2566, and clients already mitigate CVE-2011-3389. Please reconsider the relative ratings for these vulnerabilities to allow PCI-compliant servers to re-enable CBC-based ciphersuites, so that browser vendors can more comfortably disable support for RC4 as required by RFC 7465 [4] [7] [8].

Thank you for your consideration,

Michael Catanzaro

[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
[2] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2566
[3] http://www.rfc-editor.org/rfc/rfc7465.txt
[4] https://code.google.com/p/chromium/issues/detail?id=375342#c17
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c59
[6] https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=999544
[8] https://bugs.webkit.org/show_bug.cgi?id=140014

Now, will this actually work? Will I even get a response? I have no clue. Let’s find out!

Mozilla is responsible for the redhat.corpmerchandise.com fiasco

First of all, I should probably admit that, despite the title of this post, no, the redhat.corpmerchandise.com fiasco is not Mozilla’s fault: it’s Red Hat’s, because obviously Mozilla has no control over that domain. But that wouldn’t make for a very interesting title for a blog post, and Mozilla set the stage for this to happen, so let’s go with “Mozilla’s fault.” Also, it’s not really Red Hat’s fault; Staples is really to blame, since corpmerchandise.com is their domain, but I really shouldn’t be pointing that out when the point of this blog post is to blame Mozilla. And gosh now I’m off on a tangent, but it’s not really a fiasco either: it’s a significant screw-up, but not that big a deal; but words like “fiasco” make for good clickbait headlines, so let’s go with that. FIASCO.

One last note before I begin. I hold Mozilla to a higher standard than other software development companies. Sometimes it makes mistakes, like the one I’m about to present, and it’s important to call them out when this happens, but it’s because of good choices at Mozilla that Firefox still (mostly) respects your freedom, unlike other major browsers. It’s a good company.

OK, so you’ve read this far in suspense, I should probably explain the redhat.corpmerchandise.com fiasco before you reach the end of your three-paragraph Internet-length attention span. Yesterday the Fedora Store went live, where you can buy low-cost Fedora-branded items: a T-shirt, water bottle, pub glass, or baseball cap. I want a T-shirt. OK, that’s great, so what is the fiasco? Well click on this link (quick! before it gets fixed!) to find out: https://redhat.corpmerchandise.com/ProductList.aspx?did=20588

Now, depending on your browser, you may or may not have discovered the problem. When I load that site in Firefox, I see Fedora merchandise. When I load it in Epiphany, I see something noticeably less friendly:

Screenshot from 2015-01-30 20:06:22

“Legitimate banks, stores, and other public sites will not ask you to do this.” Ouch. (I actually took that language from Firefox when I designed that interstitial for Epiphany.) Ah, well, clearly there is some bug in Epiphany, because Firefox is a major browser and Firefox doesn’t get stuff like this wrong, right? Well, no, Epiphany is not wrong. Then Firefox is wrong? Well… from a certain point of view… (like mine)….

Firefox and Epiphany use different cryptography libraries to determine if the certificate is valid, and they sometimes differ in what certificates they will accept. Firefox uses NSS, a library maintained by Mozilla primarily for use by Firefox (it’s also used by Chrome on Linux), while Epiphany (indirectly) uses GnuTLS, originally a GNU project that is now de-facto maintained by Red Hat. So is NSS just better than GnuTLS at determining whether a certificate is valid? Actually, NSS really is more permissive than GnuTLS, and this does sometimes lead Firefox to approve of sites that Epiphany will not, but that’s not the case here. Let’s try a little experiment to see what’s happening. Firefox has a weird feature that feels like it was designed in the 90s for the era when computers had one user account apiece: it lets you create multiple profiles for bookmarks, history, and other settings. So let’s give this a whirl:

$ firefox -ProfileManager

Create a new profile, launch Firefox with it, then load https://redhat.corpmerchandise.com/ProductList.aspx?did=20588 to try this experiment again. Or just keep reading and trust me when I say that you’ll see this:

Screenshot from 2015-01-30 20:23:45

Oooh, that’s not good, now Firefox thinks we’re being attacked. We’re not. So what’s going on here? Why is Firefox so inconsistent?

First off, let’s get one thing straight: this site is totally and hopelessly broken. To see why, let’s use the super-handly tool gnutls-cli:

$ gnutls-cli redhat.corpmerchandise.com
Processed 182 CA certificate(s).
Resolving 'redhat.corpmerchandise.com'...
Connecting to '174.47.191.32:443'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
- subject `C=US,ST=Kansas,L=Overland Park,O=STAPLES CONTRACT & COMMERCIAL\, INC.,OU=Information Techology,CN=*.corpmerchandise.com', issuer `C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 High Assurance Server CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2014-11-12 00:00:00 UTC', expires `2015-12-09 12:00:00 UTC', SHA-1 fingerprint `50cfb26c680434d132dc64e80db54de51a5a07a6'
Public Key ID:
c273ca58bfdb2902ea30dbf5946c27178affd588
Public key's random art:
+--[ RSA 2048]----+
| |
| |
| |
| . |
| = S |
| .* O o o |
|o .+.X E o . |
| =.. =.+.+ . |
|..o oo+oo |
+-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is unknown.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

If you’re familiar with digital certificates, it’s pretty obvious what’s wrong here. When you connect securely to a web site, it sends a chain of certificates: the first certificate is owned by the web site, then it sends some number of additional certificates, usually one or two, that belong to certificate authorities. Each certificate is signed by the next certificate in the chain (not quite, but it’s almost true, so let’s go with that for this post), up until you get to the last one in the chain, which must be signed by a certificate in your browser’s (or operating system’s) root trust store. The certificates in your root trust store are super valuable, and if one were to be compromised by an attacker the devastation to the Web would be terrible, so certificate authorities must keep their roots safe at all costs, and they do this by almost never using them. Legitimate certificate authorities never sign web sites’ certificates with their root certificate; instead, they create a few other certificates, sign them with the root, and use only those to sign web sites’ certificates. So if you ever visit a site and it sends you only one certificate, you know that the site is broken for sure. And here we have a site that has sent only one certificate (there’s a Certificate[0] but no Certificate[1]), a classic case of server misconfiguration (aka fiasco).

So why did Firefox allow the site at first, even though it has no chain of trust, but not allow it with a fresh profile? Well, even though the site has presented no chain of trust, NSS goes far, far out of its way to find one. Whenever you visit a web site, NSS saves each intermediate certificate it sees, makes sure it’s signed by a trusted root, and caches it for future use. Then, whenever you visit a site that sends a broken chain of trust, NSS will effectively treat all those intermediates as roots, and use them to complete the chain of trust. This is completely safe, since it has already verified them. Those intermediate certs are saved in your Firefox profile, so by switching to a fresh profile they are no longer used, and you can’t access the broken site anymore.

If you were able to access redhat.corpmerchanise.com in Firefox, you can verify this for yourself: open Preferences -> Advanced -> Certificates -> View Certificates -> Authorities. Anything listed as Default Trust or System Trust is a root, and anything listed as Software Security Device is a cached intermediate cert. Don’t touch those root certs, but feel free to Delete or Distrust any Software Security Device — it will just be cached again the next time you visit a web site that uses it. Scroll down to DigiCert SHA2 High Assurance Server CA. That’s the cached intermediate cert that is allowing you to visit redhat.corpmerchandise.com — it’s not shipped with Firefox, and new Firefox users won’t have it. Delete it, restart the browser, then try reloading https://redhat.corpmerchandise.com. Oh no, it’s untrusted! Now visit https://stackoverflow.com, which sends a certificate signed by DigiCert SHA2 High Assurance Server CA, which will cause NSS to cache it once again. Now back to https://redhat.corpmerchandise.com, and Firefox knows it’s safe again. And that, folks, is how you screw up your web site so that it only works if you first visit Stack Overflow.

So why does NSS do this? Well, once upon a time (ten years ago), browsers were less strict about verifying chains of trust, and on an untrusted connection would let you proceed with maybe just a pop-up warning, and maybe not even that. So sites were less diligent about making sure they had valid chains of trust than they are today, in the era of nasty interstitial warnings that discourage the user from visiting the site. Since there were a lot of sites with broken chains, NSS chose to cache intermediate certificates to reduce the number of unnecessary validation errors for Firefox users. At the time, this might have been an OK choice.

Today, if your online store is missing a chain of trust, the browser makes clear in no uncertain terms that this site is not to be trusted, and sites lose visitors/customers, so they try pretty hard to get this right. (How many lost visitors depends on the browser — a large majority of Chrome and probably Epiphany users will click through the warnings, but a large majority of Firefox users will not, because Firefox’s UI for this is much scarier.) When setting up a new site, you check it in a couple of browsers to make sure it works properly, and you trust that if it works in Firefox on your machine, surely it will work in Firefox for everyone else, right? Well, no, it won’t. When setting up a secure web site, you must always test it with a fresh Firefox profile to make sure that you got the chain of trust correct. Of course, nobody knows to do this, which is how we wind up with broken sites like redhat.corpmerchandise.com.

I suspect this breakage would happen far less often if NSS did not cache intermediate certs, tricking site admins into thinking their sites are set up properly. Sure, cached certs don’t hurt the user who has them cached, but they’re bad for all other users of Firefox, as well as users of browsers that do no certificate caching. And there’s no good reason for this, because browsers don’t need to cache intermediate certificates in 2015, because almost all sites that redirect from HTTP to HTTPS get this right nowadays, and those that get it wrong are probably getting it wrong because they tested with a browser that had the right cached intermediate. Chicken and egg much? There’s only one way to fix this problem, and that brings me to my request: Mozilla, do the Web a favor and stop caching intermediate certificates.

P.S. Astute readers would note that there’s absolutely no point in deleting an intermediate certificate with the Firefox certificate manager, except to test things like this. It’s just going to come back the next time you see it.

Amazon redirecting to HTTP

For the past couple of weeks, https://www.amazon.com and https://amazon.com have redirected me to http://www.amazon.com. Region-specific sites like https://www.amazon.co.uk/ still work fine. There is probably no MITM attacker, since the secure page is performing the redirect, so a MITM would have to have a valid certificate for www.amazon.com, and if so he would presumably not add a redirect.

Questions for Amazon:

  • What the hell?
  • Why does your site work at all without HTTPS?
  • How am I going to buy things now?

It’s 2014, and this is unacceptable for an e-commerce site, plain and simple. Repent by implementing HSTS.

GNOME Web 3.14

It’s already been a few weeks since the release of GNOME Web 3.14, so it’s a bit late to blog about the changes it brings, but better late than never. Unlike 3.12, this release doesn’t contain big user interface changes, so the value of the upgrade may not be as immediately clear as it was for 3.12. But this release is still a big step forward: the focus this cycle has just been on polish and safety instead of UI changes. Let’s take a look at some of the improvements since 3.12.1.

Safety First

The most important changes help keep you safer when browsing the web.

Safer Handling of TLS Authentication Failures

When you try to connect securely to a web site (via HTTPS), the site presents identification in the form of a chain of digital certificates to prove that your connection has not been maliciously intercepted. If the last certificate in the chain is not signed by one of the certificates your browser has on file, the browser decides that the connection is not secure: this could be a harmless server configuration error, but it could also be an attacker intercepting your connection. (To be precise, your connection would be secure, but it would be a secure connection to an attacker.) Previously, Web would bet on the former, displaying an insecure lock icon next to the address in the header bar, but loading the page anyway. The problem with this approach is that if there really is an attacker, simply loading the page gives the attacker access to secure cookies, most notably the session cookies used to keep you logged in to a particular web site. Once the attacker controls your session, he can trick the web site into thinking he’s you, change your settings, perhaps make purchases with your account if you’re on a shopping site, for example. Moreover, the lock icon is hardly noticeable enough to warn the user of danger. And let’s face it, we all ignore those warnings anyway, right? Web 3.14 is much stricter: once it decides that an attacker may be in control of a secure connection, it blocks access to the page, like all major browsers already do:

Screenshot from 2014-10-17 19:52:53
Click for full size

(The white text on the button is probably a recent compatibility issue with GTK+ master: it’s fine in 3.14.)

Safety team members will note that this will obviously break sites with self-signed certificates, and is incompatible with a trust-on-first-use approach to certificate validation. As much as I agree that the certificate authority system is broken and provides only a moderate security guarantee, I’m also very skeptical of trust-on-first-use. We can certainly discuss this further, but it seemed best to start off with an approach similar to what major browsers already do.

The Load Anyway button is non-ideal, since many users will just click it, but this provides good protection for anyone who doesn’t. So, why don’t we get rid of that Load Anyway button? Well, different browsers have different strategies for validating TLS certificates (a good topic for a future blog post), which is why Web sometimes claims a connection is insecure even though Firefox loads the page fine. If you think this may be the case, and you don’t care about the security of your connection (including any passwords you use on the site), then go ahead and click the button. Needless to say, don’t do this if you’re using somebody else’s Wi-Fi access point, or on an email or banking or shopping site… when you use this button, the address in the address bar does not matter: there’s no telling who you’re really connected to.

But all of the above only applies to your main connection to a web site. When you load a web page, your browser actually creates very many connections to grab subresources (like images, CSS, or trackers) needed to display the page. Prior to 3.14, Web would completely ignore TLS errors for subresources. This means that the secure lock icon was basically worthless, since an attacker could control the page by modifying any script loaded by the page without being detected. (Fortunately, this attack is somewhat unlikely, since major browsers would all block this.) Web 3.14 will verify all TLS certificates used to encrypt subresources, and will block those resources if verification fails. This can cause web pages to break unexpectedly, but it’s how all major browsers I’ve tested behave, and it’s certainly the right thing to do. (We may want to experiment with displaying a warning, though, so that it’s clear what’s gone wrong.)

And if you’re a distributor, please read this mail to learn how not to break TLS verification in your distribution. I’m looking at you, Debian and derivatives.

Fewer TLS Authentication Failures

With glib-networking 2.42, corresponding to GNOME 3.14, Web will now accept certificate chains when the certificates are sent out of order. Sites that do this are basically broken, but all major browsers nevertheless support unordered chains. Sending certificates out of order is a harmless configuration mistake, not a security flaw, so the only harm in accepting unordered certificates is that this makes sites even less likely than before to notice their configuration mistake, harming TLS clients that don’t permute the certificates.

This change should greatly reduce the number of TLS verification failures you experience when using Web. Unfortunately, there are still too many differences in how certificate verification is performed for me to be comfortable with removing the Load Anyway button, but that is definitely the long-term goal.

HTTP Authentication

WebKitGTK+ 2.6.1 plugs a serious HTTP authentication vulnerability. Previously, when a secure web page would require a password before the user could load the page, Web would not validate the page’s TLS certificate until after prompting the user for a password and sending it to the server.

Mixed Content Detection

If a secure (HTTPS) web page displays insecure content (usually an image or video) or executes an insecure script, Web now displays a warning icon instead of a lock icon. This means that the lock icon now indicates that your connection is completely private, with the exception that a passive adversary can always know the web site that you are visiting (but not which page you are visiting on the site). If the warning icon is displayed, then an adversary can compromise some (and possibly all) of the page, and has also learned something that might reveal which page of the site you are visiting, or the contents of the page.

If you’re curious where the insecure content is coming from and don’t mind leaving behind Web’s normally simple user interface, you can check using the web inspector:

Screenshot from 2014-10-17 21:07:52
The screenshot is leaked to an attacker, revealing that you’re on the home page. Click for full size.

The focus on safety will continue to drive the development of Web 3.16. Most major browsers, with the notable exception of Safari, take mixed content detection one step further by actively blocking some more dangerous forms of insecure content, such as scripts, on secure pages, and we certainly intend to do so as well. We’re also looking into support for strict transport security (HSTS), to ensure that your connection to HSTS-enabled sites is safe even if you tried to connect via HTTP instead of HTTPS. This is what you normally do when you type an address into the address bar. Many sites will redirect you from an HTTP URL to an HTTPS URL, but an attacker isn’t going to do this kindness for you. Since all HTTP pages are insecure, you get no security warning. This problem is thwarted by strict transport security. We’re currently hoping to have both mixed content blocking and strict transport security complete in time for 3.16.

UI Changes

Of course, security hasn’t been the only thing we’ve been working on.

  • The most noticeable user experience change is not actually a change in Web at all, but in GNOME Document Viewer 3.14. The new Document Viewer browser plugin allows you to read PDFs in Web without having to download the file and open it in Document Viewer. (This is similar to the proprietary Adobe Reader browser plugin.) This is made possible by new support in WebKitGTK+ 2.6 for GTK+ 3 browser plugins.
  • The refresh button has been moved from the address bar and is now next to the new tab button, where it’s always accessible. Previously, you would need to click to show the address bar before the refresh button would appear.
  • The lock icon now opens a little popover to display the security status of the web page, instead of directly presenting the confusing certificate dialog. You can also now click the lock when the title of the page is displayed, without needing to switch to the address bar.

Bugfixes

3.14 also contains some notable bugfixes that will improve your browsing experience.

  • We fixed a race condition that caused the ad blocker to accidentally delete its list of filters, so ad block will no longer randomly stop working when enabled (it’s off by default). (We still need one additional fix in order to clean this up automatically if it’s already broken, but in the meantime you can reset your filters by deleting ~/.config/epiphany/adblock if you’re affected.)
  • We (probably!) fixed a bug that caused pages to disappear from history after the browser was closed.
  • We fixed a bug in Web’s aggressive removal of tracking parameters from URLs when the do not track preference is enabled (it’s off by default), which caused compatibility issues with some web sites.
  • We fixed a bug that caused Web to sometimes not offer to remember passwords.

These issues have all been backported to our 3.12 branch, but were never released. We’ll need to consider making more frequent stable releases, to ensure that bugfixes reach users more quickly in the future.

Polish

  • There are new context menu entries when right-clicking on an HTML video. Notably, this adds the ability to easily download a copy of the video for watching it offline.
  • Better web app support. Recent changes in 3.14.1 make it much harder for a web app to escape application mode, and ensure that links to other sites open in the default browser when in application mode.
  • Plus a host of smaller improvements: The subtitle of the header bar now changes at the same time as the title, and the URL in the address bar will now always match the current page when you switch to address bar mode. Opening multiple links in quick succession from an external application is now completely reliable (with WebKitGTK+ 2.6.1); previously, some pages would load twice or not at all. The search provider now exits one minute after you search for something in the GNOME Shell overview, rather than staying alive forever. The new history dialog that was added in 3.12 now allows you to sort history by title and URL, not just date. The image buttons in the new cookies, history, and passwords dialogs now have explanitory tooltips. Saving an image, video, or web page over top of an existing file now works properly (with Web 3.14.1). And of course there are also a few memory usage and crash fixes.

As always, the best place to send feedback is <epiphany-list@gnome.org>, or Bugzilla if you’ve found a bug. Comments on this post work too. Happy browsing!