What is a secure page?


This section presents the parameters currently used by clients to determine how secure a document is. It also presents some thought about how users interprete the security indicator(s) in the clients, and how websites use the user's interpretation to convey an appearance of security.

This section will propose guidelines for what should be considered secure by the clients, in order to provide the user with consistent security indicators across different clients.

The proposed guidelines will seek to prevent websites attempting to manipulate the client's security indicator(s) into showing a higher level of security than the website should have, for example by making the client load less secure content through mechanisms that are not part of the client's security context information framework.

The proposals of this section suggest how websites should be designed in order to be secure, and also to not appear more secure than they are.

Overview and Background

Usability principles


Secure website/webpage

A secure website is, for the purpose of this proposal, defined as a website hosted on a SSL/TLS HTTPS server, or a similar protocol offering end-to-end (client to server) protected by methods that provide 1) authentication of (at least) the website, 2) integrity and 3) privacy of the communcation. Websites accessed via encryption protocols not handled jointly by the client and server applications, such a VPNs, are not part of this definition

Unsecure website/webpage

An unsecure website is, for the purpose of this proposal, defined as a website hosted on a HTTP server or a server using similar protocols (such as FTP), where the communication between the client and the server is not protected end-to-end by encryption protocols according to information available to the end-point applications


One or more security indicators used by the client to summarize the security parameters, such as use of encryption during transport, of a webpage

Concerns this proposal seeks to address

The primary concerns this proposal seeks to address are:

Additional concerns are:


User agents determine security of a webpage based on a selection from a number of criteria, and often display its conclusion symbolically as a padlock, although other indicators may be used, or are being considered for use. For the purpose of this discussion the term "padlock" will be used for these indicators. The criteria used are, usually, concerned with the security parameters of the connection used, and its context, when loading the content used to build the displayed page.

Criteria currently used by clients (clients often use a subset of these)

Not considered by clients:

Additional criteria that have been suggested:

Other criteria that might be used

What does the user think the padlock indicate?


Current situation on clients

Problems client-side

Current problems service-side

Possible problems in the near future

Extended Validation (EV) introduces enhanced identify information for websites and to the user.

Recent testing [2] indicates that many websites that are using EV certificates are including content, such as external scripts and images, from secure servers that are not using EV certificates. This means that the client, and the user, have no way to determine that the identity of these external sites have been properly assured at the same level as the site they are connecting to.


One set of these proposals apply to websites with a secure component, and how these sites should be implemented to provide sufficient transaction security to their users. Some of these proposals apply equally well to websites without a secure component.

The other set of proposals apply to clients that somehow indicate that a website is secure to the user, either grahically, for example through a padlock icon, or through other cues. The proposals generally deal with how the client should interprete the basic security information inputs available to it, and which are then synthesized into the security indicator.

Proposals for services best practices

  1. Websites SHOULD NOT use an image of a padlock (or similar "this is secure" indicators), at least in a context where the user will assume it means "this page is safe".
  2. All login forms to a secure service MUST be served from a secure server, and MUST NOT not be included inside a page containing unsecure content.
  3. If a service require secure login, then all sensitive transactions and presentations based on the user's credentials, as well as the service provided credential token itself MUST be protected by the same level of security. Cookies on unsecure connections are vulnerable to interception, and can be used for replay attacks even if they were set by a secure server, and servers should not set credential cookies from secure servers that can be sent unencrypted.
  4. Websites MUST NOT mix secure and unsecure content in the same document. In particular, a secure document or applet MUST NOT reference or request unsecure ressources or documents as part of the document.
  5. Change from and unsecure to secure parts of a service SHOULD be done by direct links, and not redirects. If unsecure->secure redirects are needed then the redirect SHOULD be immediate, and not multistep. This lets the user know where he or she is headed before intiating the transition.

  6. Websites using an EV certificate MUST only include content hosted by other EV servers.

Proposals for clientside improvement

  1. Clients MUST display padlock/security information in a manner that clearly separates it from what the content controls.
  2. Clients MUST NOT permit unsecure content in otherwise secure documents, even when loaded and presented by an external application (for example, a plugin), when possible.
  3. Unsecure to secure redirects SHOULD cause the whole page to be considered unsecure, in particular if the redirect sequence contains more than one unsecure redirection. Due to usability issues it MAY be desirable to permit the user to enter an unsecure URL that is immediately redirected to a secure server, and consider the resulting document as secure.
  4. A client MUST NOT submit passwords from an unsecure page (even if the form is in a "secure" frame) to a secure server. Enhancement suggestion: Do not permit focus/input to the password forms field.
  5. POST actions to unsecure servers from secure document SHOULD NOT be permitted (also when performed by plugins through the client).
  6. The results of immediate (within 15-30 seconds?) automatic Meta/javascript redirects SHOULD NOT get a security level higher than the original document.
  7. In case a "secure" page is considered unsecure the https:// URL SHOULD NOT be displayed in the address field (at least, unless the user focuses in there) to avoid the "https means its secure (even if you do not see the padlock)"-mantra. There should be some very visible indication in the addressfield that the URL is not there, perhaps explaining why.

  8. A client SHOULD NOT display a padlock (or similar security indicator) if at least one of the resources required user interaction to accept the certificate of the server or other security protocol related problem, also if the user have specified that he should not be asked about that particular site certificate again. This does not apply to root certificates installed separately by the user.
  9. A client SHOULD NOT display a padlock if at least one of the resources used to build a document view was transmitted using a weak protocol version, a weak encryption method, or a short encryption key. A "weak" encryption method or encryption key is defined as a method using keys that it is estimated can be broken by brute force with less that 232 times more effort than can currently be broken in about a year using currently known techniques and technology. (232 is chosen because, even if a well-funded adversary can accumulate a million times the computing power used for a reasonable one year attack, the efficiency of the attack method would still have to be increased several thousand times to be useful. Short of revolutionary changes in methods or technology this limit will make a controlled migration to stronger methods more feasible, as there will be numerous indicators of these improvements for years before the advances become a problem)

  10. Clients supporting EV certificates MUST NOT indicate that a website is EV-validated unless all content used to generate the displayed page are retrieved from EV-validated servers.


The proposals for websites does not require any special techniques not already used to design websites.

The proposals for clients primarily require the client to maintain a state of how loading of the document was initiated, and the security state information associated with each element of the page. Some of the proposals also require the client to assess the security state of the current document before deciding to execute the requested action.

In addition, Proposal 15 require the vendor to consider the state of encryption research and its implications for the methods used by the client. In this case vendors may want to add a remote update capability to their client that will permit them to update the heuristics used in the clients.


The information used is extracted from the SSL/TLS session information, such as protocol, cipher and certificate information, as well as revocation information retrieved from OCSP and CRL resources.

Additional information, such as redirect targets, come from HTTP responses (including HTTP over TLS, HTTPS).


Non-conforming services

Conforming services

Non-conforming clients

Conforming clients

Use cases

Case 17:

If the client blocks unsecure content, Betty will still see the padlock, and there is no chance for leaking sensitive information through the URLs used, or receiving manipulated content inserted by an attacker.

Case 1:

Alice will need to check the security context information. She should know how to interprete the padlock's precense or non-precense, and how she should act in certain situations.

Related cases are 2, 3, 4(?), 20

Case 8:

Betty will need to check the security information, in particular the organization name (EV can also be involved here). There is some possibility that Malcolm have managed to create a company with a name similar to Example Inc., in such cases it might be that only a close inspection or contact with the real company would reveal the fraud.

Related case is 9

Case 11:

Current clients will display a warning. Betty will have to click through this dialog.

Some clients will also remove the padlock information, although it may be possible to get access to the certificate information.

If the client also removes the URL from the address and replaces it with some clear trouble indicator, them Betty will have yet another indicator that there is a problem.

One related case is Use Case 12, another is Use Case 18, as Betty may become too used to clicking OK on the dialog.

Attack resistance and limitations

These proposals individually or collectively, prevent several types of attacks:

None of the proposed methods can protect the user if a secure server has been compromised (this type of problem is out of scope).

The determination of what strength encryption can be broken in a given period of time depend strongly on published research results, and extrapolation of what is currently possible within the field, or may be possible in the near future.

Expected user behaviour



Sites currently mixing secure and unsecure content (as of April 24, 2007)

Sites POSTing login credentials from unsecure to secure (as of April 24, 2007)

All of these sites encourage the user to submit their login credentials from an unsecure page. The credentials are sent from the unsecure page using SSL. They also place a padlock beside the form to indicate that it is "secure".