GeezerVison

By Chris Palmer and Yan Zhu

Originally published on 15 Nov 2010. Most recent update: 21 Oct 2020.

Internet technologists have always known that HTTP is insecure, causing many risks to users. Because HTTP traffic is unencrypted, any data sent over HTTP can be read and modified by anyone who has access to the network. As revealed by the Snowden NSA surveillance documents, HTTP traffic can also be collected and searched by government agencies without notice to users or webmasters. Given these risks, EFF believes that every website should support HTTPS on all pages as soon as possible.

While HTTPS has long existed as the bare minimum for web security, some websites have been slow to adopt it. In part, this is because correctly and completely serving an application over HTTPS takes some care.

This article is designed to encourage and assist website operators in implementing and improving HTTPS support. Although no precaution will defend against all threats, supporting HTTPS will protect users from a wide range of common attacks.

Background

HTTPS provides three security guarantees:

1. Server authentication allows users 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.
2. Data confidentiality means that eavesdroppers cannot understand the content of the communications between the user's browser and the web server, because the data is encrypted.
3. 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 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 an example of a passive network attack: it eavesdrops on the contents of network communications between browser and server, but does not re-route or modify them. Government surveillance programs such as XKeyscore also use passive attacks on HTTP traffic to collect massive amounts of online communication data.

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 a range of attacks. HTTPS is currently our best option for web applications.

However, there are some potential pitfalls that site operators must avoid in order to deploy HTTPS securely.

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 attacks.

Unfortunately, many sites today load content from external sites and CDN's that do not support HTTPS. If it's not possible to serve these resources from your own host or another one that supports HTTPS, you should urge these other sites to start supporting HTTPS immediately.

Security and Cookies

As Chris Palmer 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. It is supported by all major browsers.

Important note: If you implement HSTS, and then break the HTTPS configuration on your site, browsers will prevent users from clicking through any warning messages. For this reason, we recommend starting with a short max-age on your HSTS header, and gradually increasing it over a couple of weeks, eventually reaching max-age=32000000.

Once you've successfully deployed the HSTS header and are confident with it, you can implement HSTS preloading as an extra precaution. To preload your site for HSTS, make sure it meets all the conditions listed on hstspreload.org, and submit it there. Once accepted, your site will eventually become part of a hardcoded list of sites that ships in the browsers that implement HSTS, so that a given instance of one of those browsers knows to give your site the HSTS treatment even if it hasn't yet visited your site. This prevents attacks that may occur before the first visit to your site.

Choose Strong Protocols and Cipher Suites

Here is a brief list of recommendations for choosing secure protocols and cipher suites in an SSL deployment:

• Disable support for SSLv2, SSLv3, TLS 1.0, and TLS 1.1
• Support TLS 1.2, and 1.3
• Disable NULL, aNULL, and eNULL ciphersuites, which do not offer both encryption and authentication.
• Use private keys that are at least as secure as a 2048-bit RSA key.
• Prefer ciphersuites that include ephemeral Diffie-Hellman key exchange. These offer the important property of Perfect Forward Secrecy, which prevents decryption of past web traffic if your SSL private key is compromised in the future.
• Disable ciphersuites with keys sizes smaller than 128 bits for encryption.
• Disable ciphersuites that use MD5 for hashing. SHA-1 is also discouraged but may be required for compatibility with TLS 1.0 and SSLv3.
• Disable ciphersuites that use RC4 for encryption. AES-CBC is preferable to RC4 but vulnerable to the BEAST attack. Thus, AES-GCM is often recommended.
• Disable TLS compression in order to prevent the CRIME attack.
• Only support secure TLS renegotiations compliant with RFC 5746, or disable TLS renegotiations entirely.

A useful tool for testing for well-known weaknesses in an existing HTTPS deployment is Qualys's SSL Server Test.

Also, check Mozilla's Recommended TLS Configurations and Configuration Generator for help choosing a strong configuration for your needs.

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.