How to Deploy HTTPS Correctly | Electronic Frontier Foundation
https://www.eff.org/https-everywhere/deploying-https
Chris Palmer, 15 Nov 2010
Internet technologists have long known that HTTP is insecure, causing many risks to users. The release of Firesheep made one of these risks concrete and obvious to even non-technical folks.
While HTTPS has long existed as a reasonable way to improve web security, web operators have been slow to host their applications with it. In part, this is because correctly and completely hosting an application with HTTPS takes some care.
This article is designed to help web operators get a conceptual handle on how to protect their users with HTTPS. Taking a little bit of care to protect your users is a reasonable thing for web application providers to do, and a good thing for users to demand.
Background
HTTPS provides three security guarantees:
- Server authentication allows the browser and the user to have some confidence that they are talking to the true application server. Without this guarantee, there can be no guarantee of confidentiality or integrity.
- Data confidentiality means that eavesdroppers cannot understand the communications between the user’s browser and the web server, because the data is encrypted.
- Data integrity means that a network attacker cannot damage or alter the content of the communications between the user’s browser and the web server, because they are validated with a cryptographic message authentication code.
HTTP provides no security guarantees, and applications that use it cannot possibly provide users any security. When using a web application hosted via HTTP, people have no way of knowing whether or not they are talking to the true application server, nor can they be sure attackers have not read or modified communications between the user’s computer and the server.
Modes of Attack and Defense
However users connect to the Internet, there are a variety of people who can attack them—whether spying on them, impersonating them, tampering with their communications, or all three of these. The wifi network operator can do this; any ISP in the path between client and server can do it; anyone who can reconfigure the wifi router or another router can do it; and often, anyone else using the same network can do it, too.
Firesheep is a passive network attack: it eavesdrops on the contents of network communications between browser and server, but does not re-route or modify them.
By contrast, other freely-available tools perform active network attacks, in which the attacker does modify the contents of and/or re-route communications. These tools range from serious, such as sslstrip, to silly, like the Upside-Down-Ternet. Although Upside-Down-Ternet is a funny prank, it is technically identical to potentially more damaging attacks such as an attack that injects malicious code or incorrect information into web pages; at the same time, it shows that such attacks are easy enough to be jokes. Free wifi hotspots have been known to inject advertisements dynamically into web pages that users read—indicating that active network attacks are a viable business model. Tools like Cain and Abel enable a range of attacks, including re-routing local network traffic through the attacker’s system. (Also see Arpspoof and dsniff.)
Only a mechanism that provides (at least) authentication, confidentiality, and integrity can defend against the full range of both passive and active attacks. HTTPS is currently our best option for web applications.
However, there are some potential pitfalls that site operators must avoid.
Mixed Content
When hosting an application over HTTPS, there can be no mixed content; that is, all content in the page must be fetched via HTTPS. It is common to see partial HTTPS support on sites, in which the main pages are fetched via HTTPS but some or all of the media elements, stylesheets, and JavaScript in the page are fetched via HTTP.
This is unsafe because although the main page load is protected against active and passive network attack, none of the other resources are. If a page loads some JavaScript or CSS code via HTTP, an attacker can provide a false, malicious code file and take over the page’s DOM once it loads. Then, the user would be back to a situation of having no security. This is why all mainstream browsers warn users about pages that load mixed content. Nor is it safe to reference images via HTTP: What if the attacker swapped the Save Message and Delete Message icons in a webmail app?
You must serve the entire application domain over HTTPS. Redirect HTTP requests with HTTP 301 or 302 responses to the equivalent HTTPS resource.
Some site operators provide only the login page over HTTPS, on the theory that only the user’s password is sensitive. These sites’ users are vulnerable to passive and active attack.
Security and Cookies
As I described in a paper on secure session management for web applications, site operators must scope sensitive cookies (such as cookies used for user authentication) to the secure origin. If a cookie is broadly scoped (with the Domain attribute in the Set-Cookie: header), it may “leak” to other hosts or applications in the same domain—potentially less-secure hosts or applications.
Similarly, the application must set the Secure attribute on the cookie when setting it. This attribute instructs the browser to send the cookie only over secure (HTTPS) transport, never insecure (HTTP).
Use HTTP Strict Transport Security
HTTP Strict Transport Security (HSTS) is an HTTP protocol extension that enables site operators to instruct browsers to expect the site to use HTTPS.
Although not all browsers yet support HSTS, EFF urges those that don’t—we’re looking especially at you, Apple and Microsoft—to follow the lead Google and Mozilla have set by adopting this useful security mechanism. Indeed, ultimately we expect HTTPS (and possibly SPDY) to replace HTTP entirely, the way SSH replaced Telnet and rsh.
We recently enabled HSTS for eff.org. It took less than an hour to set up, and we found a way to do it without forcibly redirecting users to HTTPS, so we can state an unequivocal preference for HTTPS access while still making the site available in HTTP. It worked like a charm and a significant fraction of our users are now automatically accessing our site in HTTPS, perhaps without even knowing it.
Performance Concerns
Many site operators report that they can’t move to HTTPS for performance reasons. However, most people who say this have not actually measured any performance loss, may not have measured performance at all, and have not profiled and optimized their site’s behavior. Usually, sites have latency far higher and/or throughput far lower than necessary even when hosting over HTTP—indicating HTTPS is not the problem.
The crux of the performance problem is usually at the content layer, and also often at the database layer. Web applications are fundamentally I/O-bound, after all. Consider this wisdom from the Gmail developers:
First, we listed every transaction between the web browser and Google’s servers, starting with the moment the “Sign in” button is pressed. To do this, we used a lot of different web development tools, like Httpwatch, WireShark, and Fiddler, plus our own performance measuring systems. […]
We spent hours poring over these traces to see exactly what was happening between the browser and Gmail during the sign-in sequence, and we found that there were between fourteen and twenty-four HTTP requests required to load an inbox and display it. To put these numbers in perspective, a popular network news site’s home page required about a 180 requests to fully load when I checked it yesterday. But when we examined our requests, we realized that we could do better. We decided to attack the problem from several directions at once: reduce the number of overall requests, make more of the requests cacheable by the browser, and reduce the overhead of each request.
We made good progress on every front. We reduced the weight of each request itself by eliminating or narrowing the scope of some of our cookies. We made sure that all our images were cacheable by the browser, and we consolidated small icon images into single meta-images, a technique known as spriting. We combined several requests into a single combined request and response. The result is that it now takes as few as four requests from the click of the “Sign in” button to the display of your inbox.
Google’s Adam Langley provides additional detail:
In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. [emphasis in original]
Is it any wonder Gmail performs well, even when using HTTPS exclusively? Site operators can realize incremental improvement by gradually tuning their web applications. I gave a presentation to this effect at Web 2.0 Expo 2009.
Conclusion
HTTPS provides the baseline of safety for web application users, and there is no performance- or cost-based reason to stick with HTTP. Web application providers undermine their business models when, by continuing to use HTTP, they enable a wide range of attackers anywhere on the internet to compromise users’ information.
More to Come
Keep an eye out for Part Two of this whitepaper, which will go into more detail about how site operators can easily and incrementally improve site efficiency, thus enabling the move to HTTPS.
No comments:
Post a Comment