One of the things that makes attackers dance around their basement lairs is finding unencrypted Web sessions. Sites that don’t give users the option to use HTTPS make life that much easier for attackers trying to hijack users’ Web sessions or eavesdrop on them. The IETF has taken a big step toward making that more difficult, approving the HTTP Strict Transport Security (HSTS) proposal as an Internet-draft.
HSTS is designed to allow Web sites to tell users’ browsers that they want to communicate only over an encrypted connection. There are a lot of sites that offer HTTPS connections as an option, but don’t have it enabled by default, so it’s up to the user to request an SSL-encrypted connection. Many of Google’s sites, such as Gmail and the search engine, give users the option of enabling HTTPS by default. The HSTS proposal would define a standard method for sites to declare their preference for SSL connections.
“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). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example,” the HSTS Internet-draft says.
Proposals approved by the IETF as Internet standards do not carry with them the weight of being a requirement, but typically become de facto standards. There already are browsers that use HSTS, including Mozilla Firefox, which included support for HSTS a couple of years ago. Chrome and Opera also have implemented HSTS.
There also are browser plug-ins that accomplish the same thing, telling Web sites that the user only wants to connect over SSL. The HTTPS Everywhere plug-in designed by the EFF is one example, and it’s available for both Firefox and Google Chrome.
The IETF approval process is a long and winding road, so the potential approval day for HSTS isn’t around the corner. Still, the proposed standard is a good incremental step. The authors of the HSTS Internet-draft, engineers from Google, PayPal and Carnegie Mellon University, say that the proposal is meant to protect against three specific classes of threats: passive network attacks, active network attacks and bad Web development. It’s not meant to defend against malware or phishing attacks.
“When a user browses the web on a local wireless network (e.g., an 802.11-based wireless local area network) a nearby attacker can possibly eavesdrop on the user’s unencrypted Internet Protocol-based connections, such as HTTP, regardless of whether or not the local wireless network itself is secured. Freely available wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive eavesdropping attacks, even if the local wireless network is operating in a secure fashion. A passive network attacker using such tools can steal session identifiers/cookies and hijack the user’s web session(s), by obtaining cookies containing authentication credentials. For example, there exist widely-available tools, such as Firesheep (a web browser extension), which enable their wielder to obtain other local users’ session cookies for various web applications,” the proposal says.
“To mitigate such threats, some Web sites support, but usually do not force, access using end-to-end secure transport — e.g., signaled through URIs constructed with the “https” scheme. This can lead users to believe that accessing such services using secure transport protects them from passive network attackers. Unfortunately, this is often not the case in real-world deployments as session identifiers are often stored in non-Secure cookies to permit interoperability with versions of the service offered over insecure transport (“Secure cookies” are those cookies containing the “Secure” attribute [RFC6265]). For example, if the session identifier for a web site (an email service, say) is stored in a non- Secure cookie, it permits an attacker to hijack the user’s session if the user’s UA makes a single insecure HTTP request to the site.”
The next step in the IETF process would be for the HSTS proposal to be elevated to the level of Internet standard.
This story was updated on Oct. 4 to clarify the IETF process.
