Web Security Context: Experience, Indicators, and Trust

3.1 Conformance Model

This section is normative.

Normative material in this specification is marked explicitly.

This specification defines (a) requirements for user interactions and interfaces that are exposed by Web user agents and (b) good practices for Web Content. Requirements for both are phrased in terms of the definitions and concepts found under 4 Interaction and content model, and in terms of the definitions and concepts found under 5 Applying TLS to the Web. These sections are normative, and part of compliance requirements.

Sections that specify requirements for products are clearly marked with the class of product that they apply to. Preconditions that conforming products need to fulfill for the requirement to be applicable are identified. In addition to requirements, the specification includes implementation techniques. These are labelled as NECESSARY (a technique MUST be implemented in order for a product to conform with the requirement) or SUFFICIENT (a technique MAY be implemented, and implementation leads to conformance).

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

3.2 Conformance Labels

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.

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, and 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

The definitions in this section are normative. The examples are informational.

[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 Using TLS to secure HTTP transactions

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 URL is dereferenced are subsumed under this term.

[Definition: (normative) An HTTP transaction is TLS-desired if the resource is identified through a URL with the https URI scheme.]

[Definition: (normative) An HTTP transaction is TLS-protected if an upgrade according to [RFC2817] is performed successfully, or if the resource was identified through a URL with the https URI scheme, the TLS handshake is finished successfully, and the HTTP transactions have occured through the TLS channel.]

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

[Definition: (normative) An HTTP transaction is strongly TLS-protected if it is TLS-protected, an https URL was used, and the following conditions are true:]

1. the server used a trusted certificate that matches the dereferenced URI
2. strong TLS algorithms were negotiated for both confidentiality and integrity protection.

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.

[Definition: (normative) Strong TLS algorithms are defined as the algorithms recommended by [ref-ALGORITHMS].]

[Definition: (normative) 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. cryptographic material was exchanged through an anonymous key exchange algorithm such as DH_anon
2. the cryptographic algorithms negotiated are not considered strong
3. certificates were shown which are not attested, and not trusted for the destination of the transaction

Note that a situation in which an attested certificate is shown, and path validation fails, does not lead to a weakly TLS-protected interaction.

5.2 Relaxed Certificate Path Validation

This section is normative.

Basic Path Validation (section 6 of [RFC3280] ) verifies the binding between the subject distinguished name and/or alternative name, and the subject public key, based on a path of certificates that leads to a trust anchor. As part of Basic Path Validation, Basic Certificate Processing is performed. This processing includes a verification of certificate status at the current time. Status verification is often not performed by Web user agents.

This specification defines a Relaxed Path Validation algorithm. [Definition: Relaxed Path Validation ] differs from Basic Path Validation in its handling of certificate validity and status; specifically:

1. Instead of performing step (a) (2) of Basic Certificate Processing (section 6.1.3 of [RFC3280]; verification of validity date), the Web user agent verifies that the intersection of the validity period of all certificates in the path (including the entity certificate and trust anchor) is non-empty. If this intersection is empty, relaxed path validation fails.
2. Step (a) (3) (status verification) is skipped.

Note that this variant of Basic Path Validation does not require a real time source.

5.3 Certificates

Web user agents can derive trust in the validity of identity certificates that are presented by Web servers from various sources, including user action, previous interactions, and attestation from trusted Certification Authorities by way of a valid certificate chain [RFC3280].

The practices used by Certification Authorities (and the information attested to) vary by CA. Whether a Certification Authority's root certificate is installed as a trust anchor is a decision typically made by Web user agent vendors and systems administrators, based on out-of-band information.

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.4 Using TLS to secure Web Content

This section is normative.

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

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 tansactions in order for the overall page to be considered TLS-secured.

5.5 Change of security level

This section and its subsections are normative. Examples are informational.

[Definition: A change of security level occurs when actual interactions do not match expectations established by user context, interaction history, or user agent state.] This section elaborates on the conditions under which such changes should be considered to have occured.

Implementations MAY assume that a change of security level has occured for reasons not covered in this specification.

6.1 Identity and Trust Anchor Signalling

This section specifies practices for signalling 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

This section is normative.

Web user agents MUST provide additional security context information as described in this section through one or more user-accessible information sources. These information sources can be implemented in either primary or secondary user interface. Where security context information is provided in both primary and secondary chrome, the presentation and semantics of the presented information MUST be consistent.

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 identity information is trusted, e.g., the fact that a certificate is qualified to attest identity information.

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

1. Whether a Web page is TLS-protected, whether the protection is weak or strong, and the reasons for the value of the protection.
2. When the Web page is TLS-protected and an attested certificate was used, whether or not a certificate status check has been performed.
3. If a certificate status check has been performed, what the result was.
4. Whether the user has visited the site in the past.
5. Whether the user has shown credentials to this site.
6. Whether the user has stored credentials for this site.
7. Whether the site content was encrypted in transmission.
8. Whether the site content was authenticated.
9. For user agents capable of displaying graphical material, any logotypes present in logotype extensions present on augmented assurance certificates.

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

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 Page Security Score

The user agent MUST reduce the state of all security context information made available to a single value. A partial order MUST be defined on the set of possible values.

The user agent MUST make the security context information value available to the end user, in either primary or secondary chrome.

The user agent MUST make the formula by which the value is calculated available to the end user. Documentation of the user agent is the likeliest place.

The form of the indicator of this value will depend on the user agent and end user abilities. The user agent SHOULD provide a a primary chrome indicator.

6.4 Error handling and signalling

Web agents regularly encounter error conditions during TLS interaction that alter the risk profile and security context of a particular resource. Due to the highly technical nature of these errors, the details are generally useful only to advanced users. For the majority of web users the technical details actually lead to confusion and risky behavior. For most users the overall security context should be adjusted intuitively while hiding the details of the error condition.

This section specifies error handling and signalling requirements for situations in which the use of TLS protection was desired, but could not be achieved. The basic approach of this section is to minimize user interaction.

7.1 Associating a history with a web site

The safe form editor keeps a history of text strings the user has given to a Web site via a special purpose text entry tool.

This section specifies the algorithm the user agent MUST use to determine if a visited web site should be considered the same as one in the history database. This algorithm is based solely on a comparison of information provided by X.509 certificate chains. Let the currently visited web site be SiteA, a candidate match in the stored editor bar history be SiteB. For each certificate chain received from SiteB, attempt a match against the one received from SiteA using the following checks:

1. If both SiteA's and SiteB's certificates are currently valid and they specify the same public key, there is a match; otherwise, continue with the matching algorithm.
2. If SiteA's certificate was issued by a different certificate authority than SiteB's certificate, there is no match; otherwise, continue with the matching algorithm. Two certificate authorities are considered the same if their certificates are identical, or if they are both installed as trusted certificate chain roots identified by the same name in the user agent's presentation to the user.
3. If both SiteA's and SiteB's certificates have the same value for the Subject field's Common Name (CN) attribute, there is a match; otherwise, continue with the matching algorithm.
4. If both SiteA's and SiteB's certificates have the same values for all of the "O", "L", "ST" and "C" attributes of the Subject field, there is a match; otherwise, continue with the matching algorithm.
5. The algorithm ends here with no match.

The user agent MUST retain sufficient information about all the certificate chains used by a web site to find a match in all cases where the above algorithm indicates there is a match.

The first check in the matching algorithm, which compares public keys, provides a means to transparently update the certificate authority used by a web site. To change certificate authorities, a site acquires a certificate for its existing public key from the new certificate authority. The site should continue using its existing public key until its user base has received the new certificate chain through visits to the site.

Both the first check in the matching algorithm and the second to last, which compares the "CN" attributes of the certificates' subject fields, provide a means to transparently update an organization's name and address. To change this certificate information, an organization acquires a certificate chain that specifies the updated information, but matches against one of these earlier checks.

It is common for an organization to use multiple, unrelated domain names. The final check in the matching algorithm enables sharing of history across all the hostnames used by an organization.

7.2 No support for non-TLS data exchange

The editor bar supports safe entry of text strings by the user into a web site with which a continuous relationship has been established. The user can expect this continuity to be securely enforced and the transmissions protected from eavesdropping and tampering. Currently, these properties can only be supported on the web through the use of TLS. The editor bar MUST NOT be enabled for exchanges that are not protected by TLS. If the user hits the editor bar attention key when visiting a site not protected by SSL, the user agent MUST present a message warning the user that data entered in the current form may be seen, or tampered with, by attackers. The user agent MUST offer an interaction to attempt navigating to a secure version of the current page. Exercising that interaction MUST navigate the browser to a URL constructed by changing the current page's URL scheme to a corresponding one that uses TLS. For example, an http: URL is converted to an https: URL.

7.3 Creating a new relationship

When visiting a web site, the user summons the editor bar via an attention key, or a toolbar button, or in some other way. In response to this request, the editor bar searches its history database for an entry corresponding to the current web site, using the algorithm specified in 7.1 Associating a history with a web site. If no match is found, the text entry tool MUST NOT be enabled. Instead, the user agent MUST present a message that indicates that the user has not transmitted sensitive data to this site before. Along with this message, the user agent MUST offer distinct interactions through which (a) the user can review sites that they have transmitted sensitive data to before, and (b) the user can proceed to establish a relationship with the site they are visiting.

If the user choses interaction (a), a list of hyperlinks to web sites in the editor bar's history database MUST be provided.

If the user choses interaction (b), the user agent must provide a message which communicates identity information based on the TLS certificate used consistent with 6.1 Identity and Trust Anchor Signalling. The user agent MUST offer distinct interactions through which (aa) the user can navigate to a known preferred search engine, and (bb) the user can enter a "petname" for the site they are interacting with.

If the user choses interaction (aa), the user agent MUST navigate to the user's preferred search engine.

If the user selects the second option, the user agent MUST search the database of existing relationships to find any name similar to the newly chosen one. If any matches are found, the user is notified of the collisions and given the opportunity to instead navigate to the corresponding web site. If no matches are found, the user agent updates its database of stored relationships and enables the text entry tool.

For user agents with a visual user interface, all user interfaces exposed for these interactions SHOULD visually replace the Web content currently displayed to the user.

7.4 Reliable Text

To defend against web site impersonation, the editor bar is designed to only display text strings provided by the user, or statically provided by the user agent software. Implementations MUST NOT display a text string, or graphic, from any other source within the editor bar user interface. The quoted text in the bootstrap message, the part of the message after "belongs to", MUST be distinguished from the rest of the static text. If the described certificate chain was not issued by one of the user-agent's installed and trusted certificate authorities, the message MUST NOT quote any information from the certificate, instead presenting a message meaning: "This web site's credentials are unrecognized". The same two user actions are still offered by the rest of the message.

The name chosen by the user at the end of the bootstrap interaction, called a [Definition: petname], MUST be the only identifier used by the editor bar user interface to refer to the named site. Each hyperlink in the list provided when the user selects the first option in the first message of the bootstrap interaction MUST use the petname as the hypertext. This list MUST also be accessible to the user via a "Contacts" option. The petname for the current web site MUST also be presented alongside the text entry tool. The user agent MUST provide a means for the user to update the petname used for a web site.

7.5 Selection of a text string

The text entry tool supports user entry of a new text string, or auto-completion of a previously entered text string. The editor MUST provide an indication of which of the two actions is being taken. The text field MUST NOT provide auto-completion of stored editor bar text strings that have not been previously submitted to the currently displayed web site.

The text entry tool history menu supports user selection of a previously entered text string. The menu MUST indicate whether or not an offered selection has been previously submitted to the currently displayed web site. Further, the user action to select a text string previously submitted to the current site MUST be different from that to select a text string previously submitted to some other site. For example, text strings previously submitted to the current site could be displayed in a main menu and other text strings displayed in a sub menu. Consequently, the user would have to click more than once to select a string not previously submitted to the current site, but only once for a string that has been previously submitted.

Both of these selection mechanisms purposely require explicit action by the user. Transmission of a text string in a particular request represents user consent for use of that text string for the purpose of that request. The user agent MUST NOT subvert this consent by auto-filling form fields with information taken from the editor bar history. Information MUST NOT be transferred from the history database to the web page, except as a result of an explicit approval action by the user.

The editor bar specified in this chapter MUST be the only form filling feature of the user agent. A competing form filling feature would undermine the security features of the interaction created by the editor bar.

7.6 On screen masking of a text string

Some text strings, such as some passwords, are of such high value that displaying them within the user agent, where they may be seen by an onlooker, is too great a risk. This sub-section specifies a mechanism for marking a text string as one which should not be displayed by the user agent.

The text entry tool history menu MUST provide a means for the user to mark a text string as one which is not to be displayed on screen. Invoking this command prompts the user for a "display name". Wherever a text string would be displayed by the editor bar, the provided display name MUST be shown in its place, as well as an indication that the displayed text is a display name, rather than an actual text string. The auto-completion feature of the text entry tool MUST match keystrokes against the display name, instead of the named text string. Whatever way a display name is selected, the named text string MUST be form filled, not the display name text.

7.7 Editing the stored history

Each change to the editor bar history MUST be explicitly made by the user. In particular, a visited web site MUST NOT be able to add, delete, modify or read the editor bar history. A visited web site MUST NOT be able to receive keystrokes sent to the editor bar by the user.

Some identifiers change over time. For example, a credit card number may change when the card is re-issued. The editor bar SHOULD provide a means to delete a text string. Using this feature, the user can reduce interface clutter created by a text string that is no longer in use.

Under some circumstances, a relationship between the editor bar and a site may need to be terminated. The editor bar MUST provide a means for a user to mark a site as one which will no longer be recognized. When this command is invoked, the editor bar MUST behave as if the relationship never existed, for all scenarios specified by this specification.

7.8 Picture-in-picture defense

Many graphical user agents are vulnerable to picture-in-picture attacks. In these user agents, the editor bar MUST be displayed using a theme customized to the user. The user selects this theme at browser installation time and it remains forever the same. The icon for the Contacts button MUST also be selected by the user at installation time.

7.9 Detecting a possible Man-In-The-Middle attack

If the user navigates to a web site by selecting a hyperlink provided by the Contacts button in the editor bar and the site presents a certificate chain that can not be matched to one of its previously stored certificate chains according to the algorithm in 7.1 Associating a history with a web site, the user agent MUST alert the user that credentials were provided which cannot be securely matched to those that had been seen in the past.

User agents SHOULD provide the option to send a notification to an alert service of the user agent's choosing.

8.1 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 desktop browsers 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.

This section includes requirements and techniques to avoid mixing of Web content and security indicators, including -- but not limited to -- the favorite icon case.

8.2 Establishing a trusted path between users and browsers

8.3 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 properly constrained to prevent malicious sites from concealing or obscuring important elements of the browser interface, or deceiving the user into performing dangerous acts. This section includes requirements and techniques to address known attacks of this kind.

9.1 Do not put Security Indicator images to indicate trust in content

This specification requires that web pages MUST NOT include trust indicating images such as padlocks in the web content.

9.2 Use TLS for Login Pages

An unsecure web page MUST NOT embed a form meant for the user to login. All login pages MUST be served from secure servers ie. login pages must be TLS protected. An unsecure page MAY carry a link for the user to click to be taken to a secure page to enter login information. This link MUST NOT carry a padlock along with it.

9.3 Use TLS Consistently across the web site

If a web site requires secure login, then all sensitive transactions and presentation based on the user's credentials, as well as the service provided credential token itself MUST be protected by the same level of security. Cookies on unsecure connections are vulnerable to interception, and can be used for replay attacks even if they were set by a secure server, and servers MUST NOT set credential cookies from secure servers that can be sent unencrypted.

9.4 Redirects from Non-Secure to Secure page and vice-versa

Web Sites that require their users to be redirected from an unsecure web page to a secure web page MUST do it as a single step rather than multi-step (redirect to an unsecure page and then redirect again to a secure page). This specification recommends that the web page MUST use direct links to a secure page rather than using redirects.

10.1 Framework

This section is normative.

Web user agents that implement optional features of this specification MUST support the configuration of different [Definition: usage modes ] which determine which of thse optional features are active. A usage mode MAY cover other configuration settings of a Web user agent. A user agent SHOULD allow users to view details of why a request to perform a Web transaction was denied if this decision was based on the currently-active usage mode.

10.2 Safe Browsing Mode

Web user agents SHOULD support a [Definition: Safe Browsing Mode ] as one usage mode. Users SHOULD NOT be able to change the settings of this usage mode. This usage mode MUST be made available through an interaction based on a Secure Attention Sequence.

In this usage mode, interactions MUST be limited to a usage-mode specific set of sites.

Web user agents MUST require all Web transactions in this usage mode to be strongly TLS protected. Use of self-signed certificates MUST be considered cause for a change of security level.

The optional technique 6.4.2 Handling certain man in the middle attacks MUST NOT be used.

For Web user agents with a visual user interface, Safe Browsing Mode SHOULD be visually distinguishable from other usage modes.

11.1 Active attacks during initial TLS interactions

6.4 Error handling and signalling leads to an additional exposure during the first TLS interaction with a site, even if that site uses attested or extended validation certificates: An active attacker can show a self-signed certificate, which will cause no warning signals to the user, except for differences in a passive security indicator (see 6.1 Identity and Trust Anchor Signalling ). Traditional web 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 attested certificates are required (causing a change of security level 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.

11.2 Using error handling interactions as vectors for user deception

6.4.2 Handling certain man in the middle attacks relies on the assumption that the information communicated to the user about the site that the user really connects to is reasonably trustworthy, and will not be used to deceive the user. If this assumption is broken, an attacker may be able to deceive users about the fact that a serious attack occured.

11.3 Secure storage of sensitive information

Like the password managers in today's user agents, the editor bar specified in 7 Safe Web Form Editor requires storage of information whose confidentiality must be protected. Implementors should use secure storage techniques that ensure the editor bar's database is only accessed by the user. Specifying appropriate storage techniques is beyond the scope of this recommendation.