Skip to main content

7. Security Considerations

7. Security Considerations​

7.1. Pinned Certificates​

As defined under Section 1.8, a certificate is said to be "pinned" to a DNS domain name when a user has explicitly chosen to associate a service's certificate with that DNS domain name despite the fact that the certificate contains some other DNS domain name (e.g., the user has explicitly approved "apps.example.net" as a domain associated with a source domain of "example.com"). The cached name association MUST take account of both the certificate presented and the context in which it was accepted or configured (where the "context" includes the chain of certificates from the presented certificate to the trust anchor, the source domain, the application service type, the service's derived domain and port number, and any other relevant information provided by the user or associated by the client).

7.2. Wildcard Certificates​

This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). As a result, the rules provided in this document are more restrictive than the rules for many existing application technologies (such as those excerpted under Appendix B). Several security considerations justify tightening the rules:

  • Wildcard certificates automatically vouch for any and all host names within their domain. This can be convenient for administrators but also poses the risk of vouching for rogue or buggy hosts. See for example [Defeating-SSL] (beginning at slide 91) and [HTTPSbytes] (slides 38-40).

  • Specifications for existing application technologies are not clear or consistent about the allowable location of the wildcard character, such as whether it can be:

    • only the complete left-most label (e.g., *.example.com)

    • some fragment of the left-most label (e.g., fo*.example.com, f*o.example.com, or *oo.example.com)

    • all or part of a label other than the left-most label (e.g., www.*.example.com or www.foo*.example.com)

    • all or part of a label that identifies a so-called "public suffix" (e.g., *.co.uk or *.com)

    • included more than once in a given label (e.g., fbr.example.com

    • included as all or part of more than one label (e.g., ..example.com)

    These ambiguities might introduce exploitable differences in identity checking behavior among client implementations and necessitate overly complex and inefficient identity checking algorithms.

  • There is no specification that defines how the wildcard character may be embedded within the A-labels or U-labels [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]; as a result, implementations are strongly discouraged from including or attempting to check for the wildcard character embedded within the A-labels or U-labels of an internationalized domain name (e.g., "xn--kcry6tjko*.example.org"). Note, however, that a presented domain name identifier MAY contain the wildcard character as long as that character occupies the entire left-most label position, where all of the remaining labels are valid NR-LDH labels, A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").

Notwithstanding the foregoing security considerations, specifications that reuse this one can legitimately encourage continued support for the wildcard character if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]).

7.3. Internationalized Domain Names​

Allowing internationalized domain names can lead to the inclusion of visually similar (so-called "confusable") characters in certificates; for discussion, see for example [IDNA-DEFS].

7.4. Multiple Identifiers​

A given application service might be addressed by multiple DNS domain names for a variety of reasons, and a given deployment might service multiple domains (e.g., in so-called "virtual hosting" environments). Use of multiple identifiers is addressed as follows:

In the default TLS handshake exchange, the client is not able to indicate the DNS domain name with which it wants to communicate, and the TLS server returns only one certificate for itself. Absent an extension to TLS, a typical workaround used to facilitate mapping an application service to multiple DNS domain names is to embed all of the domain names into a single certificate.

A more recent approach, formally specified in [TLS-EXT], is for the client to use the TLS "Server Name Indication" (SNI) extension when sending the client_hello message, stipulating the DNS domain name it desires or expects of the service. The service can then return the appropriate certificate in its Certificate message, and that certificate can represent a single DNS domain name.

To accommodate the workaround that was needed before the development of the SNI extension, this specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a certificate; however, it explicitly discourages multiple CN-IDs. Although it would be preferable to forbid multiple CN-IDs entirely, there are several reasons at this time why this specification states that they SHOULD NOT (instead of MUST NOT) be included:

  • At least one significant technology community of interest explicitly allows multiple CN-IDs [EV-CERTS].

  • At least one significant certification authority is known to issue certificates containing multiple CN-IDs.

  • Many service providers often deem inclusion of multiple CN-IDs necessary in virtual hosting environments because at least one widely deployed operating system does not yet support the SNI extension.

It is hoped that the recommendation regarding multiple CN-IDs can be further tightened in the future.

Last updated on