Web PKI OPPS B. Wilson
Internet Draft Digicert
Intended status: Informational S. Chokhani
Expires: January 2015 Cygnacom
R. Alden
Comodo
July 22, 2014
Browser processing of server certificates
draft-wilson-wpkops-browser-processing-02.txt
Abstract
This is one of a set of documents to define the operation of the Web
PKI. It describes common variations in browser behavior related to
processing server certificates.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 23, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Wilson, et al. Expires January 23, 2015 [Page 1]
Internet-Draft Browser processing of server certificates July 2014
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
1.1. Definitions...............................................3
1.2. Scope.....................................................4
1.3. Document Organization.....................................5
2. Certification Path Development.................................6
2.1. Basic Requirements........................................6
2.2. Additional Requirements...................................7
2.3. Browser/Cryptolibrary Observations........................7
2.4. Security Considerations...................................8
2.5. Areas for Future Work.....................................8
3. Certification Path Validation..................................9
3.1. Basic Requirements (based on RFC 5280)....................9
3.2. Additional Requirements..................................10
3.3. Browser Observations.....................................10
3.3.1. Path Validation.....................................10
3.3.1.1. Signature Verification.........................10
3.3.1.2. Name Constraints...............................11
3.3.2. Current Time within Validity Period.................12
3.3.3. Public Key Parameters...............................12
3.3.3.1. Sizes..........................................12
3.3.3.2. Algorithms and Cipher Suites...................13
3.4. Security Considerations..................................13
3.5. Areas for Future Work....................................13
4. Server certificate processing.................................14
4.1. Subject Names............................................14
4.2. Wildcard character.......................................15
4.3. Key Usage Extension......................................16
4.4. Security Considerations..................................16
4.5. Areas for Future Work....................................16
5. Browser Human Interface (Visual) Indicators...................17
5.1. Visual indicators........................................17
5.2. Positive visual indicators...............................17
5.3. Negative visual indicators...............................17
5.4. Message boxes, dialog boxes and error pages..............18
5.5. Certificate viewers......................................18
5.6. Certification Path Development and Validation Indication.18
5.7. Configurables............................................19
Wilson, et al. Expires January 23, 2015 [Page 2]
Internet-Draft Browser processing of server certificates July 2014
5.8. Security Considerations..................................19
5.9. Areas for Future Work....................................19
6. IANA Considerations...........................................19
7. Security Considerations.......................................20
8. Normative References..........................................20
1. Introduction
This document reviews the current processing behaviors of
cryptolibraries, and the browsers they support, with respect to
SSL/TLS session establishment between a server and a browser,
including signature verification, certificate parsing, chain
processing, and other non-revocation-checking processes described in
RFC 5280 and the SSL/TLS protocol.
The information presented in this document is based on user
experience and should not be construed as exhaustive. In other
words, it is based on observed behavior and is not based on any
comprehensive testing. The product vendors and reviewers are
encouraged to provide additional information that sheds light on the
observations made in this document or to provide additional
observations.
This document does not address future changes to the implemented
trust model.
1.1. Definitions
PKI terminology is as defined in RFC 5280. Other definitions are
defined below for interpretation of this document.
Behavior - The observed action or activity of a browser based on a
set of conditions or circumstances.
Blacklist - A group, set, or list of data objects created to
explicitly prevent them from being used because they are unsafe or
obsolete.
Block - A behavior in which the browser detects an abnormal condition
and halts (or technically cannot complete) session negotiation and
drops the connection or otherwise blocks the user from continuing.
Wilson, et al. Expires January 23, 2015 [Page 3]
Internet-Draft Browser processing of server certificates July 2014
Bypassable error - A behavior in which the browser detects an
abnormal condition and asks the user whether to proceed with (i.e.
click-through to) the SSL/TLS connection.
Fail open - A behavior in which the browser is unable to successfully
complete a certificate-checking process, but provides the content.
Internationalized Name - The Punycode-encoded ASCII representation of
Unicode characters prefaced with the ASCII Compatible Encoding (ACE)
prefix, xn--.
Name mismatch - A condition detected by a browser in which no name in
the common name or subject alternative name for the subject in the
certificate matches the hostname sought by the client (i.e. the
client's reference identity - usually a Fully Qualified Domain Name -
is not in the certificate).
Pinned - A condition in which the association between two or more
aspects of the entity-public-key relationship (e.g. server name,
public key, CA, certificate) are configured and set in the browser
before initiation of a TCP connection.
Stapled - A condition in which information related to the server's
certificate (e.g. OCSP response) is delivered by the server to the
client as part of the SSL/TLS handshake, and not by direct
communication with the issuing CA. Not all browsers request stapled
responses. Since OCSP stapling is directly related to revocation,
discussion of OCSP stapling is outside the scope of this document.
Visual indicator - A behavior in which the browser changes the
color(s) and/or intensity of pixels on a screen in the browser chrome
to indicate a changed condition. Visual indicators also include
error pages, pop-up dialogs, and warning messages.
Wildcard character - An asterisk - * (Unicode 2A).
1.2. Scope
The scope of this document excludes revocation checking. Revocation
checking is addressed in another document.
This document currently treats as out-of-scope browser behavior for
client authentication TLS. In a future version it might address
behavior when a legitimate client certificate is not selected or
presented under certain circumstances, such as when the browser and
the TLS Server have different trust anchors.
Wilson, et al. Expires January 23, 2015 [Page 4]
Internet-Draft Browser processing of server certificates July 2014
This document also does not address lesser-used X.509 certificate
extensions: issuer alternative name; subject directory attribute;
policy constraint; inhibit any policy; and subject information
access.
Also, because revocation checking is out of scope, the discussion of
the following extensions is out of scope: CRL Distribution Point;
Freshest CRL; and OCSP field in the Authority Information Access
extension. OCSP stapling support is addressed in another document.
This document reviews some of the certificate-processing features of
the following cryptolibraries: Network Security Services (NSS), in
two code sets, Classic (NSS-Classic) and PKIX (NSS-PKIX); Microsoft
Crypto API (MS-CAPI); OpenSSL; and Apple's Cryptographic,
Certificate, Key, and Trust Services (A-CKTS). Thus, it examines the
behavior of Internet Explorer, on Windows 7/8 relying on MS-CAPI;
Mozilla Firefox, relying on NSS; Apple Safari, relying on A-CKTS; and
Opera and Google Chrome, relying on MS-CAPI, A-CKTS, or NSS, as the
case may be.
Mobile platforms, such as Android, iOS, and Windows Mobile, are also
addressed as information becomes available.
1.3. Document Organization
This Section 1 provides a brief introduction to the non-revocation-
checking processes implemented in cryptolibraries and by browsers.
Section 2 describes the requirements for certification path
development in order to establish trust in the server public key.
Section 2 also contains the nuances of cryptolibraries and popular
browsers, in terms of their ability to meet these requirements and
security implications of these nuances.
Section 3 describes requirements for certification path validation in
order to establish trust in the server public key. Section 3 also
contains the nuances of cryptolibraries and popular browsers in terms
of their ability to meet these requirements and security implications
of these nuances.
Section 4 describes the requirements for processing the Server
certificate. Section 4 also contains the nuances of cryptolibraries
and popular browsers in terms of their ability to meet these
requirements and security implications of these nuances.
Section 5 describes the browser user interface indicators.
Wilson, et al. Expires January 23, 2015 [Page 5]
Internet-Draft Browser processing of server certificates July 2014
Section 6 lists IANA Considerations.
Section 7 summarizes Security Considerations discussed throughout
this document.
Section 8 contains references.
2. Certification Path Development
2.1. Basic Requirements
This section discusses sources of certificate information that are
available to browsers to assist in certification path development, as
described in RFC 5280. The purpose of X.509 path validation is to
ensure that the subject distinguished name or subject alternative
name in a certificate and the named subject's public key are
appropriately bound by a CA that chains up to the public key of a
trust anchor used by the browser. The path validation algorithm does
this by processing a sequence of certificates that support that
binding. While RFC 5280 requires that browsers process certification
chains in accordance with the path validation algorithm, it does not
specify a procedure by which a browser should construct that
certification path. (RFC 4158 provides additional guidance on
factors to consider when building a certification path.)
Root stores are not fixed. Not only can they be extended via
automatic download, but enterprises can add and remove roots through
group policies, and most end users can manually add or remove root
certificates. Browsers have or obtain root certificates used to
identify the trust anchors for a server's certification path.
Candidate trust anchors are available locally in root stores
(maintained by the browser, cryptolibrary, or operating system) or
via automatic download from a remote system. Most systems also allow
users to further adjust trust anchors with other configuration
changes, such as allowing users to enable or disable potential key
usages by checking or unchecking them for each certificate found in
the root store. For instance, Firefox provides three options
(identify websites, identify mail users, and identify software
makers), while the Apple key chain provides ten key usages to select
from, and Microsoft offers nearly fifty.
Browsers also use their local caches of certificates for
certification path development.
Wilson, et al. Expires January 23, 2015 [Page 6]
Internet-Draft Browser processing of server certificates July 2014
Browser use the certificates sent by the TLS Server in the TLS
handshake for certification path development.
Some browsers use the caIssuers field in the Authority Information
Access extension of a certificate to obtain, over unsecure HTTP or
LDAP, the intermediary CA's certificate in order to build the
certification path. Some browsers are able to process LDAP
pointers to caCertificate or crossCertificatePair attributes and also
handle HTTP single certificate payloads and multiple certificate
payloads, as described in RFC 5280.
Assuming that the browser has obtained a set of certificates that can
be used to form a certificate chain, section 4.2.1 of RFC 5280 sets
forth how the authorityKeyIdentifier and the subjectKeyIdentifier
standard extensions can also be used to select appropriate
certificate when multiple choices exist. Most browsers process these
extensions as part of certification path construction. Similarly,
most browsers also match the issuer name with the subject name of the
issuer's certificate as the chain is constructed up to the trust
anchor.
2.2. Additional Requirements
None
2.3. Browser/Cryptolibrary Observations
All browsers and cryptolibraries examined were able to perform
certificate path validation when the server presented the browser
with a properly ordered certificate chain--where the first certificate
was the end entity's "leaf" certificate, followed by the issuer CA's
certificate. However, because a misconfigured server might present a
root certificate in the middle of a chain, some cryptolibraries are
able to construct certificate paths by re-ordering certificates
presented by a server. (There are free tools available to test
whether a server is presenting a complete and well-ordered chain.)
Also, however, some servers are misconfigured and only provide the
leaf certificate and not a necessary intermediate CA certificate. In
these cases, a browser is unable to determine whether the certificate
chains to a trusted root. In these cases, the browsers indicate that
the site, the connection, or the server is untrusted. Some warning
Wilson, et al. Expires January 23, 2015 [Page 7]
Internet-Draft Browser processing of server certificates July 2014
messages indicate that the certificate was not issued by a trusted
CA.
Some browsers are able to store intermediate CA certificates
permanently or in cache, so they do not need to obtain the
intermediate CAs every time.
Some leaf certificates have a caIssuers field in the Authority
Information Access extension. The purpose of the caIssuers field is
to provide a URI pointer to the Intermediate CA's certificate. All
browsers except for Firefox are able to use the caIssuers AIA to
obtain the intermediate certificate and construct a chain. Because
NSS does not process the caIssuers AIA, Mozilla Firefox is unable to
construct a chain. When a path cannot be built, Firefox presents a
negative visual indication as a bypassable error as described in
Section 5.6. It is the authors' understanding that the Mozilla
community intentionally chose this behavior instead of processing the
caIssuers AIA because Firefox will alert server administrators about
defective chains and they can install missing CA certificates absent
from certificate chains. However, Chrome, which uses NSS, has chosen
to implement its own http-fetching ability to obtain missing
intermediate CA certificates.
2.4. Security Considerations
A browser's inability to create a path to a trust anchor leads to
uncertainty on the part of end users and may leave them more
vulnerable to man-in-the-middle attacks because they are unable to
determine whether the public key presented corresponds to the key
pair of the server that they intend to reach.
2.5. Areas for Future Work
Inputs are sought from the working group participants and vendors to
identify additional methods used and to gain understanding on browser
handling of misconfigured server-provided chains when an intermediate
CA certificate is available locally to the client.
Wilson, et al. Expires January 23, 2015 [Page 8]
Internet-Draft Browser processing of server certificates July 2014
3. Certification Path Validation
3.1. Basic Requirements (based on RFC 5280)
Browsers use one or more trust anchors from their root stores for
certification path validation.
The primary mechanism used to perform certification path validation
in accordance with Section 6 of RFC 5280 is verifying the signature
on the certificate. Much has been written on the process of
signature verification, which requires processing the tbsCertificate
and signatureValue fields using the signature algorithm and issuer
public key to verify that the certificate was properly signed. DSA,
RSA, and ECDSA are common digital signature algorithms used to sign
certificates in conjunction with hashing algorithms such as MD5,
RIPEMD-160, SHA-1, SHA-256, SHA-384, SHA-512, and Whirlpool. Thus, a
browser might need to be able to perform the signature verification
process using a variety of signature and hashing algorithms.
The following extensions described in RFC 5280 are also relevant to
certification path validation:
. The basicConstraints extension indicates whether the
certificate is for a CA or an end entity, and if for a CA, it
can include a path length constraint intended to limit the
maximum depth for the certification path from the certificate
(i.e. the allowed number of subordinate CA levels between it and
an end entity certificate). Presumably, a browser would check
whether the issuer's certificate included the basicConstraints
extension where CA=true and whether the certification path
complied with any path length constraint in the basicConstraints
extension.
. The key usage extension is a bit string of 9 bits (0 through 8)
that indicates the intended key usage. When Bit 5 is enabled,
it indicates that the public key in the intermediate CA
certificate may be used to validate signatures on certificates.
Presumably a browser would examine whether a CA's certificate
signing bit was set.
. The name constraints extension is a multi-valued field in a CA
certificate that indicates the intended scope of certificates,
in terms of name spaces, that are either allowed or prohibited
to be issued by that CA. This directive is honored by the
browser processing the subject DN and subject alternative names
in certificates issued by the CA and determining whether the
domain names in those subject fields fall within any stated
Wilson, et al. Expires January 23, 2015 [Page 9]
Internet-Draft Browser processing of server certificates July 2014
restriction (e.g. a permitted or an excluded name subtree).
(See Section 4.2.1.10 and Section 6 of RFC 5280.)
3.2. Additional Requirements
None.
3.3. Browser Observations
3.3.1. Path Validation
As mentioned in Section 2.3, online tools can be used to ensure that
servers are presenting complete, well-ordered chains, and server
administrators should do this to ensure the most efficient
certificate path processing. When a misconfigured server delivers a
shuffled group of certificates, some platforms are unable to perform
certification path validation, while other platforms are able to
perform validation because they implement a more robust path-building
process.
3.3.1.1. Signature Verification
A number of anomalous conditions arise with signature verification
processing - the signature might be plainly erroneous, the signature
algorithm might be incorrect, the browser might not be able to
process the algorithm, or the browser might disallow the certificate
because its signature or hashing algorithm is too weak or susceptible
to compromise.
When a browser encounters a signature error, it presents an error
message such as "invalid signature," "invalid certificate", or
"problem with certificate." Browsers exhibit a variety of differing
behaviors. For example, Firefox, Chrome, and Opera exhibit a blocking
behavior that prevents the user from proceeding to the site. Opera
offers a choice between "Back to safety" or "Help me understand".
Firefox and Chrome offer "try again" and "reload," as respective
options. However, Safari and Chrome on OS X and Internet Explorer on
Windows all allow the user to click through this signature validation
problem as a Bypassable Error.
Some browsers are able to detect certificates that are signed with
MD5 and block their use. For instance, Chrome provides this message,
"The site's security certificate is signed using a weak signature
algorithm!" Opera's notice states, "Invalid Server Certificate" and
Wilson, et al. Expires January 23, 2015 [Page 10]
Internet-Draft Browser processing of server certificates July 2014
offers "Back to Safety" and "Help Me Understand." Similarly, other
browsers present notices similar to those in the preceding paragraph.
3.3.1.2. Name Constraints
We have observed that Chrome and Safari on Mac OSX do not process
name constraints. When name constraints are present and marked
critical, Chrome presents a message stating, "Something is
interfering with your secure connection ...." However, if the name
constraints extension is not marked "critical", then both Chrome and
Safari allow the connection to proceed with no visual indicator of
any anomaly. If the name constraint is critical, Safari will reject
the certification path due to an unrecognized critical extension
(even if the subject DN or the subject alternative name is allowed by
the name constraint rule), but it gives the user a choice to proceed
with the connection. Chrome on Mac OS X blocks the user with a
"reload" button for all name constraints marked critical.
The following additional observations are made with respect to name
constraints:
. Microsoft IE on Windows platforms enforces name constraints (in
both the CN and in the Subject Alternative Name), but gives the
user a choice to proceed with the connection.
. Firefox on all platforms enforces name constraints (in both the CN
and in the Subject Alternative Name) and does not permit the user
to proceed.
. Chrome on the Windows platform enforces name constraints (in both
the CN and in the Subject Alternative Name), and does not permit
the user to proceed.
. Chrome on Linux enforces name constraints in the Subject
Alternative Name and does not enforce the name constraint on the
CN. Furthermore, in the case of name constraint failure on Linux,
Chrome gives the user a choice to proceed with the connection.
Wilson, et al. Expires January 23, 2015 [Page 11]
Internet-Draft Browser processing of server certificates July 2014
3.3.2. Current Time within Validity Period
Most, if not all, browsers properly evaluate whether an end entity
certificate is within its stated validity period. The browser may
display a warning indicating that a certificate in the certification
path is outside of its validity interval or expired. The user may be
given the choice to proceed to the content. The trust indicator may
be suppressed. In some cases, there may be no warning, but the trust
indicator is simply suppressed.
When the browser detects that the current system time is beyond the
validity period of a certificate in the certification path, a warning
is displayed. Some browsers indicate that a certificate has expired
and present a bypassable error asking whether or not to proceed or
allowing the user to view the certificate with a certificate viewer.
Some browsers also alert the user to the possibility that the error
is not caused by an expired certificate, but by incorrect system
time, and display the system time. For example, "Your computer's
clock currently indicates it is Monday, October 14, 2013, 4:00 AM.
Does this look right? If not, you should correct the error and
refresh this page."
We plan to enhance this section with additional and more complete
information in terms of validity period for certificates in the
certification path (i.e., handling expired CA certificates).
3.3.3. Public Key Parameters
3.3.3.1. Sizes
The public exponent for all RSA keys in SSL/TLS certificates must be
an odd number and cannot be "1" (because with RSA, when e=1, the
cipher text is equal to the plaintext).
Since December 31, 2013, has passed, all public RSA keys should be at
least 2048 bits.
Currently, if an RSA key size is less than 900 bits, Opera presents
the user with a negative visual indicator and a bypassable dialog.
If the RSA key size is greater 900 bits but less than 1,000 bits it
removes the padlock indicator.
Wilson, et al. Expires January 23, 2015 [Page 12]
Internet-Draft Browser processing of server certificates July 2014
Microsoft allows manual configuration of minimum key lengths by
editing the registry, using a certificate utility or other
mechanisms. See http://support.microsoft.com/kb/2661254. Thus, IE
and Chrome on Windows platform can enforce the 2,048 bit requirement.
It is not known if Firefox on Windows or other browsers listed in the
scope section address the 2,048 bit key size requirement.
3.3.3.2. Algorithms and Cipher Suites
Concerns about algorithms and cipher suites have increased over the
last several years as new vulnerabilities have been reported in the
media. [Examples to be given by cross-reference] This added attention
has increased focus on the abilities of browsers to block older,
insecure cryptographic methods while at the same time being able to
handle and process newer, more secure ones. For instance, Microsoft
has announced the deprecation of SHA1 and a 1-January-2017 sunset
date of its use in Windows. While other algorithms, like MD4 and
MD5, have already been sunsetted, there is the potential that
certificates could still be signed using those algorithms. At the
same time, use of Diffie-Hellman Ephemeral keys has been suggested as
one way to provide forward secrecy, and elliptic curve cryptography
is a recommended way to shorten bit lengths of keys. With the
various permutations and combinations of parameters for these
algorithms, browser capabilities for the more common ones should be
examined.
3.4. Security Considerations
Potential threats to communications security to be considered include
whether allowing weak cryptography increases the risk that
intercepted communications will be decrypted, and whether an
inability to handle unexpected certificate data might cause a browser
to fail in an insecure way, for example, software failure that allows
a connection to proceed without encryption or enables other system
misuse, e.g., a buffer overflow due to excessive data in a
certificate payload.
3.5. Areas for Future Work
Future work will include additional review of algorithm support.
We also plan to discuss how pinning interplays with certification
path development and validation. Some browsers support the pinning
of public keys.
Wilson, et al. Expires January 23, 2015 [Page 13]
Internet-Draft Browser processing of server certificates July 2014
Most browsers perform certificate policy extension processing
appropriately. We have not examined if the policy mapping, inhibit
any policy, and policy constraints extensions are processed
correctly. Most browsers, as a result of certificate policies
extension processing, provide a visual indication when they detect
that all the certificates in the certification path contain the
correct policy OID for Extended Validation. We plan to quantify
further the characteristics for the browsers listed in the scope
section.
Inputs are sought from the working group participants and vendors to
identify additional path validation rules and additional exceptions.
4. Server certificate processing
This section focuses on how the browsers use names and key usages in
Server certificates. While many of these checks are part of
certification path validation, these checks are discussed here as
part of TLS Server certificate processing in order to emphasize how
the browsers use the information in TLS Server certificates.
4.1. Subject Names
SSL/TLS certificates contain at least one subject name to bind the
public key in the certificate with the server that possesses
corresponding private key. The subject name appears in the subject
alternative name extension as dNSName name type and often in the
common name field. The latter practice of using the common name was
deprecated by RFC 2818. A browser processes the subject name in the
certificate to determine whether it matches the expected server name.
(As discussed above, the enforcement of name constraints on the DNS
name appearing in certificates varies among browsers.) Browsers are
known to successfully connect with servers whose DNS name appears in
the Subject CN only and when subject alternative name extension is
absent. Current browsers also work if the CN field is blank and the
certificate only has the name in the subject alternative name
extension. However, of some interest, is confusion over the
processing semantics with regard to the "O" and "OU" fields in the
subject name. How should subject name be populated when the
subscriber is an individual and not an organization? How is the "OU"
field interpreted? For EV certificates, what if the CA fails to
populate the "O" field?
Browser processing of internationalized names in subject names of
certificates allow browsers to either process the Internationalized
Wilson, et al. Expires January 23, 2015 [Page 14]
Internet-Draft Browser processing of server certificates July 2014
Name back into Unicode or display the Internationalized Name in ASCII
as xn--. See Section 7 of RFC 5280 for more detailed explanation.
In addition to the use of names for SSL/TLS processing, certificate
distinguished name fields may provide further identification of the
subject through domain-component naming and X.500 naming (e.g.
country, organization, etc.). When name constraints are used on the
DN, the entire subject distinguished name (not just the CN) needs to
pass the name constraints.
Section 3.1 of RFC 2818 states that in the case of a certificate name
mismatch, a browser "MUST either notify the user (clients MAY give
the user the opportunity to continue with the connection in any case)
or terminate the connection with a bad certificate error."
Typical browser behavior will provide a message box that reads,
"Security Error: Domain Name Mismatch" with treatment as a bypassable
error with options such as "View Certificate," "OK" or "Cancel."
Some browsers still prioritize common name processing over subject
alternative name processing even though use of the common name has
been deprecated. Another scenario is when the common name is not one
of the names listed as a subject alternative name. When either of
these occur, a browser might throw a domain name mismatch even though
the name to be used for the SSL/TLS session is in either the common
name field or the subject alternative name of the certificate but not
in both.
Most browsers display a warning, but allow the user to proceed to
viewing the contents of the web site.
Some systems, such as Keychain Access in Apple OS X, allow the user
to override certificate name mismatches by explicitly trusting a
certificate for a particular domain name that is not contained in the
certificate.
4.2. Wildcard character
Most browsers support a wildcard character in the leftmost position.
For the browsers listed above in the scope section, we plan to
examine wildcard behaviors when the wildcard character is placed in
positions other than the leftmost position, or when it alone is
located to the immediate left of a top level domain.
Wilson, et al. Expires January 23, 2015 [Page 15]
Internet-Draft Browser processing of server certificates July 2014
4.3. Key Usage Extension
A server's public key can be used for key encryption, key agreement,
or digital signature verification depending on the TLS cipher suite
selected. Below are a few examples:
. TLS_RSA_WITH_AES_128_CBC_SHA: The Server key is used for encrypting
the master secret and thus, the Server certificate should have the
key encipherment bit set if the Server certificate contains the key
usage extension.
. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: The Server key is used for
authentication of ephemeral DH key thus, the Server certificate
should have the digital signature bit set if the Server certificate
contains the key usage extension.
. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: The Server key is used for
authentication of ephemeral DH key thus, the Server certificate
should have the digital signature bit set if the Server certificate
contains the key usage extension.
. TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA: The Server key is used for
ECDH key agreement/exchange. Thus, the Server certificate should
have the key agreement bit set if the Server certificate contains
the key usage extension.
4.4. Security Considerations
An inability to detect and report an improper match between the
client's reference identifier (server name) and the subject name in
the certificate (a presented identifier) could enable the misuse of a
certificate for man-in-the-middle server authentication. For
example, an attacker could use a certificate surreptitiously with a
server name to bypass a general requirement that the name in the
certificate exactly match the fully qualified domain name of the
server.
4.5. Areas for Future Work
We plan to add information how the browsers adhere to these
requirements. For instance, what is the browser behavior where an
elliptic curve certificate asserts the key encipherment bit instead
of the key agreement bit?
Wilson, et al. Expires January 23, 2015 [Page 16]
Internet-Draft Browser processing of server certificates July 2014
Also, if the extended key usage extension is present in the Server
certificate, it should have one of the following OIDs: Server
Authentication or anyExtendedKeyUsage. There is concern about non-
SSL/TLS certificates (certificates issued without the intention that
they be used for SSL/TLS) with the anyExtendedKeyUsage EKU. We intend
to look at the degree of risk this presents.
We plan to add information how browsers vary in their processing of
EKUs in end entity certificates.
5. Browser Human Interface (Visual) Indicators
This section describes the typical kinds of browser/OS behaviors when
processing SSL/TLS certificates.
5.1. Visual indicators
The most commonly used visual indicator of SSL/TLS security is the
padlock icon. Variations of the icon include the closed padlock, the
open padlock, and the padlock superimposed with a red slash or X.
5.2. Positive visual indicators
Commonly used visual indicators that are considered positive
indications of web site authentication or security are a closed
padlock icon, use of the color green, and the display of additional
information about issuer or subject of the certificate.
Some of these indicators are called EV indicators because of their
use when displaying a website that presents an Extended Validation
certificate to the browser.
5.3. Negative visual indicators
Visual indicators used by browsers to convey warnings include use of
the color red, a slash (/) or X across a positive indicator (a red
slash or X across the padlock icon and/or the "https"), a message
box, or the removal of a positive indicator (e.g. removal of the
padlock).
Wilson, et al. Expires January 23, 2015 [Page 17]
Internet-Draft Browser processing of server certificates July 2014
5.4. Message boxes, dialog boxes and error pages
A message box is generally used not just as negative indicator, but
also to convey more context-specific guidance to the end user. They
can provide warnings or explain why an SSL/TLS connection cannot be
completed. Dialog boxes are used when the browser encounters an
uncertain environmental condition (for gray areas where the security
threat is not black or white). Some dialog boxes provide a simple
binary choice (a) proceed or (b) "get me out of here." This type of
browser behavior can be referred to as a "single bypassable error."
Other dialog boxes can exhibit more complex behavior, such as
multiple branches, additional nested bypassable errors, helpful
information, and decisions to be made by the user.
An error page is another mechanism used by browsers to provide
certificate-related information to users.
Some error messages provide an option to view the certificate.
Clicking on the offer launches the browser's certificate viewer.
5.5. Certificate viewers
Most browsers provide a means to examine the SSL/TLS certificate of
the web site and the chain of certificates leading up to the root
certificate. Some browsers block viewing the certificate in
circumstances determined by the browser to be insecure.
5.6. Certification Path Development and Validation Indication
If the certification path cannot be validated, some browsers will
alert the user about the inability to complete the server's
certificate chain, however the clarity of the explanation varies
among browsers. For instance, Firefox indicates "connection is
unsecure" and that the browser was unable to determine either
security status or the identity of the site. It provides the option
of "get me out of here" or "I understand the risks".
Most browsers will provide a warning when a certificate is signed by
an unknown CA. The warning usually states that an unknown authority
issued the certificate. Additional warnings include that if the user
has connected to the site previously without errors, it may mean an
attacker is trying to impersonate the site and intercept confidential
communications. Users are advised not to continue unless they are
sure.
Wilson, et al. Expires January 23, 2015 [Page 18]
Internet-Draft Browser processing of server certificates July 2014
With some browsers, this error can be bypassed for the session or the
user can explicitly trust the certificate permanently. When a
certification path fails because the issuer is not in the root store,
most browsers will still allow the user to explicitly trust the
certificate or the issuing CA. The number of steps required to
explicitly trust an untrusted certificate vary from browser to
browser.
5.7. Configurables
Most browsers provide the ability to configure certain certificate-
related behaviors. In Mozilla Firefox a user can change some options
using Tools -> Options -> Advanced -> Certificates or by typing
"about:config" in the address window and editing security
preferences. Changes in Microsoft's Internet Explorer settings can
be made under Tools -> Internet options -> Advanced -> Security or by
editing the registry. In Apple OS X, configuration changes are
performed by accessing preferences for certificates in the Keychain,
but since the only configurations available are related to revocation
checking (CRLs and OCSP), they are outside the scope of this draft.
5.8. Security Considerations
Better (i.e., more accurate, less ambiguous, and more complete)
security warnings to end users will lead to better decisions about
system security. While there is much to improve with browser error
messages, most operating systems also do not provide information that
browsers might use to provide better system diagnoses and messaging.
Better end user messages based on more accurate communication of
information can help address concerns about "warning fatigue" and
other problems of message ineffectiveness and end user confusion.
5.9. Areas for Future Work
We plan to offer "model" error messages to help guide browsers in
communicating with users more clearly.
Inputs are sought from the working group participants and vendors to
identify additional problems and solutions.
6. IANA Considerations
This memo includes no request to IANA.
Wilson, et al. Expires January 23, 2015 [Page 19]
Internet-Draft Browser processing of server certificates July 2014
7. Security Considerations
In addition to the security considerations discussed above, the
operations described above exhibit several vulnerabilities that could
adversely affect the reliability of the authentication and security
provided by SSL/TLS certificates. These vulnerabilities have been
discussed throughout this RFC and are summarized below:
Additional items will be provided as the draft becomes more stable.
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu,
"Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework", RFC 3647, Nov 2003.
[RFC 4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S.,
Nicholas, R., "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158, September 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 5280,
May 2008.
[RFC6797] Hodges, J., Jackson, C., and Barth, A., "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012.
[W3C-WSC] Web Security Context: User Interface Guidelines, W3C
Recommendation 12 August 2010.
Authors' Addresses
Ben Wilson
Email: ben@digicert.com
Santosh Chokhani
Email: schokhani@cygnacom.com
Robin Alden
Email: robin@comodo.com
Wilson, et al. Expires January 23, 2015 [Page 20]