Opportunistic Encryption and How Browsers Handle Certificate Problems

As a follow-up to my last post on improving privacy on the Internet, I ran across the concept of opportunistic encryption, which I’ve heard about before but has never seemed to go anywhere.

Opportunistic encryption seems most interesting at the TCP layer, so that it is transparent to not only the user, but to applications that use the network as well. However, there are technical challenges to successfully implementing it without introducing undue complexity or noticeable reductions in performance. Such schemes have also never been accepted by a standards body, so their chance of widespread adoption seems slim (though you can try one such scheme, TCPCrypt, already; however, it requires the other end of your communication to have TCPCrypt installed as well, which seems unlikely in most cases).

Thus, as I noted in the last post, web and email seem to offer the best opportunities for adding encryption that’s transparent to the user.

How web browsers handle encryption problems

This leads us to https, the security and privacy protocol for web browsing. As I said previously, we’d like to encourage as many web servers to support, and preferably even mandate, the use of SSL/TLS for web browsing. And the web developers, systems administrators, and internet engineers our there can certainly help make that happen.

But there are lots of things to get right when implementing web security. Getting them wrong can make you susceptible to various kinds of attacks, mostly based on some form of of man-in-the-middle. That’s why browsers go to such lengths to warn users about problems, often denying access to the site if a problem is detected, until the user explicitly overrides this warning.

But is this the right behavior to take? Is badly-configured encryption really worse than no encryption at all? Web browser vendors sure seem to think so, but I disagree. While a misconfiguration such as a mismatch between the domain named in the certificate and the actual hostname may be a sign of a man-in-the-middle attack, in my experience it’s almost always due to something else. Similarly, self-signed or expired certificates are extremely unlikely to indicate a man-in-the-middle attack. And while none of these situations is ideal, they are all almost always far better than having no encryption at all.

Undesired behavior

So what actually happens when a server has a misconfigured certificate, and the browser throws up a big warning? Either the user can ignore the warning (which is potentially dangerous, but actually fine 99% or more of the time), they can switch to insecure http (which is, at best, the same as continuing with the untrusted encryption, but much worse the vast majority of the time), or they can discontinue using the site entirely, which hurts both them and the business, and is usually unnecessary since the chances of it being an actual man-in-the-middle attack are slim.

When the operator of the site sees the problem, they may choose to fix it – but they might just choose to disable https instead (and aside from e-commerce sites, I’d suspect the latter is more likely, at least in the short term). Yes, they should fix it, but more often than not they are not going to.

The net result of these browser warnings is scaring and confusing users without increasing their security, since between the users and the website owners, the most likely course of action is to either ignore the warning and proceed (which browser vendors have combatted with ever more dire and difficult to bypass warnings), or to revert to the even-worse unsecured http.

False sense of security

But at least from the point of view of opportunistic encryption, encryption using an expired, weak, self-signed certificate is vastly preferable to no encryption at all. The only danger is providing a false sense of security. But browser vendors have done exactly that by turning everything on its head, by making totally unsecured connections seem preferable to many sorts of encrypted connections, since the unsecured connections do not throw up warnings in the browser!

We need to encourage the use of https connections on the Internet, and part of encouraging its use means not discouraging it where the implementation is not perfect. While we should encourage proper implementations most of all, we should also encourage opportunistic encryption as better than no encryption, even if we aren’t guaranteeing privacy or integrity in the face of man-in-the-middle attacks (which take some effort and are quite rare in the grand scheme of things).

How to fix this?

The fix should actually be simple: change how web browsers communicate to users problems with how encryption is implemented. And most of all, how that communication compares to how it handles totally unencrypted connections.

I propose a “sliding scale” of perceived security. In the browser bar, the scale could be represented by a range of colors and icons, as follows:

  • UNENCRYPTED: Non-https connections would always be highlighted in red. Use of “null” encryption ciphers would also put a connection in this category. In addition, I’d suggest a “bullhorn” or similar icon to communicate that you are broadcasting your activity to the world (a typical radio broadcast icon could work too, but could be confused with wifi). When clicking for more detail, it could warn the user as follows:
    • THE BAD:
      • Your connection is unencrypted. Anyone on the Internet could listen in and see what you’re doing, including viewing your password if you are logging in, could modify or replace the content sent between you and the server without your knowledge, or could be logged in as you and have full access to your account.
  • INSECURE ENCRYPTION: This would be used for various kinds of encryption which have problems that could leave them susceptible to or be a sign of a man-in-the-middle attack, such as self-signed certificates, revoked or long-since expired certificates, or certificates for a domain which does not match the hostname, but where the encryption is still useful for opportunistic encryption and protecting from casual observers. Use of particularly insecure types of encryption (weak or compromised ciphers such as “export” ciphers, too-short key length, etc.) could also contribute to showing up in this category. These should be signified by a broken or unlocked lock icon. Clicking for more detail could notify the user as follows:
    • THE BAD:
      • The certificate used by this site is [unsigned/signed for a domain that does not match the actual hostname/expired/revoked], and thus does not guarantee protection from a man-in-the-middle attack. (Along with more detail, such as a comparison of the domain name for the certificate with the actual host name, the date the certificate expired or was revoked, and a note that certificates could be revoked due to knowledge that the encryption keys have been stolen or misused.)
      • (possibly) The encryption in use is considered weak enough to be easily cracked in a reasonable time by “brute force” methods.
    • THE GOOD:
      • Your connection is encrypted, so your activities cannot be viewed by casual observers monitoring traffic on the Internet.
      • Man-in-the-middle attacks take some effort to mount and are fairly rare, so most likely your connection is secure and the warning is due to a much more mundane misconfiguration; however, there is no way to guarantee it.
  • SEMI-SECURE ENCRYPTION: This might have some kind of closed or almost-closed (maybe closed, but with a crack) lock icon. It would be a variant of the above, but where the “misconfigurations” were considered more minor, such as:
    • Signed for a subdomain that doesn’t match the hostname exactly, but shares the same overall domain name. For instance, a certificate signed for “users.mysite.com” would be considered semi-safe if used on “www.mysite.com” (or any other *.mysite.com), even though it’s not an exact match.
    • Recently expired, for instance within the last 90 days.
    • Encryption that may have some weaknesses, but is considered secure against anyone short of the NSA, and probably not super easy for even the NSA to crack in a reasonable time and on a wide scale.
  • SECURE CONNECTION: This would be used for connections that are considered fully secure: a properly signed (by a trusted certificate authority), unexpired and unrevoked certificate which matches the hostname. The connection should also be using the strongest cipher suites available. These would have a closed lock icon. Clicking for more detail could notify the user as follows:
    • THE GOOD:
      • Your connection is encrypted, so your activities cannot be viewed by observers monitoring traffic on the Internet.
      • The certificate used by this site is properly signed by a certificate authority, is not expired or revoked, and matches the hostname it is signed for, protecting you from man-in-the-middle attacks.
  • Extended validation: Much is made of extended validation certificates, which verify more information about the identity of the site using the certificate, and in the case of e-commerce it may make some sense to help trust who you are giving your money to. But I think they are more a means to increase profits for the certificate vendors, and I think the visual differentiation they are given is wholly unwarranted. Even a site with an EV certificate could take your money without shipping you the product you ordered, charge more than agreed, sell your information to others, or otherwise cheat you; they could also be just as likely to allow NSA access to their private encryption key (either through cooperation or hacking). And most sites without EV certificates are probably perfectly trustworthy even if they didn’t bother to pay 10x as much to get their certificate. However, it could add a green checkmark across the lock icon and an additional benefit to the “Good” category when clicking for more detail:
    • THE GOOD:
      • Your connection is encrypted, so your activities cannot be viewed by observers monitoring traffic on the Internet
      • The certificate used by this site is properly signed by a certificate authority, is not expired or revoked, and matches the hostname it is signed for, protecting you from man-in-the-middle attacks.
      • The domain for this website has undergone extended validation of the identity of its owner.
  • Forward secrecy: Using ephemeral cipher suites to achieve “perfect forward secrecy” is also highly desirable, and such sites should be differentiated with an even more secure-looking icon (or at least sparkly/magical/happy-looking) and an additional benefit:
    • THE GOOD:
      • The encryption keys change each time you connect, so gaining the master keys will not allow an attacker to see your past or future activities.
Tagged , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: