Web Security Context: User Interface Guidelines

3.1 Product classes

This specification addresses Web user agents as a product class. Web user agents and user agents are used synonymously in this specification.

This specification also addresses products that might incorporate changes to a user agents, such as plug-ins, extensions, and others; they are summarily called [Definition: plug-ins] in this section.

Such products that might incorporate changes to the user agent, e.g. through the addition or removal of features, can render an otherwise conforming user agent non conforming, or vice versa.

3.2 Language conventions

Throughout the specification, the RFC 2119 [RFC2119] keywords MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are applied, with their respective meanings.

3.3 Conformance levels

A user agent conforms to this specification at the [Definition: basic level] if it honors all MUST and MUST NOT clauses of this specification.

A user agent conforms to this specification at the [Definition: advanced level] if it also honors all SHOULD and SHOULD NOT clauses of this specification.

Conformance of a plug-in is defined in terms of the conformance of the user agent that results when the plug-in is added to a base user agent. E.g., if a given user agent conforms to this specification on the basic level, and a plug-in adds features that lead to conformance on the advanced level, then this plug-in conforms on the advanced level with respect to this base user agent.

3.4 Conformance claims

A claim about a Web user agent's conformance with this specification must state:

1. Whether basic or advanced conformance is claimed (see 3.3 Conformance levels)
2. What TLS [SSLv3][TLSv11][TLSv12] protocol versions and algorithms are considered as strong TLS algorithms, and what protocol versions and algorithms are supported in TLS negotiation, but not considered strong.
3. What user interface element is the TLS indicator defined in this specification.
4. What user interface element is the identity signal defined in this specification.
5. What broadly accepted practices are considered sufficient for a trust anchor to be deemed augmented assurance qualified (see 5.1.2 Augmented Assurance Certificates), and what data elements are deemed assured by those certificates.
6. What features beyond the claimed conformance level the user agent conforms with.

A claim about a plug-in's conformance with this specification must include all of the above, and also identify the base user agent with respect to which conformance is claimed.

4.1 Overview

This specification assumes a human user interacting with a Web user agent, interacting with Web resources. Many of the requirements specified are focused on the presentation of security context information to the user, and therefore directly relate to user interfaces. Where requirements or techniques are specific to certain modalities, these are made explicit, and are part of the preconditions for applying the requirement or technique.

When this specification speaks of a Web user agent to describe the application through which a user interacts with the Web, then this term is used on a conceptual level: No assumption is made about implementation details; the "Web user agent" may denote a combination of several applications, extensions to such applications, operating system features, and assistive technologies.

A common user agent will therefore be a web browser with some number of plug-ins, extensions, call outs to external systems which render particular document formats, and assistive technologies.

This specification makes no specific assumption about the content with which the user interacts, except for one: There is a top-level Web page that is identified by a URI [RFC3986]. This Web page might be an HTML frameset, an application running on top of a proprietary run-time environment, or a document in a format interpreted by plug-ins or external systems served as part of a Web interaction. The page's behavior might be determined by scripting, stylesheets, or other mechanisms.

Some requirements are expressed in terms of user interface components commonly found in current-generation Web user agents.

4.2 Terms and definitions is expected to be consistent with the Web Content Accessibility Guidelines Version 2, [WCAG20].

4.2 Terms and definitions

[Definition: A Web User Agent is any software that retrieves and presents Web content for users.]

[Definition: A Web Page is a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it.]

5.1 Certificate Handling and Information

Public key certificates (see [PKIX]) are widely used in TLS [SSLv3] [TLSv11] [TLSv12], but have been the basis for the generation of many inappropriate warnings and other dialogs for users. This section describes some modifications to current certificate processing aimed at improving this aspect of handling web security context and defines some new terms describing various cases related to certificate handling in user agents.

User agents can base their acceptance of certificates that are presented by Web servers on various sources, including user action, previous interactions involving the same certificate, or, as more traditionally assumed, on validation of a certificate chain where each certificate is issued by a Certification Authority (CA). The practices used by CAs (and the information attested to) vary by CA and are not available in any useful sense to Web user agents.

5.2 Types of TLS

The most common mechanism for applying TLS to the Web is the use of the https URI scheme [RFC2818]; the alternative upgrade mechanism [RFC2817] is used rarely, if at all. For the purposes of this specification, the most relevant property of [RFC2818] is that the URI used to identify a resource includes an assertion that use of TLS is desired.

This specification uses the term [Definition: HTTP transaction ] regardless of whether any kind of TLS protection was applied; in particular, the transactions arising when an https URI is dereferenced are subsumed under this term. [RFC2616]

[Definition: An HTTP transaction is TLS-protected if an upgrade according to [RFC2817] is performed successfully, or if the resource was identified through a URI with the https URI scheme, the TLS handshake was performed successfully, and the HTTP transaction has occurred through the TLS channel.]

Note that an HTTP transaction may be considered TLS protected even though weak algorithms (including NULL encryption) are negotiated.

[Definition: An HTTP transaction is strongly TLS-protected if it is TLS-protected, an https URI was used, strong TLS algorithms were negotiated for both confidentiality and integrity protection, and one of the following conditions are true:]

1. the server used a validated certificate that matches the dereferenced URI; or
2. the server used a self-signed certificate that was pinned to the destination; or
3. the server used a certificate chain leading to an untrusted root certificate that was pinned to the destination.

TLS modes that do not require the server to show a certificate (such as the DH_anon mode) do not lead to a strongly TLS-protected transaction.

The ability to provide privacy and secure the connection between a user agent and web server is in part determined by the strength and capabilities of the TLS protocol and underlying cryptographic mechanisms. The TLS protocol is versioned to keep pace with protocol features and cipher suites that are available. Cipher suites are grouped according to algorithms and the key length used by cryptographic functions to provide cipher strength.

When this document speaks of [Definition: Strong TLS algorithms], then the following must hold:

1. No version of the TLS protocol that suffers known security flaws has been negotiated. At the point of writing of this document, versions of SSL prior to SSLv3 [SSLv3] MUST NOT be considered strong.
2. A cipher suite has been selected for which key and algorithm strengths correspond to industry practice. At the time of writing of this document, the "export" cipher suites explicitly forbidden in appendix A.5 of [TLSv11] MUST NOT be considered strong.

What set of algorithms is considered as strong by a given implementation must be described in any conformance claim against this specification, see 3.4 Conformance claims.

[Definition: An HTTP transaction is weakly TLS-protected if it is TLS-protected, but strong TLS protection could not be achieved for one of the following reasons:]

1. TLS handshake used an anonymous key exchange algorithm such as DH_anon
2. the cryptographic algorithms negotiated are not considered strong
3. certificates were used that are not either validated certificates, or self-signed certificates pinned to the destination (see 5.1.4 Self-signed Certificates and Untrusted Root Certificates)

Weakly TLS-protected interactions may provide security services such as confidentiality protection against passive attackers, or integrity protection against active attackers (without confidentiality protection). These properties are often desirable, even if strong TLS protection cannot be achieved.

5.3 Mixed Content

If a given Web page consists of a single resource only, then all content that the user interacts with has security properties derived from the HTTP transaction used to retrieve the content.

[Definition: A Web page is called TLS-secured if the top-level resource and all other resources that can affect or control the page's content and presentation have been retrieved through strongly TLS protected HTTP transactions. ]

[Definition: A Web page is called mixed content if the top-level resource was retrieved through a strongly TLS protected HTTP transaction, but some dependent resources were retrieved through weakly protected or unprotected HTTP transactions.]

This definition implies that inline images, stylesheets, script content, and frame content for a secure page need to be retrieved through strongly TLS protected HTTP transactions in order for the overall page to be considered TLS-secured.

Any UI indicator used to signal the presence of Augmented Assurance certificates MUST NOT signal the presence of such a certificate, unless the page is TLS-secured, i.e., all parts of the page are loaded from servers presenting at least a validated certificate, over strongly TLS-protected interactions.

For relevant security considerations, see 8.6 Mixing Augmented Assurance and Validated Certificates.

5.4 Error conditions

6.1 Identity and Trust Anchor Signaling

This section specifies practices for signaling information about the identity of the Web site a user interacts with. All signals specified in this section are passive. No claim is made about the effectiveness of these signals to counter impersonation attacks.

6.2 Additional Security Context Information

Web user agents provide additional security context information as described in this section. Where security context information is provided in both primary and secondary interface, the meaning of the presented information MUST be consistent. Best practice will also avoid inconsistent presentation, such as using identical or semantically similar icons for different information in different places.

The information sources MUST make the following security context information available:

1. the Web page's domain name
2. Owner information, consistent with 6.1.2 Identity Signal Content
3. Verifier information, consistent with 6.1.2 Identity Signal Content
4. The reason why the displayed information is trusted (or not). This includes whether or not a certificate was accepted interactively, whether a self-signed certificate was used, and whether the self-signed certificate was pinned to the site that the user interacts with, and whether trust relevant settings of the user agent were otherwise overridden through user action.

The information sources SHOULD make the following security context information available:

1. An explanation of the information represented by the TLS indicator, e.g., concerning the presence mixed content;
2. If the Web page is weakly TLS-protected, then, what conditions cause the protection to be weak (e.g., bad algorithms, mixed content, ...)
3. Whether the user has visited the site in the past.
4. Whether the user has stored credentials for this site.
5. Whether the site content was encrypted in transmission.
6. Whether the site content was authenticated (e.g., server authentication via TLS).

Additionally, the information sources MAY make the following security context information available:

1. When the user first visited the site in the past.
2. How often the user visited the site in the past.

User agents that provide information about the presence or absence of Cookies [RFC2965] MUST NOT make any claims that suggest that the absence of cookies implies an absence of any user tracking, as there are numerous tracking and session management techniques that do not rely on Cookies.

6.3 TLS indicator

User agents MUST make information about the state of TLS protection available. The [Definition: TLS indicator] MUST be part of primary user interface during usage modes which entail the presence of signaling to the user beyond only presenting page content. As in the case of 6.1.1 Identity Signal, there may be usage modes during which this requirement does not apply. Web content MUST NOT obscure security interface, 7.4.1 Obscuring or disabling Security User Interfaces.

User agents with a visual user interface SHOULD make the TLS indicator available in a consistent visual position.

The TLS indicator MUST present a distinct state that is used only for TLS-secured Web pages. The User Agent SHOULD inform users when they are viewing a page that, along with all dependent resources, was retrieved through at least weakly TLS protected transactions, including mixed content.

The user agent MAY accomplish this by using a third state in the TLS indicator, or via another mechanism (such as a dialog, info bar, or other means).

6.4 Error handling and signaling

This section defines common error interaction requirements and, ordered by increasing severity, practices to signal the following classes of errors:

• 6.4.2 Warning/Caution Messages
• 6.4.3 Danger Messages

User agents MAY communicate additional indicators to users. E.g., a user agent could additionally display a persistent indicator in a "danger" situation.

For additional security considerations concerning frequent warning messages, see 8.5 Warning Fatigue.

7.1 Keep Security Chrome Visible

For visual user agents, agent chrome SHOULD always be present to signal security context information. This requirement does not apply when user interface is explicitly dismissed by the user.

7.2 Do not mix content and security indicators

To the extent to which users pay attention to passive security indicators at all, noticing and understanding them is made difficult to impossible when the same signal path that is commonly used for security indicators can also be controlled by Web content. For example, the location bar commonly found on agents is often used to both display the "padlock" security indicator, and a possible "favorite icon" [FAVICON], which can in turn be a simple copy of the very padlock an informed and attentive user might look for.

Web User Agents MUST NOT communicate trust information using user interface elements which can be mimicked within chrome under the control of web content. Site-controlled content (e.g. page title, favicon) MAY be hosted in chrome, but this content MUST NOT be displayed in a manner that confuses hosted content and chrome indicators, by allowing that content to mimic chrome indicators in a position close to them. This requirement applies to both primary and secondary elements of visual user interfaces.

In particular, Web User Agents SHOULD NOT use a 16x16 image in chrome to indicate security status if doing so would allow the favorite icon to mimic it.

7.3 Managing User Attention

When confronted with multiple modal interactions during a short amount of time, users are known to exercise the default option (e.g., by pressing the Enter key repeatedly) until the sequence of modal interactions stops blocking the user's intended interaction.

[Definition: An Interaction flooding attack refers to a Web site with the malicious intent of performing an unintended action (e.g. installing software that would have required an user intervention such as clicking OK on a warning dialog) or by exploiting distraction and task-focus. The Web site opens a large number of new windows over the desired web content and the malicious action is performed when the user tries to close these new windows and/or clicks on a dialog that indicates a trust decision. ]

User interfaces used to inform users about security critical events or to solicit input MUST employ techniques that prevent immediate dismissal of the user interface, e.g., by using a temporarily disabled "OK" button on user interfaces that make such an interaction paradigm available. When users interact with security relevant notifications (6.4.2 Warning/Caution Messages and above), interactions caused by Web content MUST NOT be granted control of the user agent's interaction.

A Web User Agent SHOULD NOT display a modal security dialog related to a web page which does not currently have focus. Security dialogs include prompts for user credentials, script errors and TLS errors.

7.4 APIs Exposed To Web Content

User agents commonly allow web content to perform certain manipulations of agent UI and functionality such as opening new windows, resizing existing windows, etc. to permit customization of the user experience. These manipulations need to be constrained to prevent malicious sites from concealing or obscuring important elements of the agent interface, or deceiving the user into performing dangerous acts. This section includes requirements and techniques to address known attacks of this kind.

8.1 Active attacks during initial TLS interactions

5.4.1 TLS errors leads to an additional exposure during the first TLS interaction with a site, even if that site uses validated or extended validation certificates: An active attacker can show a self-signed certificate, which will cause only weak warning signals to the user. Traditional user agents react to this scenario with a dialogue box that interrupts the user's flow of interaction, but gives users the ability to override the security warning. Empirical evidence shows that this ability is typically exercised by users.

Countermeasures against this threat include the prior designation of high-value sites, for which extended validation or validated certificates are required (causing a stronger warning signal during the attack scenario described above), and communication of certification and TLS expectations by a mechanism separate from HTTP, e.g. through authenticated DNS records.

5.4.1 TLS errors refers to the pinning of a new certificate to a destination. Note that this newly pinned certificate could be the basis for a spoofing attack, or it could represent a refresh of an Self Signed Certificate.

8.2 Certificate Status Checking Failures

The TLS Errors (5.4.1 TLS errors) section does not document intended behaviour for user agents when a certificate status check fails for network or other non-revocation reasons. At time of writing, the deployment environment for OCSP [RFC2560] status checking is fragile and subject to frequent failures, so it is inappropriate to require user agents to treat such failures as warnings or errors. However, this creates a possibility for attack: site operators using a fraudulently obtained, and revoked, certificate may attempt to attack a CA's revocation infrastructure as a way to suppress revocation errors. User agent countermeasures for this vulnerability include: exposing failures of certificate validation checks to users as warning (6.4.2 Warning/Caution Messages ) or danger (6.4.3 Danger Messages) level messages; or refusal to load sites that fail these checks.

8.3 Certificates assure identity, not security

While TLS certificates of all types (i.e. self-signed, validated, or augmented assurance) provide the means for strong encryption of communications, they should not be understood to be, or treated as, blanket security assurances. In particular, validated and augmented assurance certificates make guarantees about some level of owner identity verification having been performed (see definitions) but they do not represent any guarantees that a site is operated in a safe manner, or is not otherwise subject to attack. Historically, issues of security and identity have been conflated by user agent interfaces which present SSL/TLS connections as "secure," but implementers of this specification are advised to be cautious and cognizant of this distinction.

8.4 Binding "human readable" names to domain names

Several recommendations in this document concern themselves with the binding between domain names and certificates, but equally important for users is the binding between domain name/certificate and the actual real-world entity involved in the transaction. It is helpful, for example, to know not only that example.com presents a valid certificate, but also that it is the "Example Inc., Norway" with whom the user expects to be interacting. In the case of augmented assurance certificates, the identity information provided may be considered sufficient for this purpose, but other validated certificates do not necessarily provide this real-world identity. User agents that wish to provide a mechanism for users to manually establish these linkages are advised to consider the petnames approach (see [PETNAMES]).

8.5 Warning Fatigue

Requirements in this document often involve warning (6.4.2 Warning/Caution Messages and 6.4.3 Danger Messages) messages when warranted by conditions in the user agent. However, it is important to be aware, when developing user interfaces, that users will habituate to over-frequent warnings, weakening the impact of the messages and their ability to effectively interrupt the user's task flow.

User agents are advised to constrain the number of warnings and errors presented to the minimum required to satisfy these and other security guidelines. It is also recommended that user agents phrase options in these messages in terms of the action taken (e.g. "Ignore this warning," "Trust this site") rather than using generic labels (e.g. "OK", "Cancel").

8.6 Mixing Augmented Assurance and Validated Certificates

The Augmented Assurance indicator tells the user that the owner and author of the Web page being displayed can be identified using information from the associated augmented assurance certificate. Identity signals in this specification only directly address displaying the identity of the party responsible for the top level resource in a Web page. User agents may choose to make the identities of other resources that can affect or control the page's content available, but we do not put forward a model for users on how they might use such information in their trust decisions.

The identity of the top level resource vouches for the content of all dependent resources. What resources these are is under the control of the top-level resource, which will typically identify these resources using URIs with domain based authority. Therefore, this specification requires that, in order to display any augmented assurance related indicators, dependent resources must all be strongly TLS protected using validated certificates.

If an augmented assurance page includes content from other strongly TLS-protected resources that are not identified by augmented assurance certificates, the authors for these third party parts of the document cannot be identified to the same extent as for the main document. Given that certain types of content, for example external scripts and styling can change the containing document's entire appearance, and framed content and plug-ins can be where the user's main interaction occurs, the user's real interaction may be with content under the control of a completely different party than the one identified by the main document's augmented assurance certificate.

Using third party content also makes the main document reliant upon the security of the third party contributor, and expands the available attack surface of the service, thus giving attackers several more lines of attack.

Under the agent's Same Origin policy, separately displayed Web pages from the same origin can freely read and modify each other's state. A Web page's origin is comprised of the scheme, host and port of the URI used to retrieve the Web page. The origin does not take into account any attributes of the TLS session or server certificate used when retrieving a Web page. For example, consider a user agent that has loaded two Web pages from "https://www.example.com/". When the first page was retrieved, an Augmented Assurance Certificate was used by the TLS session. When the second page was retrieved, a different certificate, such as a domain validated or self-signed certificate, was used. Though the first page was retrieved using an augmented assurance certificate, the second page can freely read and write the first page. Differing security presentations of the two pages may obscure this relationship in the mind of the user.

8.7 Dynamic content might change security properties

This specification is expressed in terms of the fundamentally static indicators of existing agent security user interfaces.

These indicators tend to assume that the security properties "of a page" will not change in a significant way once it has finished loading (whatever that might mean in detail). Strictly speaking, this assumption is flawed: Dynamic pages can load scripts and data at any time and from any source (using techniques like the insertion of script tags into the DOM at run time); the effect may very well be that a page that was retrieved from a secure Web site with an Augmented Assurance certificate could at some point be under the control of scripts that are retrieved insecurely. This specification does not prescribe any specific user interaction in this kind of situation.

For HTTPS requests caused using the XMLHttpRequest API [XHR] [XHR2], this specification permits either handling the error situation described above as a network error (and leaving behavior to the Web application in question) or causing a user interaction. It is expected that upcoming specifications for the XMLHttpRequest API will opt for the former choice.