This finding documents the TAG’s position on securing the Web through the use of cryptography, identifies some of the associated issues, and recommends further work to aid in its use.
Its primary audience is W3C participants.
This document has been produced by the W3C Technical Architecture Group (TAG). The TAG approved this finding at its 22 January 2015 teleconference. Additional TAG findings, both accepted and in draft state, may also be available. The TAG may incorporate this and other findings into future versions of the [[webarch]]. Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org (archive).
Over the last 25 years, the Web has grown into a platform for much of the world’s communication, whether it be information sharing, community building, commerce, education, social networking, or underpinning applications.
In meeting these needs, the Web’s trustworthiness has become critical to its success. If a person cannot trust that they are communicating with the party they intend, they can’t use the Web to shop safely; if they cannot be assured that Web-delivered news isn’t modified in transit, they won’t trust it as much. If someone cannot be assured that they’re talking only to the intended recipients, they might avoid social networking.
These important properties of authentication, integrity and increased confidentiality are currently best provided on the Web by Transport Layer Security (TLS) [[RFC5246]]. For the HTTP protocol, this means using "https://" URLs [[RFC7230]].
In the past, Web sites have deployed HTTPS rarely; often, only when financial transactions take place. More recently, however, it has become apparent that nearly all activity on the Web can be considered sensitive, since it now plays such a central role in everyday life.
At the same time, security on the Web has proven to be quite subtle. If an attacker can modify content in transit, the power of the Web platform we are defining can easily be turned against the user (or the site they are using).
For example, networks can (and some do) insert advertisements into unencrypted Web pages; by nature, this conveys the ability to track users. Even more hostile attacks include inserting persistent code into the browser that is run on subsequent visits ("cache poisoning"), or changing content (such as editing a company's Web site to affect its stock price).
An attacker can also access information that might have been stored by a site in previous visits. If this includes a persistent grant of access to a privileged APIs, such as geolocation [[geolocation-API]] or media capture [[media-capture-api]], then the attacker can access those resources using any prior authorization.
Notably, these risks are just as present for users of "plain" Web sites as they are for those using more sophisticated, interactive sites.
Also, if confidentiality is lost, something as simple as an image request "in the clear" (i.e., unencrypted) can give an attacker information about what the user is doing, opening an opportunity for further attacks -- again, even if the content being accessed seems innocuous.
Finally, widespread attacks like Pervasive Monitoring [[RFC7258]] further erode users' trust in the Web -- whether they be activists, businesses or ordinary citizens.
This leads us to a conclusion that server authentication and integrity are baseline requirements for the continued success of the Web. Furthermore, confidentiality -- while arguably not always strictly necessary -- is often needed. Since the necessity of confidentiality may only become apparent in hindsight, we should also consider it as being crucial to the continued success of the Web.
Therefore, the TAG finds that:
Within the W3C, there are a number of potential areas to both mitigate issues encountered in transitioning to and using encryption, as well as ways to encourage its use. This includes (but is not limited to):
Many new Web platform features offer increased capabilities, access to data and richer functionality. Some of these "powerful" features also have significant security and privacy implications, and Working Groups should consider whether they ought only be used over an encrypted connection. The Web Applications Security Working Group (WebAppSec) has begun work on [[powerful-features]] to document best practices in this area.
Existing specifications that change behavior based upon the URL scheme ("http://" vs. "https://") should be examined to see if these differences can either be eliminated or controlled by authors, provided that there is no loss of security or surprising changes in behavior. For example, the [[referrer-policy]] specification is offering more control over the Referer HTTP header, as part of [[CSP2]].
Updating sites from "http://" to "https://" necessitates changing links to resources, which is counter to the good practice of "avoiding URI aliases" [[webarch]]. To mitigate such changes, Working Groups (in particular, those dealing with Linked Data) should consider how redirects (like 301 Moved Permanently) and Strict Transport Security [[RFC6797]] can be used to assert that a "http://" origin has been replaced by an "https://" one.
When transitioning from "http://" to "https://", applications that depend upon third-party resources ("mashups") that have not yet changed to "https://" themselves can experience difficulties, because of the Mixed Content policy [[mixed-content]]. We encourage WebAppSec to examine this problem.
Adopting "https://" has the side effect of disallowing shared HTTP caching [[RFC7234]]. Shared caching has a limited role on the Web today; many high traffic sites either discourage caching with metadata, or disallow it by already using "https://". However, shared caching is still considered desirable by some (e.g., in limited networks); in some cases, it might be so desirable that networks require users to accept TLS Man-in-the-Middle -- which is a bad outcome for Web security overall. Therefore, we encourage exploration of alternative mechanisms that preserve security more robustly, such as certain uses of Subresource Integrity [[SRI]].
Similarly, adopting "https://" makes the practice of imposing policy in intermediaries (e.g., in schools and workplaces, by parents, in prisons) more difficult. While TLS Man-in-the-Middle is one solution to this, it is a blunt one, sacrificing substantial security when they are used. Therefore, we encourage development of facilities to enable imposition of policy -- when it is necessary -- in a more controlled way, e.g., as new APIs for Web browser extensions.
Changing to "https://" is often difficult, for a variety of reasons. We encourage development of documentation to aid Web content creators, administrators and implementers in this process. In particular, since W3C has expertise in the implications upon content creators, our documentation should focus on this audience.
Educating and interacting with users regarding security is notoriously difficult. Even so, we encourage the implementer community to continuously challenge their assumptions in this space; for example, there is currently a discussion changing how "http://" URLs are presented so that they are marked insecure, or even defaulting to "https://" when a URL reference without a scheme is input. Where appropriate, we also encourage these discussions to take place in W3C fora.
To facilitate this finding, the TAG encourages continuing improvement of both TLS and its use in Web protocols, while acknowledging that some of this work may not be best suited for the W3C. In particular:
Transitioning Web sites to "https://" URLs often brings up concerns that aren't covered in the issues discussed above, including:
Cryptography will not solve all security problems in the Web platform, both because it does not address many types of attack, and because TLS itself has been shown to have flaws in the past (and presumably will again). However, it does serve as an important and necessary baseline for further improvements to security. This is especially true as the platform becomes more powerful, and thus more dangerous to use “in the clear”.
The CPU overhead of TLS has largely been overcome by advances in processor technology; modern CPUs are much faster, use less power, and often have specialized chips for accelerating cryptography. As a result, many sites report that encryption overhead is manageable, or even "in the noise." However, note that some specialized techniques for very high performance servers (such as sendfile() and TCP Splice) are unavailable when using TLS.
Historically, the perceived performance of HTTPS has been worse than that of cleartext HTTP, because of the extra round trips that the handshake and certificate validation require. However, recent developments such as OCSP Stapling [[RFC6961]] and TLS session tickets [[RFC5077]] have reduced this overhead to the point where the deficit is minor -- often, imperceptible (see Is TLS Fast Yet? for details). We expect that future developments (such as TLS/1.3) will further reduce the performance penalty of encryption.
This finding builds upon and explicitly acknowledges the Internet Architecture Board’s Statement on Internet Confidentiality, the STRINT Workshop, and the Chromium Security Team’s “Prefer Secure Origins For Powerful New Features”.