A proposal for handling self-signed certs

Version: 20070725-02

WSC Goals


This proposal assumes that the presentation of non-self-signed certificates is handled elsewhere and so only addresses "special" handling for self-signed certificates (SSC).

SSC are useful in a number of contexts and should not be deprecated. For example, devices may use SSC in order to "secure" a web based configuration tool. As a second example, small "community" web servers may wish to use an SSC in order to provide confidentiality for access to sensitive data like personal details, often coupled with use of a username/password authentication scheme.

The basic idea is to initially treat a site using an SSC as being unsecure (by not displaying "secure" SCI), but to eventually, after a number of successful, "identical" interactions, start to display SCI that indicate that the site is "secure" in the same way as a non-SSC would be displayed. In this case "identical" means that no essential security information has changed, e.g. public keys or (perhaps) DNS names or IP addresses.

We refer to this initial period as the "probation" period for the SSC. An "interaction" here means from the start of a TLS session (or possibly session resumption) until the user's focus switches away from the object in question, e.g. by exiting the browser or by moving the focus. Note that the interaction duration is not the same as the period for which the same TLS pre-master secret is in use. (That last may need more thought.)


This requirement applies to web user agents that implement TLS.

Conformance Requirement

Implementations SHOULD maintain state sufficient to detect that the same SSC is being used without changes. This state includes the SSC itself and possibly additional information like URIs, DNS names and/or IP addresses. (Not sure which is relevant when.)

Implementations SHOULD NOT display "secure" SCI for uses of a given SSC during the probation period.

Implementations SHOULD display "secure" SCI, equivalent to what would be displayed for a non-SSC after the probation period.

The number of successful interactions required before ending the probation period SHOULD be a configuration setting.

There MUST be a minimum duration (in seonds) for the probation period which SHOULD be sufficiently long that a user has time to consider and react to what they see. The time remaining (in seconds) MUST only be decreased by the amount of time the user is actually interacting with the site.

Interactions counting towards the end of the probation period SHOULD only be counted if they are "visible" to the user, e.g. only if the object in question is a "top level object" (Thomas' term - dunno if its well-defined or not).

An unsuccessful interaction SHOULD reset the implemenation back to the start of the probation period.


The duration over which the set of successful interactions occurs needs to be a factor in whether or not to display SCI, e.g. presentation of the same SSC 10 times in ten separate sessions (perhaps via re-directs) over the course of one second would be suspicious.

The duration of each interaction could be related to the user "paying attention", e.g. placing the focus on the object in question.

The implementation might also take account of the type of interaction with the site, for example, making use of secondary SCI to alert the user that potentially sensitive information is being requested during the probation period.


This depends on the presentation of SCI for non-SSC being agreed.


A user purchases a new wireless print server for her home network. The print server has a web based configuration interface that allows setting WLAN security settings and also has an ethernet port. Secure initial configuration requires connecting via the ethernet cable to the web server. The web server listens on port 443 (probably using a manufacturer selected private IP address documented on paper) for TLS connections and provides an interface for configuring wireless security settings. Once the wireless security is working, the user can connect via her home WLAN where the same (or another) SSC may be used. After four or five TLS sessions are established in this way, the SCI displays the connection as "secure" according to whatever appopriate primary SCI is relevant.

The parents/mentors for a children's football team maintain a web site with information about the team-members that includes phone numbers and basic medical information that should not be sent in clear over the Internet and to which access should be controlled. There are no funds for paying for any certificates available and only a small set of users to which access should be granted. The site uses an SSC and once the probation period is over, then the SCI displays the connection as "secure" according to whatever appopriate primary SCI is relevant.

Use Cases


Attack Resistance and Limitations

During the probation period the user might be relucant to enter information to the site. For some sites, this might result in the user not re-visiting, thus indefinitely extending the probation period.

If a user can be attracted back to a site sufficiently often, over a sufficiently extended duration (possibly "invisibly") then the probation period could be over before the user realises that they have interacted with the site at all.

This proposal might interact with the "mixed content" proposal (from Ynvge), in particular in terms of "inivisible" content.

Faking the SSC would reset the probation period, and would therefore constitute a new potential DoS vector.


This proposal could result in a previously "secure" appearance being displayed as non-secure whenever a new browser version (the 1st that implements this proposal) is installed, or if state information is lost or if the server SSC or other relevant state information changes.

If the same SSC were used for more than one site (e.g. if a web server was distributed with a single built-in key pair and SSC) then this proposal could result in all such sites remaining in the probation period for ever. Arguably that is correct.