Most Web users are familiar with the secure version of the basic HTTP protocol, denoted by
https: at the start of a URL,and typically marked by a small padlock icon in the browser. The secure protocol provides for identification of the site, using a cryptographic certificate, and encrypts all communications between the user’s browser and the server. This helps assure the user that (s)he is interacting with the desired site, and not an impostor; it also provides protection against session “sniffing” (otherwise trivially easy on wireless networks) and man-in-the-middle attacks. Many sites, from banks to Facebook, offer HTTPS connections. But people still have to use them, although some sites (GMail, for example) allow the user to set a preference to always use HTTPS.
Another step in the direction of better security has just been taken, according to an article in the Australian publication, Computer World. The Internet Engineering Task Force, a group responsible for setting Internet technical standards, has just approved a standard [RFC 6797] for HTTP Strict Transport Security (HSTS).
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS).
Essentially, the standard allows a site to declare that it will only allow secure connections, and a method for browsers to conform to that policy.
The new standard fixes some loopholes and bad design choices in the original HTTPS standard. For example, when a browser attempts to set up an HTTPS connection, it will generally issue a warning message if there is some problem with the site’s cryptographic certificate; but the user can choose to proceed anyway. In many cases, this is OK; the certificate problem is not serious. Unfortunately, though, sometimes the problem really is serious; this is a Bad Thing if users have become accustomed to just clicking “OK”. With HSTS, the browser will just refuse to make the connection. This may seem draconian, but users are typically not well qualified to evaluate certificate problems, so this approach amounts to “better safe than sorry”. The new standard also addresses a variety of other security issues.
At present, not many sites have support for the new HSTS standard (though PayPal, Twitter, and some Google sites do). I hope that, with the adoption of the formal standard, more sites will provide support for a mechanism that can significantly improve security.