You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2626 lines
118 KiB
2626 lines
118 KiB
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 15.3), see www.w3.org" />
|
|
<meta http-equiv="Content-Type" content=
|
|
"text/html; charset=utf-8" />
|
|
|
|
<title>Web Security Context: User Interface Guidelines</title>
|
|
<link rel="home" title="Top" href="#title" />
|
|
<link rel="chapter" title="Abstract" href="#abstract" />
|
|
<link rel="chapter" title="Status of this Document" href=
|
|
"#status" />
|
|
<link rel="contents" title="Table of Contents" href=
|
|
"#contents" />
|
|
<link rel="chapter" title="1 Overview" href="#Overview" />
|
|
<link rel="chapter" title="2 Acknowledgments" href="#thanks" />
|
|
<link rel="chapter" title="3 Conformance" href="#Conformance" />
|
|
<link rel="section" title="3.1 Product classes" href=
|
|
"#conformance-products" />
|
|
<link rel="bookmark" title="def-plug-in" href="#def-plug-in" />
|
|
<link rel="section" title="3.2 Language conventions" href=
|
|
"#conformance-language" />
|
|
<link rel="section" title="3.3 Conformance levels" href=
|
|
"#conformance-levels" />
|
|
<link rel="bookmark" title="conformance-basic" href=
|
|
"#conformance-basic" />
|
|
<link rel="bookmark" title="conformance-advanced" href=
|
|
"#conformance-advanced" />
|
|
<link rel="section" title="3.4 Conformance claims" href=
|
|
"#conformance-claims" />
|
|
<link rel="chapter" title="4 Interaction and content model"
|
|
href="#concepts" />
|
|
<link rel="section" title="4.1 Overview" href=
|
|
"#interaction-overview" />
|
|
<link rel="section" title="4.2 Terms and definitions" href=
|
|
"#definitions" />
|
|
<link rel="bookmark" title="def-user-agent" href=
|
|
"#def-user-agent" />
|
|
<link rel="bookmark" title="def-page" href="#def-page" />
|
|
<link rel="subsection" title=
|
|
"4.2.1 Common User Interface elements" href="#common-widgets" />
|
|
<link rel="bookmark" title="def-primary-chrome" href=
|
|
"#def-primary-chrome" />
|
|
<link rel="bookmark" title="def-secondary-chrome" href=
|
|
"#def-secondary-chrome" />
|
|
<link rel="bookmark" title="def-chrome" href="#def-chrome" />
|
|
<link rel="bookmark" title="def-locationbar" href=
|
|
"#def-locationbar" />
|
|
<link rel="bookmark" title="def-identity-information" href=
|
|
"#def-identity-information" />
|
|
<link rel="chapter" title="5 Applying TLS to the Web" href=
|
|
"#tlsforweb" />
|
|
<link rel="section" title=
|
|
"5.1 Certificate Handling and Information" href=
|
|
"#tlstosecurehttp" />
|
|
<link rel="subsection" title=
|
|
"5.1.1 Interactively accepting trust anchors or certificates"
|
|
href="#sec-interactively" />
|
|
<link rel="bookmark" title="def-interactively" href=
|
|
"#def-interactively" />
|
|
<link rel="subsection" title=
|
|
"5.1.2 Augmented Assurance Certificates" href="#sec-evcert" />
|
|
<link rel="bookmark" title="def-augmented-assurance-cert" href=
|
|
"#def-augmented-assurance-cert" />
|
|
<link rel="subsection" title="5.1.3 Validated Certificates" href=
|
|
"#sec-validated-certificates" />
|
|
<link rel="bookmark" title="def-validated-cert" href=
|
|
"#def-validated-cert" />
|
|
<link rel="subsection" title=
|
|
"5.1.4 Self-signed Certificates and Untrusted Root Certificates"
|
|
href="#selfsignedcerts" />
|
|
<link rel="section" title="5.2 Types of TLS" href=
|
|
"#typesoftls" />
|
|
<link rel="bookmark" title="def-http-transaction" href=
|
|
"#def-http-transaction" />
|
|
<link rel="bookmark" title="def-tls-protected" href=
|
|
"#def-tls-protected" />
|
|
<link rel="bookmark" title="def-strong-tls" href=
|
|
"#def-strong-tls" />
|
|
<link rel="bookmark" title="def-strong-algos" href=
|
|
"#def-strong-algos" />
|
|
<link rel="bookmark" title="def-weak-tls" href="#def-weak-tls" />
|
|
<link rel="section" title="5.3 Mixed Content" href=
|
|
"#securepage" />
|
|
<link rel="bookmark" title="def-secure-page" href=
|
|
"#def-secure-page" />
|
|
<link rel="bookmark" title="def-mixed-content" href=
|
|
"#def-mixed-content" />
|
|
<link rel="section" title="5.4 Error conditions" href=
|
|
"#errorconditions" />
|
|
<link rel="subsection" title="5.4.1 TLS errors" href=
|
|
"#sec-tlserrors" />
|
|
<link rel="subsection" title=
|
|
"5.4.2 Error Conditions based on Third Party or Heuristic Information"
|
|
href="#errors-blacklists" />
|
|
<link rel="subsection" title="5.4.3 Insecure form submission"
|
|
href="#insecure-form-submission" />
|
|
<link rel="chapter" title="6 Indicators and Interactions" href=
|
|
"#indicators" />
|
|
<link rel="section" title=
|
|
"6.1 Identity and Trust Anchor Signaling" href=
|
|
"#IdentitySignal" />
|
|
<link rel="subsection" title="6.1.1 Identity Signal" href=
|
|
"#identity-requirement" />
|
|
<link rel="subsection" title="6.1.2 Identity Signal Content"
|
|
href="#signal-content" />
|
|
<link rel="section" title=
|
|
"6.2 Additional Security Context Information" href=
|
|
"#pageinfosummary" />
|
|
<link rel="bookmark" title="asc-must" href="#asc-must" />
|
|
<link rel="bookmark" title="pageinfo-domain" href=
|
|
"#pageinfo-domain" />
|
|
<link rel="bookmark" title="pageinfo-owner" href=
|
|
"#pageinfo-owner" />
|
|
<link rel="bookmark" title="pageinfo-verifier" href=
|
|
"#pageinfo-verifier" />
|
|
<link rel="bookmark" title="pageinfo-trustroots" href=
|
|
"#pageinfo-trustroots" />
|
|
<link rel="bookmark" title="asc-should" href="#asc-should" />
|
|
<link rel="bookmark" title="pageinfo-weak" href=
|
|
"#pageinfo-weak" />
|
|
<link rel="bookmark" title="pageinfo-history" href=
|
|
"#pageinfo-history" />
|
|
<link rel="bookmark" title="pageinfo-storedcreds" href=
|
|
"#pageinfo-storedcreds" />
|
|
<link rel="bookmark" title="pageinfo-enc" href="#pageinfo-enc" />
|
|
<link rel="bookmark" title="pageinfo-auth" href=
|
|
"#pageinfo-auth" />
|
|
<link rel="bookmark" title="asc-may" href="#asc-may" />
|
|
<link rel="bookmark" title="pageinfo-when-first" href=
|
|
"#pageinfo-when-first" />
|
|
<link rel="bookmark" title="pageinfo-how-often" href=
|
|
"#pageinfo-how-often" />
|
|
<link rel="section" title="6.3 TLS indicator" href=
|
|
"#sec-tls-indicator" />
|
|
<link rel="section" title="6.4 Error handling and signaling"
|
|
href="#error-handling" />
|
|
<link rel="subsection" title=
|
|
"6.4.1 Common Error Interaction Requirements" href=
|
|
"#error-common" />
|
|
<link rel="subsection" title="6.4.2 Warning/Caution Messages "
|
|
href="#error-warning" />
|
|
<link rel="subsection" title="6.4.3 Danger Messages" href=
|
|
"#error-danger" />
|
|
<link rel="chapter" title="7 Robustness Best Practices" href=
|
|
"#Robustness" />
|
|
<link rel="section" title="7.1 Keep Security Chrome Visible"
|
|
href="#keepchromevisible-goodpractice" />
|
|
<link rel="section" title=
|
|
"7.2 Do not mix content and security indicators" href=
|
|
"#site-identifying" />
|
|
<link rel="section" title="7.3 Managing User Attention" href=
|
|
"#interaction-flooding" />
|
|
<link rel="bookmark" title="whack-a-mole" href="#whack-a-mole" />
|
|
<link rel="bookmark" title="prevent-click-thru" href=
|
|
"#prevent-click-thru" />
|
|
<link rel="section" title="7.4 APIs Exposed To Web Content" href=
|
|
"#robustness-apis" />
|
|
<link rel="subsection" title=
|
|
"7.4.1 Obscuring or disabling Security User Interfaces" href=
|
|
"#robustness-apis-obscure-security-ui" />
|
|
<link rel="bookmark" title="prevent-obscuring" href=
|
|
"#prevent-obscuring" />
|
|
<link rel="bookmark" title="restrict-window-resizing" href=
|
|
"#restrict-window-resizing" />
|
|
<link rel="bookmark" title="prevent-new-windows" href=
|
|
"#prevent-new-windows" />
|
|
<link rel="bookmark" title="prevent-overlaying-chrome" href=
|
|
"#prevent-overlaying-chrome" />
|
|
<link rel="subsection" title="7.4.2 Software Installation" href=
|
|
"#robustness-software-install" />
|
|
<link rel="bookmark" title="prevent-api-exposure" href=
|
|
"#prevent-api-exposure" />
|
|
<link rel="bookmark" title="prevent-installation" href=
|
|
"#prevent-installation" />
|
|
<link rel="subsection" title="7.4.3 Bookmarking APIs" href=
|
|
"#robustness-bookmarks" />
|
|
<link rel="bookmark" title="bookmark-api-userconsent" href=
|
|
"#bookmark-api-userconsent" />
|
|
<link rel="bookmark" title="bookmark-api-uri-match" href=
|
|
"#bookmark-api-uri-match" />
|
|
<link rel="subsection" title="7.4.4 Pop-up Window APIs" href=
|
|
"#popups" />
|
|
<link rel="bookmark" title="prevent-newwindows" href=
|
|
"#prevent-newwindows" />
|
|
<link rel="bookmark" title="offer-extended-perm" href=
|
|
"#offer-extended-perm" />
|
|
<link rel="chapter" title="8 Security Considerations" href=
|
|
"#security-considerations" />
|
|
<link rel="section" title=
|
|
"8.1 Active attacks during initial TLS interactions" href=
|
|
"#mitm-initial" />
|
|
<link rel="section" title=
|
|
"8.2 Certificate Status Checking Failures" href=
|
|
"#cert-status-check-failures" />
|
|
<link rel="section" title=
|
|
"8.3 Certificates assure identity, not security" href=
|
|
"#certs-assure-identity" />
|
|
<link rel="section" title=
|
|
"8.4 Binding "human readable" names to domain names"
|
|
href="#security-considerations-petnames" />
|
|
<link rel="section" title="8.5 Warning Fatigue" href=
|
|
"#security-considerations-warning-fatigue" />
|
|
<link rel="section" title=
|
|
"8.6 Mixing Augmented Assurance and Validated Certificates" href=
|
|
"#security-considerations-ev-dv" />
|
|
<link rel="section" title=
|
|
"8.7 Dynamic content might change security properties" href=
|
|
"#dynamic-content" />
|
|
<link rel="chapter" title="9 Terms defined in this document"
|
|
href="#Terms" />
|
|
<link rel="chapter" title="10 References" href="#Ref" />
|
|
<style type="text/css">
|
|
/*<![CDATA[*/
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
|
|
[id]:hover:after {
|
|
content: " #" attr(id) " ";
|
|
font-size: 80%;
|
|
color: #ccc;
|
|
text-decoration: none;
|
|
}
|
|
|
|
a.borken {
|
|
background: #f99;
|
|
color: #000;
|
|
font-weight: bold;
|
|
}
|
|
|
|
p[id]:hover:after {
|
|
content: "";
|
|
}
|
|
|
|
a.anchor {
|
|
color: inherit;
|
|
font-weight: inherit;
|
|
text-decoration: none;
|
|
font-style: inherit;
|
|
}
|
|
|
|
p[id]:hover:after {
|
|
content: " #" attr(id) " ¶ ";
|
|
font-size: 80%;
|
|
color: #ccc;
|
|
text-decoration: none;
|
|
}
|
|
|
|
div.note {
|
|
font-weight: bold;
|
|
font-style: italic;
|
|
color: #008000;
|
|
border-left: 2px solid #008000;
|
|
margin-left: 0;
|
|
padding-left: 2em;
|
|
}
|
|
|
|
span.sqbrackets {
|
|
font-style: italic;
|
|
color: #005000;
|
|
}
|
|
|
|
div.exampleOuter {
|
|
padding-left: 2em;
|
|
padding-right: 2em;
|
|
border: 1px solid black;
|
|
background: #ffa;
|
|
}
|
|
|
|
/*]]>*/
|
|
</style>
|
|
<link rel="stylesheet" type="text/css" href=
|
|
"http://www.w3.org/StyleSheets/TR/W3C-REC.css" />
|
|
</head>
|
|
|
|
<body>
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width=
|
|
"72" /></a></p>
|
|
|
|
<h1><a href="#title" id="title" name="title" class="anchor">Web
|
|
Security Context: User Interface Guidelines</a></h1>
|
|
|
|
<h2><a href="#w3c-doctype" id="w3c-doctype" name="w3c-doctype"
|
|
class="anchor">W3C Recommendation 12 August 2010</a></h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2010/REC-wsc-ui-20100812/">http://www.w3.org/TR/2010/REC-wsc-ui-20100812/</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/wsc-ui/">http://www.w3.org/TR/wsc-ui/</a></dd>
|
|
|
|
<dt>Previous version:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2010/PR-wsc-ui-20100622/">http://www.w3.org/TR/2010/PR-wsc-ui-20100622/</a></dd>
|
|
|
|
<dt>Editors:</dt>
|
|
|
|
<dd>Thomas Roessler, <a href=
|
|
"http://www.w3.org/">W3C</a></dd>
|
|
|
|
<dd>Anil Saldhana, <a href=
|
|
"http://www.redhat.com/">RedHat</a></dd>
|
|
</dl>
|
|
|
|
<p>Please refer to the <a href="http://www.w3.org/2010/08/wsc-errata.html"><strong>errata</strong></a> for this document, which may include some normative corrections.</p>
|
|
|
|
<p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=wsc-ui"><strong>translations</strong></a>.</p>
|
|
|
|
<p class="copyright"><a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
|
|
(<a href="http://www.csail.mit.edu/"><acronym title=
|
|
"Massachusetts Institute of Technology">MIT</acronym></a>,
|
|
<a href="http://www.ercim.eu/"><acronym title=
|
|
"European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights
|
|
Reserved. W3C <a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">
|
|
liability</a>, <a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
|
|
and <a href=
|
|
"http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply.</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div>
|
|
<h2><a href="#abstract" id="abstract" name="abstract" class=
|
|
"anchor">Abstract</a></h2>This specification defines guidelines
|
|
and requirements for the presentation and communication of Web
|
|
security context information to end-users.
|
|
</div>
|
|
|
|
<div>
|
|
<h2><a href="#status" id="status" name="status" class=
|
|
"anchor">Status of this Document</a></h2>
|
|
|
|
<p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
|
|
|
|
|
|
<p>Please see the Working Group's <a href=
|
|
"wsc-impl.html">implementation report</a>.</p>
|
|
|
|
<p>To frame its development of this specification, the Working
|
|
Group had previously published a use case note <a href=
|
|
"#ref-wsc-usecases">[WSC-USECASES]</a>. This specification
|
|
addresses most of the use cases and issues documented in that
|
|
note by documenting best existing practice, with the following
|
|
exceptions:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>This specification does not include advice for web site
|
|
authors.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>This specification does not provide advice to address
|
|
the issue explained in sections <a href=
|
|
"http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/#extended-chrome">
|
|
9.1.2 Visually extending the chrome</a> and <a href=
|
|
"http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/#information-bar">
|
|
9.2.7 Information bar (aka: notification bar)</a>.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Additionally, section <a href=
|
|
"http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/#usability-testing">
|
|
10.4 Implementation and testing</a> of <a href=
|
|
"#ref-wsc-usecases">[WSC-USECASES]</a> articulated an
|
|
expectation that the recommendations in this specification
|
|
would be subject to usability testing, at least on a low
|
|
fidelity level, and that such testing would form part of the
|
|
Candidate Recommendation exit criteria. Resources available to
|
|
the Working Group at this point will not permit the group to
|
|
conduct extensive usability testing. At the same time, the
|
|
focus of this specification has shifted toward documenting best
|
|
existing practice.</p>
|
|
|
|
<p>This document was developed by the <a href=
|
|
"http://www.w3.org/2006/WSC/">Web Security Context Working
|
|
Group</a>. For a list of changes to this document since its
|
|
Proposed Recommendation version, please refer to the <a href=
|
|
"diff.html">diff document</a>. All changes were editorial in
|
|
nature.</p>
|
|
|
|
<p>Please send comments about this document to <a href=
|
|
"mailto:public-usable-authentication@w3.org">public-usable-authentication@w3.org</a>
|
|
(with <a href=
|
|
"http://lists.w3.org/Archives/Public/public-usable-authentication/">
|
|
public archive</a>).</p>
|
|
|
|
<p>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p>
|
|
|
|
<p>This document was produced by a group operating under the
|
|
<a href=
|
|
"http://www.w3.org/Consortium/Patent-Policy-20040205/">5
|
|
February 2004 W3C Patent Policy</a>. W3C maintains a <a rel=
|
|
"disclosure" href=
|
|
"http://www.w3.org/2004/01/pp-impl/39814/status">public list of
|
|
any patent disclosures</a> made in connection with the
|
|
deliverables of the group; that page also includes instructions
|
|
for disclosing a patent.</p>
|
|
</div>
|
|
|
|
<div class="toc">
|
|
<h2><a href="#contents" id="contents" name="contents" class=
|
|
"anchor">Table of Contents</a></h2>
|
|
|
|
<p class="toc">1 <a href="#Overview">Overview</a><br />
|
|
2 <a href="#thanks">Acknowledgments</a><br />
|
|
3 <a href="#Conformance">Conformance</a><br />
|
|
3.1 <a href=
|
|
"#conformance-products">Product classes</a><br />
|
|
3.2 <a href=
|
|
"#conformance-language">Language conventions</a><br />
|
|
3.3 <a href=
|
|
"#conformance-levels">Conformance levels</a><br />
|
|
3.4 <a href=
|
|
"#conformance-claims">Conformance claims</a><br />
|
|
4 <a href="#concepts">Interaction and content model</a><br />
|
|
4.1 <a href=
|
|
"#interaction-overview">Overview</a><br />
|
|
4.2 <a href="#definitions">Terms and
|
|
definitions</a><br />
|
|
4.2.1 <a href=
|
|
"#common-widgets">Common User Interface elements</a><br />
|
|
5 <a href="#tlsforweb">Applying TLS to the Web</a><br />
|
|
5.1 <a href=
|
|
"#tlstosecurehttp">Certificate Handling and
|
|
Information</a><br />
|
|
5.1.1 <a href=
|
|
"#sec-interactively">Interactively accepting trust anchors or
|
|
certificates</a><br />
|
|
5.1.2 <a href=
|
|
"#sec-evcert">Augmented Assurance Certificates</a><br />
|
|
5.1.3 <a href=
|
|
"#sec-validated-certificates">Validated Certificates</a><br />
|
|
5.1.4 <a href=
|
|
"#selfsignedcerts">Self-signed Certificates and Untrusted Root
|
|
Certificates</a><br />
|
|
5.2 <a href="#typesoftls">Types of
|
|
TLS</a><br />
|
|
5.3 <a href="#securepage">Mixed
|
|
Content</a><br />
|
|
5.4 <a href="#errorconditions">Error
|
|
conditions</a><br />
|
|
5.4.1 <a href=
|
|
"#sec-tlserrors">TLS errors</a><br />
|
|
5.4.2 <a href=
|
|
"#errors-blacklists">Error Conditions based on Third Party or
|
|
Heuristic Information</a><br />
|
|
5.4.3 <a href=
|
|
"#insecure-form-submission">Insecure form submission</a><br />
|
|
6 <a href="#indicators">Indicators and Interactions</a><br />
|
|
6.1 <a href="#IdentitySignal">Identity
|
|
and Trust Anchor Signaling</a><br />
|
|
6.1.1 <a href=
|
|
"#identity-requirement">Identity Signal</a><br />
|
|
6.1.2 <a href=
|
|
"#signal-content">Identity Signal Content</a><br />
|
|
6.2 <a href=
|
|
"#pageinfosummary">Additional Security Context
|
|
Information</a><br />
|
|
6.3 <a href="#sec-tls-indicator">TLS
|
|
indicator</a><br />
|
|
6.4 <a href="#error-handling">Error
|
|
handling and signaling</a><br />
|
|
6.4.1 <a href=
|
|
"#error-common">Common Error Interaction Requirements</a><br />
|
|
6.4.2 <a href=
|
|
"#error-warning">Warning/Caution Messages</a><br />
|
|
6.4.3 <a href=
|
|
"#error-danger">Danger Messages</a><br />
|
|
7 <a href="#Robustness">Robustness Best Practices</a><br />
|
|
7.1 <a href=
|
|
"#keepchromevisible-goodpractice">Keep Security Chrome
|
|
Visible</a><br />
|
|
7.2 <a href="#site-identifying">Do not
|
|
mix content and security indicators</a><br />
|
|
7.3 <a href=
|
|
"#interaction-flooding">Managing User Attention</a><br />
|
|
7.4 <a href="#robustness-apis">APIs
|
|
Exposed To Web Content</a><br />
|
|
7.4.1 <a href=
|
|
"#robustness-apis-obscure-security-ui">Obscuring or disabling
|
|
Security User Interfaces</a><br />
|
|
7.4.2 <a href=
|
|
"#robustness-software-install">Software Installation</a><br />
|
|
7.4.3 <a href=
|
|
"#robustness-bookmarks">Bookmarking APIs</a><br />
|
|
7.4.4 <a href=
|
|
"#popups">Pop-up Window APIs</a><br />
|
|
8 <a href="#security-considerations">Security
|
|
Considerations</a><br />
|
|
8.1 <a href="#mitm-initial">Active
|
|
attacks during initial TLS interactions</a><br />
|
|
8.2 <a href=
|
|
"#cert-status-check-failures">Certificate Status Checking
|
|
Failures</a><br />
|
|
8.3 <a href=
|
|
"#certs-assure-identity">Certificates assure identity, not
|
|
security</a><br />
|
|
8.4 <a href=
|
|
"#security-considerations-petnames">Binding "human readable"
|
|
names to domain names</a><br />
|
|
8.5 <a href=
|
|
"#security-considerations-warning-fatigue">Warning
|
|
Fatigue</a><br />
|
|
8.6 <a href=
|
|
"#security-considerations-ev-dv">Mixing Augmented Assurance and
|
|
Validated Certificates</a><br />
|
|
8.7 <a href="#dynamic-content">Dynamic
|
|
content might change security properties</a><br />
|
|
9 <a href="#Terms">Terms defined in this document</a><br />
|
|
10 <a href="#Ref">References</a><br /></p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div class="body">
|
|
<div class="div1">
|
|
<h2><a href="#Overview" id="Overview" name="Overview" class=
|
|
"anchor">1 Overview</a></h2>
|
|
|
|
<p>This specification deals with the trust decisions that
|
|
users must make online, and with ways to support them in
|
|
making safe and informed decisions where possible.</p>
|
|
|
|
<p>In order to achieve that goal, this specification includes
|
|
recommendations on the presentation of identity information
|
|
by user agents, <a href="#identity-requirement"><b>6.1.1
|
|
Identity Signal</b></a>. We also include recommendations on
|
|
conveying error situations in security protocols. The error
|
|
handling recommendations both minimize the trust decisions
|
|
left to users, and represent known best practice in inducing
|
|
users toward safe behavior where they have to make these
|
|
decisions. To complement the interaction and decision related
|
|
parts of this specification, <a href="#Robustness"><b>7
|
|
Robustness Best Practices</b></a> addresses the question of
|
|
how the communication of context information needed to make
|
|
decisions can be made more robust against attacks.</p>
|
|
|
|
<p>This document specifies user interactions with a goal
|
|
toward making security usable, based on known best practice
|
|
in this area. This document is intended to provide user
|
|
interface guidelines. Most sections assume the audience has a
|
|
certain level of understanding of the core PKI (Public Key
|
|
Infrastructure) technologies as used on the Web. The
|
|
following sections are relevant to all readers and do not
|
|
require a thorough understanding of PKI: <a href=
|
|
"#Conformance"><b>3 Conformance</b></a>, <a href=
|
|
"#concepts"><b>4 Interaction and content model</b></a>,
|
|
<a href="#indicators"><b>6 Indicators and
|
|
Interactions</b></a>, <a href="#error-handling"><b>6.4 Error
|
|
handling and signaling</b></a>, <a href="#Robustness"><b>7
|
|
Robustness Best Practices</b></a> and <a href=
|
|
"#security-considerations-warning-fatigue"><b>8.5 Warning
|
|
Fatigue</b></a>. Since this document is part of the W3C
|
|
specification process, it is written to clearly lay out the
|
|
requirements and options for conforming to it as a standard.
|
|
User interface guidelines that are not intended for use as
|
|
standards do not have such a structure. Readers more familiar
|
|
with that latter form of user interface guideline are
|
|
encouraged to read this specification as a way to avoid known
|
|
mistakes in usable security.</p>
|
|
|
|
<p>This specification comes with two companion documents:
|
|
<a href="#ref-wsc-usecases">[WSC-USECASES]</a> documents the
|
|
initial assumptions about the scope of this specification. It
|
|
also includes an initial set of use cases the Working Group
|
|
discussed. <a href="#ref-wsc-threats">[WSC-THREATS]</a>
|
|
documents the Working Group's initial threat analysis. This
|
|
document is based on current best practices in deployed user
|
|
agents, and covers the use cases and threats in those
|
|
documents to that extent.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#thanks" id="thanks" name="thanks" class=
|
|
"anchor">2 Acknowledgments</a></h2>
|
|
|
|
<p>This specification is based on text from Mary Ellen Zurko,
|
|
Stephen Farrell, Anil Saldhana, Ian Fette, Michael McCormick,
|
|
Serge Egelman, Johnathan Nightingale, Yngve N. Pettersen,
|
|
Luis Barriga, Hal Lockhart, Tyler Close, Bill Doyle, Thomas
|
|
Roessler, as well as input and discussions from the active
|
|
members of the Web Security Context Working Group, primarily
|
|
Phillip Hallam-Baker, Mike Beltzner, Joe Steele, Jan Vidar
|
|
Krey, Maritza Johnson, Rachna Dhamija and Dan Schutzer. It
|
|
has also benefited from general public and working group
|
|
commentary on earlier drafts.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#Conformance" id="Conformance" name=
|
|
"Conformance" class="anchor">3 Conformance</a></h2>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#conformance-products" id=
|
|
"conformance-products" name="conformance-products" class=
|
|
"anchor">3.1 Product classes</a></h3>
|
|
|
|
<p>This specification addresses <a title="" href=
|
|
"#def-user-agent">Web user agents</a> as a product class.
|
|
Web user agents and user agents are used synonymously in
|
|
this specification.</p>
|
|
|
|
<p>This specification also addresses products that might
|
|
incorporate changes to a user agents, such as plug-ins,
|
|
extensions, and others; they are summarily called [<a name=
|
|
"def-plug-in" id="def-plug-in" title="">Definition</a>:
|
|
plug-ins] in this section.</p>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#conformance-language" id=
|
|
"conformance-language" name="conformance-language" class=
|
|
"anchor">3.2 Language conventions</a></h3>
|
|
|
|
<p>Throughout the specification, the RFC 2119 <a href=
|
|
"#ref-RFC2119">[RFC2119]</a> keywords MUST, MUST NOT,
|
|
SHOULD, SHOULD NOT, MAY are applied, with their respective
|
|
meanings.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#conformance-levels" id="conformance-levels"
|
|
name="conformance-levels" class="anchor">3.3 Conformance
|
|
levels</a></h3>
|
|
|
|
<p>A user agent conforms to this specification at the
|
|
[<a name="conformance-basic" id="conformance-basic" title=
|
|
"">Definition</a>: basic level] if it honors all MUST and
|
|
MUST NOT clauses of this specification.</p>
|
|
|
|
<p>A user agent conforms to this specification at the
|
|
[<a name="conformance-advanced" id="conformance-advanced"
|
|
title="">Definition</a>: advanced level] if it also honors
|
|
all SHOULD and SHOULD NOT clauses of this
|
|
specification.</p>
|
|
|
|
<p>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 <em>with respect to this base user agent</em>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#conformance-claims" id="conformance-claims"
|
|
name="conformance-claims" class="anchor">3.4 Conformance
|
|
claims</a></h3>
|
|
|
|
<p>A claim about a Web user agent's conformance with this
|
|
specification must state:</p>
|
|
|
|
<ol class="enumar">
|
|
<li>Whether basic or advanced conformance is claimed (see
|
|
<a href="#conformance-levels"><b>3.3 Conformance
|
|
levels</b></a>)</li>
|
|
|
|
<li>What TLS <a href="#ref-sslv3">[SSLv3]</a><a href=
|
|
"#ref-tlsv11">[TLSv11]</a><a href=
|
|
"#ref-tlsv12">[TLSv12]</a> protocol versions and
|
|
algorithms are considered as <a title="" href=
|
|
"#def-strong-algos">strong TLS algorithms</a>, and what
|
|
protocol versions and algorithms are supported in TLS
|
|
negotiation, but not considered <a title="" href=
|
|
"#def-strong-algos">strong</a>.</li>
|
|
|
|
<li>What user interface element is the <a title="" href=
|
|
"#tls-indicator">TLS indicator</a> defined in this
|
|
specification.</li>
|
|
|
|
<li>What user interface element is the <a title="" href=
|
|
"#def-identity-signal">identity signal</a> defined in
|
|
this specification.</li>
|
|
|
|
<li>What broadly accepted practices are considered
|
|
sufficient for a trust anchor to be deemed augmented
|
|
assurance qualified (see <a href="#sec-evcert"><b>5.1.2
|
|
Augmented Assurance Certificates</b></a>), and what data
|
|
elements are deemed assured by those certificates.</li>
|
|
|
|
<li>What features beyond the claimed conformance level
|
|
the user agent conforms with.</li>
|
|
</ol>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#concepts" id="concepts" name="concepts" class=
|
|
"anchor">4 Interaction and content model</a></h2>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#interaction-overview" id=
|
|
"interaction-overview" name="interaction-overview" class=
|
|
"anchor">4.1 Overview</a></h3>
|
|
|
|
<p>This specification assumes a human user interacting with
|
|
a <a title="" href="#def-user-agent">Web user agent</a>,
|
|
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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>This specification makes no specific assumption about
|
|
the content with which the user interacts, except for one:
|
|
There is a top-level <a title="" href="#def-page">Web
|
|
page</a> that is identified by a URI <a href=
|
|
"#ref-URI">[RFC3986]</a>. 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.</p>
|
|
|
|
<p>In interactive Web applications, the presentation to the
|
|
user might also depend on state that is local to the client
|
|
- be it local storage of structured data, or be it recent
|
|
interactions with the Web page. The security properties of
|
|
those data will depend on the security properties of the
|
|
client computer itself, and are out of scope for this
|
|
specification.</p>
|
|
|
|
<p>Some requirements are expressed in terms of user
|
|
interface components commonly found in current-generation
|
|
<a title="" href="#def-user-agent">Web user agents</a>.</p>
|
|
|
|
<p><a href="#definitions"><b>4.2 Terms and
|
|
definitions</b></a> is expected to be consistent with the
|
|
Web Content Accessibility Guidelines Version 2, <a href=
|
|
"#ref-WCAG2">[WCAG20]</a>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#definitions" id="definitions" name=
|
|
"definitions" class="anchor">4.2 Terms and
|
|
definitions</a></h3>
|
|
|
|
<p>[<a name="def-user-agent" id="def-user-agent" title=
|
|
"">Definition</a>: A <b>Web User Agent</b> is any software
|
|
that retrieves and presents Web content for users.]</p>
|
|
|
|
<p>[<a name="def-page" id="def-page" title=
|
|
"">Definition</a>: A <b>Web Page</b> 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.]</p>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#common-widgets" id="common-widgets" name=
|
|
"common-widgets" class="anchor">4.2.1 Common User
|
|
Interface elements</a></h4>
|
|
|
|
<p>This section defines terms for user interface elements
|
|
commonly present in <a title="" href=
|
|
"#def-user-agent">Web User Agents</a>.</p>
|
|
|
|
<p>[<a name="def-primary-chrome" id="def-primary-chrome"
|
|
title="">Definition</a>: <b>Primary User Interface</b>
|
|
denotes the portions of a <a title="" href=
|
|
"#def-user-agent">Web user agent's</a> user interface
|
|
that are available to users without being solicited by a
|
|
user interaction.]</p>
|
|
|
|
<p>Examples of primary user interface include the
|
|
location bar in common Web user agents, the "padlock"
|
|
icon present in common Web user agents, or error pages
|
|
that take the place of a Web page that could not be
|
|
retrieved.</p>
|
|
|
|
<p>[<a name="def-secondary-chrome" id=
|
|
"def-secondary-chrome" title="">Definition</a>:
|
|
<b>Secondary User Interface</b> denotes the portions of a
|
|
<a title="" href="#def-user-agent">Web user agent's</a>
|
|
user interface that are available to the user after they
|
|
are solicited by a specific user interaction.]</p>
|
|
|
|
<p>Examples of secondary user interface include the "Page
|
|
Information" dialog commonly found in Web user agents,
|
|
and the "Security Properties" dialog that can obtained by
|
|
clicking the padlock icon in common Web user agents.</p>
|
|
|
|
<p>We occasionally use the term [<a name="def-chrome" id=
|
|
"def-chrome" title="">Definition</a>: <b>chrome</b>] to
|
|
refer to the representation through which the user
|
|
interacts with the user agent itself, as distinct from
|
|
the accessed web content. This includes both primary and
|
|
secondary user interface.</p>
|
|
|
|
<p>[<a name="def-locationbar" id="def-locationbar" title=
|
|
"">Definition</a>: <b>Location Bar</b> is a widget in a
|
|
Web user agent's user interface which displays (and often
|
|
allows input of) the textual location (entered as a URI)
|
|
of the resource being requested (or displayed - after the
|
|
response is received).]</p>
|
|
|
|
<p>[<a name="def-identity-information" id=
|
|
"def-identity-information" title="">Definition</a>:
|
|
<b>Identity Information</b> is information about the web
|
|
site which is used to present the identity signal.]</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#tlsforweb" id="tlsforweb" name="tlsforweb"
|
|
class="anchor">5 Applying TLS to the Web</a></h2>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#tlstosecurehttp" id="tlstosecurehttp" name=
|
|
"tlstosecurehttp" class="anchor">5.1 Certificate Handling
|
|
and Information</a></h3>
|
|
|
|
<p>Public key certificates (see <a href=
|
|
"#ref-PKIX">[PKIX]</a>) are widely used in TLS <a href=
|
|
"#ref-sslv3">[SSLv3]</a> <a href="#ref-tlsv11">[TLSv11]</a>
|
|
<a href="#ref-tlsv12">[TLSv12]</a>, 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.</p>
|
|
|
|
<p>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) vary by CA and
|
|
are not available in any useful sense to Web user
|
|
agents.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#sec-interactively" id="sec-interactively"
|
|
name="sec-interactively" class="anchor">5.1.1
|
|
Interactively accepting trust anchors or
|
|
certificates</a></h4>
|
|
|
|
<p>A trust anchor represents an authoritative entity
|
|
represented by a public key and associated data. The
|
|
public key is used to verify digital signatures and the
|
|
associated data is used to constrain the types of
|
|
information for which the trust anchor is authoritative.
|
|
Relying parties use trust anchors to determine if
|
|
digitally signed information objects are valid by
|
|
verifying digital signatures using the trust anchor's
|
|
public key and by enforcing the constraints expressed in
|
|
the associated certificate data.</p>
|
|
|
|
<p>Trust anchor installation is typically handled by user
|
|
agent vendors, systems administrators and device
|
|
manufacturers, based on out-of-band information. Note
|
|
that updating trust anchors is therefore often handled as
|
|
part of user agent or operating system software
|
|
updates.</p>
|
|
|
|
<p>However, current user agents sometimes support the
|
|
interactive acceptance of a trust anchor during a
|
|
session, based on user interaction. Most users cannot
|
|
sensibly decide how to handle such interactions.</p>
|
|
|
|
<p>Similarly, end-entity (e.g. web server) certificates
|
|
that cannot be currently verified using the Basic Path
|
|
Validation algorithm may trigger current user agents to
|
|
offer the user a choice to accept the certificate in any
|
|
case, sometimes for a single session, sometimes for all
|
|
future sessions involving that certificate, possibly
|
|
scoped to specific host and port combinations.</p>
|
|
|
|
<p>[<a name="def-interactively" id="def-interactively"
|
|
title="">Definition</a>: A trust anchor or certificate is
|
|
<b>interactively accepted</b> if the acceptance was
|
|
caused through a user interaction that happens while the
|
|
user is focused on a primary task unrelated to trust and
|
|
certificate management.]</p>
|
|
|
|
<p>For example, if a web server certificate is presented
|
|
for acceptance by a user during ordinary Web
|
|
interactions, and is accepted by the user, then this
|
|
matches the test for interactive acceptance. If, however,
|
|
a systems administrator (or user) adds a trust anchor's
|
|
certificate to an agent's store of trust roots, then that
|
|
certificate is not considered interactively accepted.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#sec-evcert" id="sec-evcert" name=
|
|
"sec-evcert" class="anchor">5.1.2 Augmented Assurance
|
|
Certificates</a></h4>
|
|
|
|
<p>Some trust anchors adhere to documented broadly
|
|
accepted practices (e.g. <a href=
|
|
"#ref-EV">[EVTLSCERT]</a>). These involve some level of
|
|
guarantee that certificates chaining up to those roots
|
|
embody augmented assurance and can therefore be treated
|
|
more favorably in terms of the primary security
|
|
indicators. We call such certificates "Augmented
|
|
Assurance Certificates".</p>
|
|
|
|
<p>[<a name="def-augmented-assurance-cert" id=
|
|
"def-augmented-assurance-cert" title="">Definition</a>:
|
|
An <b>Augmented Assurance Certificate</b> is a public key
|
|
certificate where the issuer asserts that the subject
|
|
entity has been authenticated by means of some process
|
|
that adheres to the requirements of an augmented
|
|
assurance specification supported by the user agent. The
|
|
certificate chain for such a certificate MUST be
|
|
validated up to a trust root that is recognized as
|
|
augmented assurance qualified by the user agent.]</p>
|
|
|
|
<p>This specification does not define what an "augmented
|
|
assurance qualified trust root" is, except to note that
|
|
this designation is made by user agents through an out of
|
|
band mechanism consistent with the relevant underlying
|
|
augmented assurance specification.</p>
|
|
|
|
<p>Marking a trust anchor as augmented assurance
|
|
qualified is a security-critical step and most often will
|
|
involve the use of some application-specific out-of-band
|
|
mechanism.</p>
|
|
|
|
<p><span id="I">Implementations MUST NOT enable users to
|
|
designate trust roots as augmented assurance qualified as
|
|
part of a unrelated interaction.</span> In particular,
|
|
the notions of an augmented assurance qualified trust
|
|
root and an <a title="" href=
|
|
"#def-interactively">interactively</a> accepted trust
|
|
root are mutually exclusive.</p>
|
|
|
|
<p>In addition to the out of band designation process
|
|
described above, the trust anchor, and possibly all
|
|
certificates in a path chaining up to such a trust anchor
|
|
may need to be specially marked, e.g. through the use of
|
|
specific policy object identifiers.</p>
|
|
|
|
<p>The specific marking mechanisms to be used and the
|
|
special treatment to be afforded to such certificates are
|
|
out of scope of this document, but will typically be
|
|
covered by the underlying augmented assurance
|
|
specification. User agent implementers determine the set
|
|
of such standards that they support and the associated
|
|
special treatment to apply, other than as outlined below,
|
|
where we impose some consistency requirements on the
|
|
handling of this type of certificate.</p>
|
|
|
|
<p><span id="II">To derive a human-readable subject name
|
|
from an augmented assurance certificate, user agents
|
|
SHOULD use the Subject field's Organization (O) and
|
|
Country (C) attributes.</span> <span id="IIa">They MUST
|
|
use information that is subject to the certificate
|
|
authority's additional assurances, as documented in the
|
|
user agent's conformance statement.</span></p>
|
|
|
|
<p>Note: Should certificates arise in the future that
|
|
provide strong assurance of the holder's identity, but do
|
|
not include an organization attribute, then user agents
|
|
can make use of the additional assurance level and
|
|
identity information without violating this
|
|
specification. Such future certificates could, for
|
|
example, include high assurance certificates for
|
|
individuals.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#sec-validated-certificates" id=
|
|
"sec-validated-certificates" name=
|
|
"sec-validated-certificates" class="anchor">5.1.3
|
|
Validated Certificates</a></h4>
|
|
|
|
<p>The term [<a name="def-validated-cert" id=
|
|
"def-validated-cert" title="">Definition</a>:
|
|
<b>validated certificate</b> ] is used to denote a public
|
|
key certificate that has been verified by chaining up to
|
|
a locally configured trust anchor. The set of trust
|
|
anchors used by a given Web User agent is
|
|
implementation-dependent.</p>
|
|
|
|
<p>Since Augmented Assurance Certificates chain up to a
|
|
"special" trust anchor, all valid Augmented Assurance
|
|
Certificates are also validated certificates.</p>
|
|
|
|
<p>Certificates or certificate chains that are <a title=
|
|
"" href="#def-pinned-cert">pinned</a> to a particular
|
|
destination are <em>not</em> considered validated
|
|
certificates by virtue of being pinned.</p>
|
|
|
|
<p>The notion of a validated certificate in this
|
|
specification corresponds to the domain validated
|
|
certificate commonly deployed on the Web. This type of
|
|
certificate attests to a binding between a domain name
|
|
registration and a key pair; additional certificate
|
|
attributes are often not validated.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#selfsignedcerts" id="selfsignedcerts" name=
|
|
"selfsignedcerts" class="anchor">5.1.4 Self-signed
|
|
Certificates and Untrusted Root Certificates</a></h4>
|
|
|
|
<p>Self-signed certificates (SSC) which are not trust
|
|
anchors by themselves are commonly used for appliances
|
|
and web sites catering to small groups of users, and
|
|
essentially serve as a container for cryptographic key
|
|
material in a key exchange that is not verified by any
|
|
third party. Certificate chains that lead up to custom
|
|
root certificates which are not part of the user agent's
|
|
store of trust roots are sometimes used similarly.</p>
|
|
|
|
<p>In both situations, use of TLS provides
|
|
confidentiality protection services against passive
|
|
attackers. No binding of a third-party asserted identity
|
|
to the cryptographic key is achieved. In both cases, the
|
|
certificates are not considered <a title="" href=
|
|
"#def-validated-cert">validated certificates</a>.</p>
|
|
|
|
<p>Using Key Continuity Management <a href=
|
|
"#ref-gutmann-kcm">[KCM]</a>, user agents can use
|
|
self-signed certificates (or certificates that chain up
|
|
to an untrusted root) to determine that they are
|
|
consistently communicating with the same end entity,
|
|
thereby defending against active attacks as well. Simply
|
|
put, if a Web site consistently presents the same
|
|
self-signed certificate (or the same certificate chaining
|
|
up to the same untrusted root) to a client, then this can
|
|
be strong evidence that protection against an active
|
|
attacker has been achieved as well. Conversely, a change
|
|
of certificates for the same site can be evidence that a
|
|
man in the middle attack occurs -- or it can merely
|
|
indicate that the legitimate site has changed to a
|
|
different certificate.</p>
|
|
|
|
<p><span id="V">User agents MAY support [<a name=
|
|
"def-pinned-cert" id="def-pinned-cert" title=
|
|
"">Definition</a>: <b>pinning</b>] a self-signed
|
|
certificate or more generally a certificate chain that
|
|
leads to an untrusted root certificate to a particular
|
|
Web site, to enable behavior based on recorded state
|
|
about certificates shown previously by the same
|
|
site.</span> Such behavior includes, e.g., warning users
|
|
about changes of certificates, and not showing warning
|
|
messages if a site shows a certificate consistent with
|
|
previous visits.</p>
|
|
|
|
<p><span id="VI"><a title="" href=
|
|
"#def-interactively">The interaction</a> that enables
|
|
users to pin a certificate to a destination SHOULD NOT
|
|
cause a self-signed certificate to be pinned to more than
|
|
one site, identified through URI scheme, domain, and
|
|
port.</span> <span id="VII">The interaction MUST NOT
|
|
cause an untrusted root certificate to be accepted
|
|
automatically for additional sites.</span></p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#typesoftls" id="typesoftls" name="typesoftls"
|
|
class="anchor">5.2 Types of TLS</a></h3>
|
|
|
|
<p>The most common mechanism for applying TLS to the Web is
|
|
the use of the <code>https</code> URI scheme <a href=
|
|
"#ref-RFC2818">[RFC2818]</a>; the alternative upgrade
|
|
mechanism <a href="#ref-RFC2817">[RFC2817]</a> is used
|
|
rarely, if at all. For the purposes of this specification,
|
|
the most relevant property of <a href=
|
|
"#ref-RFC2818">[RFC2818]</a> is that the URI used to
|
|
identify a resource includes an assertion that use of TLS
|
|
is desired.</p>
|
|
|
|
<p>This specification uses the term [<a name=
|
|
"def-http-transaction" id="def-http-transaction" title=
|
|
"">Definition</a>: <b>HTTP transaction</b> ] regardless of
|
|
whether any kind of TLS protection was applied; in
|
|
particular, the transactions arising when an
|
|
<code>https</code> URI is dereferenced are subsumed under
|
|
this term. <a href="#ref-RFC2616">[RFC2616]</a></p>
|
|
|
|
<p>[<a name="def-tls-protected" id="def-tls-protected"
|
|
title="">Definition</a>: An HTTP transaction is
|
|
<b>TLS-protected</b> 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.]</p>
|
|
|
|
<p>Note that an HTTP transaction may be considered
|
|
<a title="" href="#def-tls-protected">TLS protected</a>
|
|
even though weak algorithms (including <code>NULL</code>
|
|
encryption) are negotiated.</p>
|
|
|
|
<p>[<a name="def-strong-tls" id="def-strong-tls" title=
|
|
"">Definition</a>: An HTTP transaction is <b>strongly
|
|
TLS-protected</b> if it is <a title="" href=
|
|
"#def-tls-protected">TLS-protected</a>, an https URL was
|
|
used, <a title="" href="#def-strong-algos">strong TLS
|
|
algorithms</a> were negotiated for both confidentiality and
|
|
integrity protection, and at least one of the following
|
|
conditions is true:]</p>
|
|
|
|
<ol class="enumar">
|
|
<li>the server used a <a title="" href=
|
|
"#def-validated-cert">validated certificate</a> that
|
|
matches the dereferenced URI; or</li>
|
|
|
|
<li>the server used a self-signed certificate that was
|
|
<a title="" href="#def-pinned-cert">pinned</a> to the
|
|
destination; or</li>
|
|
|
|
<li>the server used a certificate chain leading to an
|
|
untrusted root certificate that was <a title="" href=
|
|
"#def-pinned-cert">pinned</a> to the destination.</li>
|
|
</ol>
|
|
|
|
<p>TLS modes that do not require the server to show a
|
|
certificate (such as the <code>DH_anon</code> mode) do not
|
|
lead to a strongly TLS-protected transaction.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>When this document speaks of [<a name="def-strong-algos"
|
|
id="def-strong-algos" title="">Definition</a>: Strong TLS
|
|
algorithms], then the following must hold:</p>
|
|
|
|
<ol class="enumar">
|
|
<li>No version of the TLS protocol that suffers known
|
|
security flaws has been negotiated. <span id="VIII">At
|
|
the point of writing of this document, versions of SSL
|
|
prior to SSLv3 <a href="#ref-sslv3">[SSLv3]</a> MUST NOT
|
|
be considered strong.</span></li>
|
|
|
|
<li>A cipher suite has been selected for which key and
|
|
algorithm strengths correspond to industry practice.
|
|
<span id="IX">At the time of writing of this document,
|
|
the "export" cipher suites explicitly forbidden in
|
|
appendix A.5 of <a href="#ref-tlsv11">[TLSv11]</a> MUST
|
|
NOT be considered strong.</span></li>
|
|
</ol>
|
|
|
|
<p>What set of algorithms is considered as strong by a
|
|
given implementation must be described in any conformance
|
|
claim against this specification, see <a href=
|
|
"#conformance-claims"><b>3.4 Conformance
|
|
claims</b></a>.</p>
|
|
|
|
<p>[<a name="def-weak-tls" id="def-weak-tls" title=
|
|
"">Definition</a>: An HTTP transaction is <b>weakly
|
|
TLS-protected</b> if it is TLS-protected, but strong TLS
|
|
protection could not be achieved for one of the following
|
|
reasons:]</p>
|
|
|
|
<ol class="enumar">
|
|
<li>TLS handshake used an anonymous key exchange
|
|
algorithm such as <code>DH_anon</code></li>
|
|
|
|
<li>the cryptographic algorithms negotiated are not
|
|
considered <a title="" href=
|
|
"#def-strong-algos">strong</a></li>
|
|
|
|
<li>certificates were used that are not either <a title=
|
|
"" href="#def-validated-cert">validated certificates</a>,
|
|
or self-signed certificates <a title="" href=
|
|
"#def-pinned-cert">pinned</a> to the destination (see
|
|
<a href="#selfsignedcerts"><b>5.1.4 Self-signed
|
|
Certificates and Untrusted Root
|
|
Certificates</b></a>)</li>
|
|
</ol>
|
|
|
|
<p><a title="" href="#def-weak-tls">Weakly
|
|
TLS-protected</a> 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 <a title="" href=
|
|
"#def-strong-tls">strong TLS protection</a> cannot be
|
|
achieved.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#securepage" id="securepage" name="securepage"
|
|
class="anchor">5.3 Mixed Content</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>[<a name="def-secure-page" id="def-secure-page" title=
|
|
"">Definition</a>: A Web page is called <b>TLS-secured</b>
|
|
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. ]</p>
|
|
|
|
<p>[<a name="def-mixed-content" id="def-mixed-content"
|
|
title="">Definition</a>: A Web page is called <b>mixed
|
|
content</b> if the top-level resource was retrieved through
|
|
a strongly TLS protected HTTP transaction, but some
|
|
dependent resources were retrieved through a weakly
|
|
protected or unprotected HTTP transaction.]</p>
|
|
|
|
<p>This definition implies that inline images, stylesheets,
|
|
script content, and frame content for a secure page need to
|
|
be retrieved through <a title="" href=
|
|
"#def-strong-tls">strongly TLS</a> protected HTTP
|
|
transactions in order for the overall page to be considered
|
|
TLS-secured.</p>
|
|
|
|
<p><span id="X">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 <a title="" href="#def-secure-page">TLS-secured</a>,
|
|
i.e., all parts of the page are loaded from servers
|
|
presenting at least a <a title="" href=
|
|
"#def-validated-cert">validated certificate</a>, over
|
|
<a title="" href="#def-strong-tls">strongly TLS-protected
|
|
interactions</a>.</span></p>
|
|
|
|
<p>For relevant security considerations, see <a href=
|
|
"#security-considerations-ev-dv"><b>8.6 Mixing Augmented
|
|
Assurance and Validated Certificates</b></a>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#errorconditions" id="errorconditions" name=
|
|
"errorconditions" class="anchor">5.4 Error
|
|
conditions</a></h3>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#sec-tlserrors" id="sec-tlserrors" name=
|
|
"sec-tlserrors" class="anchor">5.4.1 TLS errors</a></h4>
|
|
|
|
<p>This section covers TLS-related error conditions, and
|
|
maps them to the classes of error handling interactions
|
|
(see <a href="#error-handling"><b>6.4 Error handling and
|
|
signaling</b></a>) that are used when these conditions
|
|
arise.</p>
|
|
|
|
<p><span id="XI">If multiple error conditions apply, the
|
|
most severe signaling level currently known MUST be used,
|
|
as defined in <a href="#error-handling"><b>6.4 Error
|
|
handling and signaling</b></a>.</span></p>
|
|
|
|
<p>When, during TLS negotiation, the certificate chain
|
|
presented by the server does not lead to a trusted root
|
|
certificate, and the certificate chain presented was not
|
|
<a title="" href="#def-pinned-cert">pinned</a> to the
|
|
destination, the following applies:</p>
|
|
|
|
<ol class="enumar">
|
|
<li><span id="XII">Error signaling of class warning or
|
|
higher (<a href="#error-warning"><b>6.4.2
|
|
Warning/Caution Messages</b></a> , <a href=
|
|
"#error-danger"><b>6.4.3 Danger Messages</b></a>) MUST
|
|
be used to signal the error condition.</span></li>
|
|
|
|
<li><span id="XIII">User agents MAY offer a possibility
|
|
to pin newly encountered certificates to the
|
|
destination.</span></li>
|
|
</ol>
|
|
|
|
<p>Note that, when untrusted certificates are accepted
|
|
without user interaction, an additional exposure to
|
|
man-in-the-middle attacks is created. See <a href=
|
|
"#mitm-initial"><b>8.1 Active attacks during initial TLS
|
|
interactions</b></a> for a more detailed discussion of
|
|
this scenario.</p>
|
|
|
|
<p><span id="XIV">When certificate information is
|
|
presented in the interactions described in this section,
|
|
then human-readable information from certificates MUST
|
|
NOT be presented as trustworthy unless it is attested.
|
|
E.g., a self-signed certificate's Common Name or
|
|
Organization attribute MUST NOT be displayed, even if
|
|
that certificate is pinned to a destination.</span>
|
|
<span id="XV">User agents MAY display this information in
|
|
a dialog or other secondary user interfaces reachable
|
|
from the warning or error messages specified
|
|
here.</span></p>
|
|
|
|
<p><span id="XVI">When, during TLS negotiation, the
|
|
end-entity certificate presented or one of the
|
|
intermediate certificates in the certificate chain are
|
|
found to have been revoked, error signaling of class
|
|
danger (<a href="#error-danger"><b>6.4.3 Danger
|
|
Messages</b></a>) MUST be used.</span></p>
|
|
|
|
<p><span id="XVII">When, during TLS negotiation, the
|
|
end-entity certificate presented or one of the
|
|
intermediate certificates in the certificate chain are
|
|
found to have expired, error signaling of class danger
|
|
(<a href="#error-danger"><b>6.4.3 Danger
|
|
Messages</b></a>) MUST be used.</span></p>
|
|
|
|
<p><span id="XVIII">When the URI corresponding to the
|
|
transaction does not match the end-entity certificate
|
|
presented, and a <a title="" href=
|
|
"#def-validated-cert">validated certificate</a> is used,
|
|
then error signaling of level danger (<a href=
|
|
"#error-danger"><b>6.4.3 Danger Messages</b></a>) MUST be
|
|
used.</span></p>
|
|
|
|
<p><span id="XIX">If TLS negotiation otherwise fails,
|
|
error signaling of level danger (<a href=
|
|
"#error-danger"><b>6.4.3 Danger Messages</b></a>) MUST be
|
|
used.</span></p>
|
|
|
|
<p><span id="XX">When TLS error conditions occur, user
|
|
agents MAY choose to abort the connection without any
|
|
further user interaction.</span> The guidelines in this
|
|
section apply when user agents choose to cause a user
|
|
interaction in the case of TLS error conditions. Note
|
|
that user agents may combine both practices: E.g., an
|
|
interactive approach may be chosen for the top-level
|
|
frame of a Web page, but a non-interactive approach may
|
|
be chosen for inline content. It is expected that the
|
|
XMLHttpRequest specification <a href="#ref-XHR">[XHR]</a>
|
|
will include a non-interactive approach as well.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#errors-blacklists" id="errors-blacklists"
|
|
name="errors-blacklists" class="anchor">5.4.2 Error
|
|
Conditions based on Third Party or Heuristic
|
|
Information</a></h4>
|
|
|
|
<p><span id="XXI">User agents that use third party
|
|
services or heuristic approaches to assess the possible
|
|
danger of a pending Web transaction MUST use error
|
|
signaling of class danger (<a href=
|
|
"#error-danger"><b>6.4.3 Danger Messages</b></a>) to
|
|
signal positively identified dangers, e.g., identified
|
|
malicious downloads or exploits of user agent
|
|
vulnerabilities.</span></p>
|
|
|
|
<p><span id="XXII">To signal risks that are identified
|
|
with high likelihood, but involve further user decisions
|
|
(e.g., phishing heuristics were triggered), error
|
|
signaling of class warning or above (<a href=
|
|
"#error-warning"><b>6.4.2 Warning/Caution
|
|
Messages</b></a> , <a href="#error-danger"><b>6.4.3
|
|
Danger Messages</b></a>) MUST be used.</span></p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#insecure-form-submission" id=
|
|
"insecure-form-submission" name=
|
|
"insecure-form-submission" class="anchor">5.4.3 Insecure
|
|
form submission</a></h4>
|
|
|
|
<p>Users interacting with a <a title="" href=
|
|
"#def-secure-page">TLS-secured page</a> are likely to
|
|
develop the impression that information submitted during
|
|
these interactions will be <a title="" href=
|
|
"#def-strong-tls">strongly TLS-protected</a>. <span id=
|
|
"XXIV">User agents MAY warn users, using an error of
|
|
class Warning or higher (<a href=
|
|
"#error-warning"><b>6.4.2 Warning/Caution
|
|
Messages</b></a> , <a href="#error-danger"><b>6.4.3
|
|
Danger Messages</b></a>), if form submissions from a
|
|
TLS-secured page are directed to an unsecured
|
|
channel.</span></p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#indicators" id="indicators" name="indicators"
|
|
class="anchor">6 Indicators and Interactions</a></h2>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#IdentitySignal" id="IdentitySignal" name=
|
|
"IdentitySignal" class="anchor">6.1 Identity and Trust
|
|
Anchor Signaling</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#identity-requirement" id=
|
|
"identity-requirement" name="identity-requirement" class=
|
|
"anchor">6.1.1 Identity Signal</a></h4>
|
|
|
|
<p><span id="XXV">User agents MUST make information about
|
|
the identity of the Web site that a user interacts with
|
|
available.</span> <span id="XXVI">This [<a name=
|
|
"def-identity-signal" id="def-identity-signal" title=
|
|
"">Definition</a>: <b>identity signal</b> ] SHOULD be
|
|
part of <a title="" href="#def-primary-chrome">primary
|
|
user interface</a> during usage modes which entail the
|
|
presence of signaling to the user beyond only presenting
|
|
page content. Otherwise, it MUST be available through
|
|
secondary user interface.</span> Note that there may be
|
|
usage modes during which this requirement does not apply:
|
|
For example, a Web agent which is interactively switched
|
|
into a presentation mode that does not display any chrome
|
|
need not preserve security indicators in primary user
|
|
interface. On the other hand, a user agent such as a
|
|
smart phone, individual entertainment screen in an
|
|
airplane seat back, or TV set which has a usage mode that
|
|
makes minimal (but visible) chrome elements available
|
|
does need to preserve security indicators in such a
|
|
mode.</p>
|
|
|
|
<p><span id="XXXI">User agents with a visual user
|
|
interface MUST show the Identity Signal in a consistent
|
|
visual position.</span> <span id="XXXII">Web Content MUST
|
|
NOT obscure security user interface, <a href=
|
|
"#robustness-apis-obscure-security-ui"><b>7.4.1 Obscuring
|
|
or disabling Security User Interfaces</b></a>.</span></p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#signal-content" id="signal-content" name=
|
|
"signal-content" class="anchor">6.1.2 Identity Signal
|
|
Content</a></h4>
|
|
|
|
<p><span id="XXXIII">Information displayed in the
|
|
<a title="" href="#def-identity-signal">identity
|
|
signal</a> MUST be derived from <a title="" href=
|
|
"#def-validated-cert">validated certificates</a>, or from
|
|
user agent state.</span> <span id="XXXIV">Web user agents
|
|
MUST NOT use information as part of the <a title="" href=
|
|
"#def-identity-signal">identity signal</a> that is taken
|
|
from unauthenticated or untrusted sources.</span></p>
|
|
|
|
<p>During interactions with a <a title="" href=
|
|
"#def-secure-page">TLS-secured Web page</a> for which the
|
|
top-level resource has been retrieved through a <a title=
|
|
"" href="#def-strong-tls">strongly TLS-protected</a>
|
|
interaction that involves an <a title="" href=
|
|
"#def-augmented-assurance-cert">augmented assurance
|
|
certificate</a>, and for which all dependent resources
|
|
have been retrieved through interactions that involve
|
|
<a title="" href="#def-validated-cert">validated
|
|
certificates</a>, the following applies:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><span id="XXXV">The <a title="" href=
|
|
"#def-identity-signal">identity signal</a> MUST
|
|
include human-readable information about the
|
|
certificate subject, derived as specified in <a href=
|
|
"#sec-evcert"><b>5.1.2 Augmented Assurance
|
|
Certificates</b></a>, to inform the user about the
|
|
owner of the <a title="" href="#def-page">Web
|
|
page</a>.</span></p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>During interactions with a <a title="" href=
|
|
"#def-secure-page">TLS-secured Web page</a> for which the
|
|
top-level resource has been retrieved through a <a title=
|
|
"" href="#def-strong-tls">strongly TLS-protected</a>
|
|
interaction that involves a <a title="" href=
|
|
"#def-validated-cert">validated certificate</a>
|
|
(including an <a title="" href=
|
|
"#def-augmented-assurance-cert">augmented assurance
|
|
certificate</a>), the following applies:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><span id="XXXVI">If the identity signal does not
|
|
include any other human readable information about
|
|
the identity of the certificate subject (derived,
|
|
e.g., from an augmented assurance certificate), then
|
|
it MUST include an applicable DNS name that matches
|
|
either the subject's Common Name attribute or its
|
|
subjectAltName extension.</span> <span id=
|
|
"XXXVII">User agents MAY shorten such a DNS name by
|
|
displaying only a suffix.</span></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><span id="XXXVIII">To inform the user about the
|
|
party responsible for that information, the Issuer
|
|
field's Organization attribute MUST be displayed in
|
|
the Identity Signal, or in secondary user interface
|
|
that is available through a consistent interaction
|
|
with the Identity Signal.</span></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><span id="XXXIX">Subject logotypes <a href=
|
|
"#ref-RFC3709">[RFC3709]</a> derived from
|
|
certificates MUST NOT be rendered, unless the
|
|
certificate used is an <a title="" href=
|
|
"#def-augmented-assurance-cert">augmented assurance
|
|
certificate</a>.</span></p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Note that this behavior does not apply when
|
|
self-signed certificates or certificate chains that chain
|
|
up to an untrusted root certificate are used.</p>
|
|
|
|
<p><span id="XL">During interactions with a <a title=""
|
|
href="#def-mixed-content">mixed content</a> Web page, the
|
|
<a title="" href="#def-identity-signal">identity
|
|
signal</a> MUST NOT include any site identity information
|
|
beyond that which is in use for unprotected HTTP
|
|
transactions.</span> <span id="XLI">In this situation,
|
|
the identity signal MAY include indicators that point out
|
|
any error conditions that occurred.</span></p>
|
|
|
|
<p><span id="XLII">During interactions with mixed
|
|
content, user agents MUST NOT render any logotypes
|
|
<a href="#ref-RFC3709">[RFC3709]</a> derived from
|
|
certificates.</span></p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#pageinfosummary" id="pageinfosummary" name=
|
|
"pageinfosummary" class="anchor">6.2 Additional Security
|
|
Context Information</a></h3>
|
|
|
|
<p><span id="XLIII">This section describes additional
|
|
security context information provided by <a title="" href=
|
|
"#def-user-agent">Web user agents</a>.</span> <span id=
|
|
"XLIV">Where security context information is provided in
|
|
both primary and secondary interface, the meaning of the
|
|
presented information MUST be consistent.</span> Best
|
|
practice will also avoid inconsistent presentation, such as
|
|
using identical or semantically similar icons for different
|
|
information in different places.</p>
|
|
|
|
<p id="asc-must">The information sources MUST make the
|
|
following security context information available:</p>
|
|
|
|
<ol class="enumar">
|
|
<li id="pageinfo-domain"><span id="XLV">the Web page's
|
|
domain name</span></li>
|
|
|
|
<li id="pageinfo-owner"><span id="XLVI">Owner
|
|
information, consistent with section <a href=
|
|
"#signal-content"><b>6.1.2 Identity Signal
|
|
Content</b></a></span></li>
|
|
|
|
<li id="pageinfo-verifier"><span id="XLVII">Verifier
|
|
information, consistent with section <a href=
|
|
"#signal-content"><b>6.1.2 Identity Signal
|
|
Content</b></a></span></li>
|
|
|
|
<li id="pageinfo-trustroots"><span id="XLVIII">The reason
|
|
why the displayed information is trusted (or not).</span>
|
|
This includes whether or not a certificate was <a title=
|
|
"" href="#def-interactively">accepted interactively</a>,
|
|
whether a self-signed certificate was used, and whether
|
|
the self-signed certificate was <a title="" href=
|
|
"#def-pinned-cert">pinned</a> to the site that the user
|
|
interacts with, and whether trust relevant settings of
|
|
the user agent were otherwise overridden through user
|
|
action.</li>
|
|
</ol>
|
|
|
|
<p id="asc-should">The information sources SHOULD make the
|
|
following security context information available:</p>
|
|
|
|
<ol class="enumar">
|
|
<li id="pageinfo-weak"><span id="XLIX">An explanation of
|
|
the information represented by the <a title="" href=
|
|
"#tls-indicator">TLS indicator</a></span>, e.g.,
|
|
concerning the presence mixed content;</li>
|
|
|
|
<li><span id="L">If the Web page is <a title="" href=
|
|
"#def-weak-tls">weakly</a> TLS-protected, then, what
|
|
conditions cause the protection to be weak (e.g., bad
|
|
algorithms, mixed content, ...)</span></li>
|
|
|
|
<li id="pageinfo-history"><span id="LI">Whether the user
|
|
has visited the site in the past.</span></li>
|
|
|
|
<li id="pageinfo-storedcreds"><span id="LII">Whether the
|
|
user has stored credentials for this site.</span></li>
|
|
|
|
<li id="pageinfo-enc"><span id="LIII">Whether the site
|
|
content was encrypted in transmission.</span></li>
|
|
|
|
<li id="pageinfo-auth"><span id="LIV">Whether the site
|
|
content was authenticated (e.g., server authentication
|
|
via TLS).</span></li>
|
|
</ol>
|
|
|
|
<p id="asc-may">Additionally, the information sources MAY
|
|
make the following security context information
|
|
available:</p>
|
|
|
|
<ol class="enumar">
|
|
<li id="pageinfo-when-first"><span id="LVI">When the user
|
|
first visited the site in the past.</span></li>
|
|
|
|
<li id="pageinfo-how-often"><span id="LVII">How often the
|
|
user visited the site in the past.</span></li>
|
|
</ol>
|
|
|
|
<p><span id="LVIII">User agents that provide information
|
|
about the presence or absence of Cookies <a href=
|
|
"#ref-COOKIES">[RFC2965]</a> 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.</span></p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#sec-tls-indicator" id="sec-tls-indicator"
|
|
name="sec-tls-indicator" class="anchor">6.3 TLS
|
|
indicator</a></h3>
|
|
|
|
<p><span id="LIX">User agents MUST make information about
|
|
the state of TLS protection available.</span> <span id=
|
|
"LX">The [<a name="tls-indicator" id="tls-indicator" title=
|
|
"">Definition</a>: <b>TLS indicator</b>] SHOULD be part of
|
|
primary user interface during usage modes which entail the
|
|
presence of signaling to the user beyond only presenting
|
|
page content.</span> <span id="LXI">Otherwise, it MUST be
|
|
available through secondary user interface.</span> As in
|
|
the case of <a href="#identity-requirement"><b>6.1.1
|
|
Identity Signal</b></a>, there may be usage modes during
|
|
which this requirement does not apply. <span id="LXII">Web
|
|
content MUST NOT obscure security interface, see <a href=
|
|
"#robustness-apis-obscure-security-ui"><b>7.4.1 Obscuring
|
|
or disabling Security User Interfaces</b></a>.</span></p>
|
|
|
|
<p><span id="LXV">User agents with a visual user interface
|
|
SHOULD make the TLS indicator available in a consistent
|
|
visual position.</span></p>
|
|
|
|
<p><span id="LXVI">The TLS indicator MUST present a
|
|
distinct state that is used only for <a title="" href=
|
|
"#def-secure-page">TLS-secured</a> Web pages.</span>
|
|
<span id="LXVII">The User Agent SHOULD inform users when
|
|
they are viewing a page that, along with all dependent
|
|
resources, was retrieved through at least <a title="" href=
|
|
"#def-weak-tls">weakly TLS protected</a> transactions,
|
|
including <a title="" href="#def-mixed-content">mixed
|
|
content</a>.</span></p>
|
|
|
|
<p><span id="LXVIII">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).</span></p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#error-handling" id="error-handling" name=
|
|
"error-handling" class="anchor">6.4 Error handling and
|
|
signaling</a></h3>
|
|
|
|
<p>This section defines common error interaction
|
|
requirements and, ordered by increasing severity, practices
|
|
to signal the following classes of errors:</p>
|
|
|
|
<ul>
|
|
<li><a href="#error-warning"><b>6.4.2 Warning/Caution
|
|
Messages</b></a></li>
|
|
|
|
<li><a href="#error-danger"><b>6.4.3 Danger
|
|
Messages</b></a></li>
|
|
</ul>
|
|
|
|
<p><span id="LXIX">User agents MAY communicate additional
|
|
indicators to users. E.g., a user agent could additionally
|
|
display a persistent indicator in a "danger"
|
|
situation.</span></p>
|
|
|
|
<p>For additional security considerations concerning
|
|
frequent warning messages, see <a href=
|
|
"#security-considerations-warning-fatigue"><b>8.5 Warning
|
|
Fatigue</b></a>.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#error-common" id="error-common" name=
|
|
"error-common" class="anchor">6.4.1 Common Error
|
|
Interaction Requirements</a></h4>
|
|
|
|
<p><span id="LXX">Error signaling that occurs as part of
|
|
<a title="" href="#def-primary-chrome">primary user
|
|
interface</a> SHOULD be phrased in terms of threat to
|
|
user's interests, not technical occurrence.</span></p>
|
|
|
|
<p><span id="LXXI"><a title="" href=
|
|
"#def-primary-chrome">Primary user interface</a> error
|
|
messages MUST NOT be phrased solely in terms of
|
|
art.</span> For example, if a certificate includes a DNS
|
|
name in the subjectAltName extension that does not match
|
|
the URI of the site that the user tries to visit, an
|
|
error message can explain that the user is reaching a
|
|
different site, instead of reporting a "subjectAltName
|
|
mismatch".</p>
|
|
|
|
<p><span id="LXXII">They SHOULD NOT tell the user to
|
|
enter the destination site that caused the error, e.g.,
|
|
to provide feedback or obtain assistance.</span>
|
|
<span id="LXXIII">For error messages that interrupt the
|
|
user's flow of interaction, user agents SHOULD enable the
|
|
user to easily return to the page that the user was
|
|
previously interacting with.</span> Note that this
|
|
ideally implies returning to the previous user agent
|
|
state -- including the results of user input and dynamic
|
|
processing --; however, this may not be feasible under
|
|
all circumstances.</p>
|
|
|
|
<p><span id="LXXIV">For advanced users, error
|
|
interactions SHOULD have an option to request a detailed
|
|
description of the condition that caused the error
|
|
interaction to occur.</span></p>
|
|
|
|
<p>The error interactions discussed in this section
|
|
typically involve communication of security context
|
|
information.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#error-warning" id="error-warning" name=
|
|
"error-warning" class="anchor">6.4.2 Warning/Caution
|
|
Messages</a></h4>
|
|
|
|
<p><span id="LXXV">Warning / Caution messages are
|
|
intended for situations when the system has good reason
|
|
to believe that the user may be at risk based on the
|
|
current security context information, but a determination
|
|
cannot positively be made.</span></p>
|
|
|
|
<p><span id="LXXVII">Warning / Caution messages MUST
|
|
interrupt the user's current task, such that the user has
|
|
to acknowledge the message.</span></p>
|
|
|
|
<p><span id="LXXVIII">Warning / Caution messages MUST
|
|
provide the user with distinct options for how to proceed
|
|
(i.e., these messages MUST NOT lead to a situation in
|
|
which the only option presented to the user is to dismiss
|
|
the warning and continue).</span> <span id="LXXIX">The
|
|
options presented on these warnings MUST be descriptive
|
|
to the point that their respective meaning can be
|
|
understood in the absence of any other information
|
|
contained in the warning interaction.</span> <span id=
|
|
"LXXX">One of the options offered SHOULD be recommended,
|
|
and the warning message SHOULD include a succinct text
|
|
component denoting which option is recommended.</span>
|
|
<span id="LXXXI">In the absence of a recommended option,
|
|
the warning MUST present the user with a method of
|
|
finding out more information (e.g., a hyperlink,
|
|
secondary window, etc) if the options cannot be
|
|
understood.</span></p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#error-danger" id="error-danger" name=
|
|
"error-danger" class="anchor">6.4.3 Danger
|
|
Messages</a></h4>
|
|
|
|
<p><span id="LXXXII">Danger Messages are intended for
|
|
situations when there is a positively identified danger
|
|
to the user (i.e., not merely a risk).</span></p>
|
|
|
|
<p><span id="LXXXIII">The interactions communicating
|
|
these messages MUST be designed such that the user's task
|
|
is interrupted.</span></p>
|
|
|
|
<p><span id="LXXXIV">These interactions MUST be presented
|
|
in a way that makes it impossible for the user to go to
|
|
or interact with the destination web site that caused the
|
|
danger situation to occur, without first explicitly
|
|
interacting with the Danger Message.</span></p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#Robustness" id="Robustness" name="Robustness"
|
|
class="anchor">7 Robustness Best Practices</a></h2>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#keepchromevisible-goodpractice" id=
|
|
"keepchromevisible-goodpractice" name=
|
|
"keepchromevisible-goodpractice" class="anchor">7.1 Keep
|
|
Security Chrome Visible</a></h3>
|
|
|
|
<p><span id="LXXXV">For visual user agents, agent chrome
|
|
SHOULD always be present to signal security context
|
|
information.</span> This requirement does not apply when
|
|
user interface is explicitly dismissed by the user.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#site-identifying" id="site-identifying" name=
|
|
"site-identifying" class="anchor">7.2 Do not mix content
|
|
and security indicators</a></h3>
|
|
|
|
<p>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" <a href="#ref-FAVICON">[FAVICON]</a>, which can in
|
|
turn be a simple copy of the very padlock an informed and
|
|
attentive user might look for.</p>
|
|
|
|
<p><span id="LXXXVI">Web User Agents MUST NOT communicate
|
|
positive trust information using user interface elements
|
|
which can be mimicked within chrome under the control of
|
|
web content.</span> <span id="LXXXVII">Site-controlled
|
|
content (e.g. page title, favicon) MAY be hosted in
|
|
chrome</span>, <span id="LXXXVIII">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.</span> This
|
|
requirement applies to both <a title="" href=
|
|
"#def-primary-chrome">primary</a> and <a title="" href=
|
|
"#def-secondary-chrome">secondary</a> elements of visual
|
|
user interfaces.</p>
|
|
|
|
<p><span id="LXXXIX">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.</span></p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#interaction-flooding" id=
|
|
"interaction-flooding" name="interaction-flooding" class=
|
|
"anchor">7.3 Managing User Attention</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>[<a name="whack-a-mole" id="whack-a-mole" title=
|
|
"">Definition</a>: An <b>Interaction flooding attack</b>
|
|
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. ]</p>
|
|
|
|
<p id="prevent-click-thru"><span id="XC">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.</span>
|
|
<span id="XCI">When users interact with security relevant
|
|
notifications (<a href="#error-warning"><b>6.4.2
|
|
Warning/Caution Messages</b></a> and above), Web content
|
|
MUST NOT be granted control of the user agent's
|
|
interaction.</span></p>
|
|
|
|
<p><span id="XCII">A Web User Agent SHOULD NOT display a
|
|
modal security dialog related to a web page which does not
|
|
currently have focus.</span> Security dialogs include
|
|
prompts for user credentials, script errors and TLS
|
|
errors.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#robustness-apis" id="robustness-apis" name=
|
|
"robustness-apis" class="anchor">7.4 APIs Exposed To Web
|
|
Content</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#robustness-apis-obscure-security-ui" id=
|
|
"robustness-apis-obscure-security-ui" name=
|
|
"robustness-apis-obscure-security-ui" class=
|
|
"anchor">7.4.1 Obscuring or disabling Security User
|
|
Interfaces</a></h4>
|
|
|
|
<p id="prevent-obscuring"><span id="XCIII"><a title=""
|
|
href="#def-user-agent">Web user agents</a> MUST prevent
|
|
web content from obscuring, hiding, or disabling user
|
|
interfaces that display security context information,
|
|
except in response to a user interaction.</span></p>
|
|
|
|
<p id="restrict-window-resizing"><span id="XCIV">User
|
|
agents MUST restrict window sizing and moving operations
|
|
consistent with section <a href=
|
|
"#keepchromevisible-goodpractice"><b>7.1 Keep Security
|
|
Chrome Visible</b></a>.</span> This prevents attacks
|
|
wherein agent chrome is obscured by moving it off the
|
|
edges of the visible screen.</p>
|
|
|
|
<p id="prevent-new-windows"><span id="XCV">User agents
|
|
MUST NOT allow web content to open new windows with the
|
|
agent's security UI hidden.</span> Allowing this
|
|
operation facilitates picture-in-picture attacks, where
|
|
artificial chrome (usually indicating a positive security
|
|
state) is supplied by the web content in place of the
|
|
hidden UI.</p>
|
|
|
|
<p id="prevent-overlaying-chrome"><span id="XCVI">User
|
|
agents MUST prevent web content from overlaying
|
|
chrome.</span> This helps to ensure that user
|
|
interactions that are perceived to target agent chrome
|
|
are not redirected to Web applications.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#robustness-software-install" id=
|
|
"robustness-software-install" name=
|
|
"robustness-software-install" class="anchor">7.4.2
|
|
Software Installation</a></h4>
|
|
|
|
<p>This section covers web user agent APIs that allow web
|
|
content to download software for later execution outside
|
|
of the web user agent context.</p>
|
|
|
|
<p id="prevent-api-exposure"><span id="XCVII"><a title=""
|
|
href="#def-user-agent">Web user agents</a> MUST NOT
|
|
expose programming interfaces which permit installation
|
|
of software without a user intervention.</span></p>
|
|
|
|
<p id="prevent-installation"><span id="XCVIII">User
|
|
agents MUST inform the user and request consent when the
|
|
user agent is attempting to install software outside of
|
|
the agent environment as a result of web content.</span>
|
|
<span id="XCIX">The interaction used MUST follow the
|
|
requirements in <a href="#error-warning"><b>6.4.2
|
|
Warning/Caution Messages</b></a> .</span> <span id=
|
|
"C">User agents SHOULD NOT provide features which can be
|
|
used by web content to install software outside of the
|
|
agent environment without the user's consent.</span></p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#robustness-bookmarks" id=
|
|
"robustness-bookmarks" name="robustness-bookmarks" class=
|
|
"anchor">7.4.3 Bookmarking APIs</a></h4>
|
|
|
|
<p>User agents often include features that enable Web
|
|
content to update the user's bookmarks, e.g. through an
|
|
ECMAScript API. If permitted unchecked, these features
|
|
can serve to confuse users by, e.g., placing a bookmark
|
|
that goes by the same name as the user's bank, but points
|
|
to an attacker's site.</p>
|
|
|
|
<p id="bookmark-api-userconsent"><span id=
|
|
"CIII"><a title="" href="#def-user-agent">Web user
|
|
agents</a> MUST NOT permit Web content to add bookmarks
|
|
without explicit user consent.</span></p>
|
|
|
|
<p id="bookmark-api-uri-match"><span id="CIV"><a title=""
|
|
href="#def-user-agent">Web user agents</a> MUST NOT
|
|
permit Web content to add URIs to the user's bookmark
|
|
collection that do not match the URI of the page that the
|
|
user currently interacts with.</span></p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a href="#popups" id="popups" name="popups" class=
|
|
"anchor">7.4.4 Pop-up Window APIs</a></h4>
|
|
|
|
<p id="prevent-newwindows"><span id="CV">With visual user
|
|
interfaces that use a windowed interaction paradigm, User
|
|
agents SHOULD restrict the opening of pop-up windows from
|
|
web content, particularly those not initiated by user
|
|
action.</span> Creating excessive numbers of new pop-up
|
|
windows is a technique that can be used to condition
|
|
users to rapidly dismissing dialogs. This can be employed
|
|
in <a title="" href="#whack-a-mole">interaction flooding
|
|
attacks</a>.</p>
|
|
|
|
<p id="offer-extended-perm"><span id="CVI">User agents
|
|
which offer this restriction SHOULD offer a way to extend
|
|
permission to individual trusted sites.</span> Failing to
|
|
do so encourages users who desire the functionality on
|
|
certain sites to disable the feature universally.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#security-considerations" id=
|
|
"security-considerations" name="security-considerations"
|
|
class="anchor">8 Security Considerations</a></h2>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#mitm-initial" id="mitm-initial" name=
|
|
"mitm-initial" class="anchor">8.1 Active attacks during
|
|
initial TLS interactions</a></h3>
|
|
|
|
<p>Section <a href="#sec-tlserrors"><b>5.4.1 TLS
|
|
errors</b></a> leads to additional exposure during the
|
|
<em>first</em> 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
|
|
dialog 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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p><a href="#sec-tlserrors"><b>5.4.1 TLS errors</b></a>
|
|
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.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#cert-status-check-failures" id=
|
|
"cert-status-check-failures" name=
|
|
"cert-status-check-failures" class="anchor">8.2 Certificate
|
|
Status Checking Failures</a></h3>
|
|
|
|
<p>The TLS Errors (<a href="#sec-tlserrors"><b>5.4.1 TLS
|
|
errors</b></a>) section does not document intended behavior
|
|
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 <a href=
|
|
"#ref-ocsp">[RFC2560]</a> status checking is fragile and
|
|
subject to frequent failures, so it is inappropriate to
|
|
require that user agents 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 (<a href="#error-warning"><b>6.4.2
|
|
Warning/Caution Messages</b></a> ) or danger (<a href=
|
|
"#error-danger"><b>6.4.3 Danger Messages</b></a>) level
|
|
messages; or refusal to load sites that fail these
|
|
checks.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#certs-assure-identity" id=
|
|
"certs-assure-identity" name="certs-assure-identity" class=
|
|
"anchor">8.3 Certificates assure identity, not
|
|
security</a></h3>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#security-considerations-petnames" id=
|
|
"security-considerations-petnames" name=
|
|
"security-considerations-petnames" class="anchor">8.4
|
|
Binding "human readable" names to domain names</a></h3>
|
|
|
|
<p>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 <a href=
|
|
"#ref-petnames">[PETNAMES]</a>).</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#security-considerations-warning-fatigue" id=
|
|
"security-considerations-warning-fatigue" name=
|
|
"security-considerations-warning-fatigue" class=
|
|
"anchor">8.5 Warning Fatigue</a></h3>
|
|
|
|
<p>Requirements in this document often involve warning
|
|
(<a href="#error-warning"><b>6.4.2 Warning/Caution
|
|
Messages</b></a> and <a href="#error-danger"><b>6.4.3
|
|
Danger Messages</b></a>) 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.</p>
|
|
|
|
<p>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").</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#security-considerations-ev-dv" id=
|
|
"security-considerations-ev-dv" name=
|
|
"security-considerations-ev-dv" class="anchor">8.6 Mixing
|
|
Augmented Assurance and Validated Certificates</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <em>using validated
|
|
certificates</em>.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a href="#dynamic-content" id="dynamic-content" name=
|
|
"dynamic-content" class="anchor">8.7 Dynamic content might
|
|
change security properties</a></h3>
|
|
|
|
<p>This specification is expressed in terms of the
|
|
fundamentally static indicators of existing agent security
|
|
user interfaces.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>For TLS-protected HTTP requests caused using the
|
|
XMLHttpRequest API <a href="#ref-XHR">[XHR]</a> <a href=
|
|
"#ref-XHRl2">[XHR2]</a>, 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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#Terms" id="Terms" name="Terms" class="anchor">9
|
|
Terms defined in this document</a></h2>
|
|
|
|
<ul>
|
|
<li><a title="" href="#conformance-advanced">advanced
|
|
level</a></li>
|
|
|
|
<li><a title="" href=
|
|
"#def-augmented-assurance-cert">Augmented Assurance
|
|
Certificate</a></li>
|
|
|
|
<li><a title="" href="#conformance-basic">basic
|
|
level</a></li>
|
|
|
|
<li><a title="" href="#def-chrome">chrome</a></li>
|
|
|
|
<li><a title="" href="#def-http-transaction">HTTP
|
|
transaction</a></li>
|
|
|
|
<li><a title="" href="#def-identity-information">Identity
|
|
Information</a></li>
|
|
|
|
<li><a title="" href="#def-identity-signal">identity
|
|
signal</a></li>
|
|
|
|
<li><a title="" href="#whack-a-mole">Interaction flooding
|
|
attack</a></li>
|
|
|
|
<li><a title="" href="#def-interactively">interactively
|
|
accepted</a></li>
|
|
|
|
<li><a title="" href="#def-locationbar">Location
|
|
Bar</a></li>
|
|
|
|
<li><a title="" href="#def-mixed-content">mixed
|
|
content</a></li>
|
|
|
|
<li><a title="" href="#def-pinned-cert">pinning</a></li>
|
|
|
|
<li><a title="" href="#def-plug-in">plug-ins</a></li>
|
|
|
|
<li><a title="" href="#def-primary-chrome">Primary User
|
|
Interface</a></li>
|
|
|
|
<li><a title="" href="#def-secondary-chrome">Secondary User
|
|
Interface</a></li>
|
|
|
|
<li><a title="" href="#def-strong-algos">Strong TLS
|
|
algorithms</a></li>
|
|
|
|
<li><a title="" href="#def-strong-tls">strongly
|
|
TLS-protected</a></li>
|
|
|
|
<li><a title="" href="#tls-indicator">TLS
|
|
indicator</a></li>
|
|
|
|
<li><a title="" href=
|
|
"#def-tls-protected">TLS-protected</a></li>
|
|
|
|
<li><a title="" href=
|
|
"#def-secure-page">TLS-secured</a></li>
|
|
|
|
<li><a title="" href="#def-validated-cert">validated
|
|
certificate</a></li>
|
|
|
|
<li><a title="" href="#def-weak-tls">weakly
|
|
TLS-protected</a></li>
|
|
|
|
<li><a title="" href="#def-page">Web Page</a></li>
|
|
|
|
<li><a title="" href="#def-user-agent">Web User
|
|
Agent</a></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a href="#Ref" id="Ref" name="Ref" class="anchor">10
|
|
References</a></h2>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="ref-ECRYPT-report" id=
|
|
"ref-ECRYPT-report"></a>ECRYPT2009</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ecrypt.eu.org/documents/D.SPA.7.pdf"><cite>ECRYPT2
|
|
Yearly Report on Algorithms and Key Lengths (2009
|
|
Edition)</cite></a>, available at
|
|
http://www.ecrypt.eu.org/documents/D.SPA.7.pdf .</dd>
|
|
|
|
<dt class="label"><a name="ref-EV" id=
|
|
"ref-EV"></a>EVTLSCERT</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.cabforum.org/EV_Certificate_Guidelines.pdf"><cite>
|
|
Guidelines for the Issuance and Management of Extended
|
|
Validation Certificates</cite></a>, CA/Browser Forum, 7
|
|
June 2007, available at
|
|
http://www.cabforum.org/EV_Certificate_Guidelines.pdf
|
|
.</dd>
|
|
|
|
<dt class="label"><a name="ref-FAVICON" id=
|
|
"ref-FAVICON"></a>FAVICON</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/2005/10/howto-favicon"><cite>How to Add
|
|
a Favicon to your Site</cite></a>, D. Hazaël-Massieux, C.
|
|
Lilley, O. Théreaux, W3C work in progress, available at
|
|
http://www.w3.org/2005/10/howto-favicon .</dd>
|
|
|
|
<dt class="label"><a name="ref-gutmann-kcm" id=
|
|
"ref-gutmann-kcm"></a>KCM</dt>
|
|
|
|
<dd><a href=
|
|
"http://tools.ietf.org/id/draft-gutmann-keycont-01.txt"><cite>
|
|
Key Management through Key Continuity (KCM)</cite></a>,
|
|
(Expired) Internet Draft, September 2008, Peter Gutmann.
|
|
This draft is available at
|
|
http://tools.ietf.org/id/draft-gutmann-keycont-01.txt
|
|
.</dd>
|
|
|
|
<dt class="label"><a name="ref-NESSIE-report" id=
|
|
"ref-NESSIE-report"></a>NESSIE</dt>
|
|
|
|
<dd><a href=
|
|
"https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf">
|
|
<cite>Portfolio of recommended cryptographic primitives,
|
|
New European Schemes for Signatures, Integrity, and
|
|
Encryption (NESSIE)</cite></a>, available at
|
|
https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf
|
|
.</dd>
|
|
|
|
<dt class="label"><a name="ref-petnames" id=
|
|
"ref-petnames"></a>PETNAMES</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.hpl.hp.com/techreports/2005/HPL-2005-148.html"><cite>
|
|
Petname Systems</cite></a>, HPL-2005-148, Mark Stiegler,
|
|
August 2005. This report is available at
|
|
http://www.hpl.hp.com/techreports/2005/HPL-2005-148.html
|
|
.</dd>
|
|
|
|
<dt class="label"><a name="ref-PKIX" id=
|
|
"ref-PKIX"></a>PKIX</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc5280.txt"><cite>Internet X.509
|
|
Public Key Infrastructure Certificate and Certificate
|
|
Revocation List (CRL) Profile</cite></a>, RFC 5280, D.
|
|
Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W.
|
|
Polk, May 2008, available at
|
|
http://www.ietf.org/rfc/rfc5280.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-RFC2119" id=
|
|
"ref-RFC2119"></a>RFC2119</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key
|
|
words for use in RFCs to Indicate Requirement
|
|
Levels</cite></a>, RFC 2119, S. Bradner, March 1997,
|
|
available at http://www.ietf.org/rfc/rfc2119.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-ocsp" id=
|
|
"ref-ocsp"></a>RFC2560</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc2560.txt"><cite>X.509 Internet
|
|
Public Key Infrastructure Online Certificate Status
|
|
Protocol - OCSP</cite></a>, RFC 2560, M. Myers, R. Ankney,
|
|
A. Malpani, S. Galperin, C. Adams, June 1999. This
|
|
specification is available at
|
|
http://www.ietf.org/rfc/rfc2560.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-RFC2616" id=
|
|
"ref-RFC2616"></a>RFC2616</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext
|
|
Transfer Protocol -- HTTP/1.1</cite></a>, RFC 2616, R.
|
|
Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
|
|
Leach, T. Berners-Lee, June 1999, available at
|
|
http://www.ietf.org/rfc/rfc2616.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-RFC2817" id=
|
|
"ref-RFC2817"></a>RFC2817</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc2817.txt"><cite>Upgrading to
|
|
TLS Within HTTP/1.1</cite></a>, RFC 2817, R. Khare, S.
|
|
Lawrence, May 2000, available at
|
|
http://www.ietf.org/rfc/rfc2817.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-RFC2818" id=
|
|
"ref-RFC2818"></a>RFC2818</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc2818.txt"><cite>HTTP Over
|
|
TLS</cite></a>, RFC 2818, E. Rescorla, May 2000, available
|
|
at http://www.ietf.org/rfc/rfc2818.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-COOKIES" id=
|
|
"ref-COOKIES"></a>RFC2965</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc2965.txt"><cite>HTTP State
|
|
Management Mechanism</cite></a>, RFC 2965, D. Kristol, L.
|
|
Montulli, October 2000, available at
|
|
http://www.ietf.org/rfc/rfc2965.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-RFC3709" id=
|
|
"ref-RFC3709"></a>RFC3709</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc3709.txt"><cite>Internet X.509
|
|
Public Key Infrastructure: Logotypes in X.509
|
|
Certificates</cite></a>, RFC 3709, S. Santeson, R. Housley,
|
|
T. Freeman, February 2004, available at
|
|
http://www.ietf.org/rfc/rfc3709.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-URI" id=
|
|
"ref-URI"></a>RFC3986</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform
|
|
Resource Identifier (URI): Generic Syntax"</cite></a>, RFC
|
|
3986, T. Berners-Lee, R. Fielding, L. Masinter, January
|
|
2005, available at http://www.ietf.org/rfc/rfc3986.txt
|
|
.</dd>
|
|
|
|
<dt class="label"><a name="ref-sslv3" id=
|
|
"ref-sslv3"></a>SSLv3</dt>
|
|
|
|
<dd><a href=
|
|
"http://web.archive.org/web/20080208141212/http://wp.netscape.com/eng/ssl3/">
|
|
<cite>SSLv3 specification</cite></a>, Netscape, November
|
|
1996. This specification is archived at
|
|
http://web.archive.org/web/20080208141212/http://wp.netscape.com/eng/ssl3/
|
|
.</dd>
|
|
|
|
<dt class="label"><a name="ref-tlsv11" id=
|
|
"ref-tlsv11"></a>TLSv11</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc4346.txt"><cite>The
|
|
Transport Layer Security (TLS) Protocol</cite></a>, RFC
|
|
4346, T. Dierks, E. Rescorla, April 2006. This
|
|
specification is available at
|
|
http://www.ietf.org/rfc/rfc4346.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-tlsv12" id=
|
|
"ref-tlsv12"></a>TLSv12</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc5246.txt"><cite>The
|
|
Transport Layer Security (TLS) Protocol Version
|
|
1.2</cite></a>, RFC 5246, T. Dierks, E. Rescorla, August
|
|
2008. This specification is available at
|
|
http://www.ietf.org/rfc/rfc5246.txt .</dd>
|
|
|
|
<dt class="label"><a name="ref-WCAG2" id=
|
|
"ref-WCAG2"></a>WCAG20</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2008/REC-WCAG20-20081211/"><cite>Web
|
|
Content Accessibility Guidelines 2.0</cite></a>, B.
|
|
Caldwell, M. Cooper, L. G. Reid, G. Vanderheiden (eds.),
|
|
W3C Recommendation 11 December 2008. This version is
|
|
http://www.w3.org/TR/2008/REC-WCAG20-20081211/ . The
|
|
<a href="http://www.w3.org/TR/WCAG20/">latest version of
|
|
WCAG 2.0</a> is available at http://www.w3.org/TR/WCAG20/
|
|
.</dd>
|
|
|
|
<dt class="label"><a name="ref-wsc-threats" id=
|
|
"ref-wsc-threats"></a>WSC-THREATS</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2007/NOTE-wsc-threats-20071101/"><cite>
|
|
Web User Interaction: Threat Trees</cite></a>, T. Roessler
|
|
(ed), W3C Working Group Note (work in progress) 1 November
|
|
2007. This version is
|
|
http://www.w3.org/TR/2007/NOTE-wsc-threats-20071101". The
|
|
<a href="http://www.w3.org/TR/wsc-threats/">latest
|
|
version</a> is available at
|
|
http://www.w3.org/TR/wsc-threats/ .</dd>
|
|
|
|
<dt class="label"><a name="ref-wsc-usecases" id=
|
|
"ref-wsc-usecases"></a>WSC-USECASES</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/"><cite>
|
|
Web Security Experience, Indicators and Trust: Scope and
|
|
Use Cases</cite></a>, T. Close, Editor, W3C Working Group
|
|
Note (work in progress) 06 March 2008. This version is
|
|
http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/ . The
|
|
<a href="http://www.w3.org/TR/wsc-usecases/">latest
|
|
version</a> is available at
|
|
http://www.w3.org/TR/wsc-usecases/ .</dd>
|
|
|
|
<dt class="label"><a name="ref-XHR" id=
|
|
"ref-XHR"></a>XHR</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/XMLHttpRequest/"><cite>XMLHttpRequest</cite></a>.
|
|
A. van Kesteren (ed.), W3C Working Draft (Work in Progress)
|
|
19 November 2009. This version of the XMLHttpRequest
|
|
specification is at
|
|
http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/ . The
|
|
<a href="http://www.w3.org/TR/XMLHttpRequest/">latest
|
|
version</a> of this specification is available at
|
|
http://www.w3.org/TR/XMLHttpRequest/ .</dd>
|
|
|
|
<dt class="label"><a name="ref-XHRl2" id=
|
|
"ref-XHRl2"></a>XHR2</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/XMLHttpRequest2/"><cite>XMLHttpRequest
|
|
Level 2</cite></a>. A. van Kesteren (ed.), W3C Working
|
|
Draft (Work in Progress) 20 August September 2009. This
|
|
version of the XMLHttpRequest Level 2 specification is at
|
|
http://www.w3.org/TR/2009/WD-XMLHttpRequest2-20090820/ .
|
|
The <a href=
|
|
"http://tools.ietf.org/id/draft-gutmann-keycont-01.txt">latest
|
|
version</a> of this specification is available at
|
|
http://www.w3.org/TR/XMLHttpRequest2/ .</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|