• WhatIsASecurePage

What is a secure page?

Goals

• 2.1 Document the status quo

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.

• 2.2 Relevance of security information
• 2.3 Consistent presentation of security information

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.

• 2.5 Reliable presentation of security information

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.

• 2.7 Authoring and deployment techniques

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

• Conceptual model
• Habit formation

Definition

Concerns this proposal seeks to address

The primary concerns this proposal seeks to address are:

• End-to-end protection of the data exchanged between the client and the server when downloading content, in a manner that the end applications are aware of.
• The strength of the methods used, individually, and in combination (For example, is the protocol secure, even if the encryption methods by themselves are secure?)
• How to present an easy to understand summary to the user about the methods used to download the content that is presented to the user.

Additional concerns are:

• If parts of the presented content is not protected in the above mentioned fashiom, how should the client inform the user about this, or how should it automatically handle the situation
• How should the client handle a situation where the the content transitions from unprotected to protected, and the (sensitive) data the user entered in the unprotected content (that is, a form) is to be sent to the server over a protected connection?

Discussion

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)

• Symmetric encryption strength used by the connection
• Strength of authentication used by server (such as public key length and certificate chain)
• Security of the protocol
• Sequence of redirects used to get to the document
• The security of documents loaded as part of the document
• The security of resources loaded by external software (plugins, Java) through the client
• Problems retreiving revocation information (OCSP or CRL)

Not considered by clients:

• The security of resources loaded by external software by direct connection to the network (bypassing the client) as part of the document
• The security of networked resources retrieved by the server as a result of the request from the client (that is, the server function as a proxy)
• Actions taken by a proxy that has been given permission to decrypt and then (possibly) reencrypt the request and the resulting content, for example to filter the content.
• The security of the endpoints
• Usage of content. It is not practical for the client to differentiate between types of content, such as sensitive/non-sensitive images, adverts, webbugs, active content, etc.

Additional criteria that have been suggested:

• Information about the service's reputation (Clients using Fraud and phishing filters are currently being deployed. Requires a repository of user experiences, difficult to quantify).
• Previously registered information about the server (requires an extensive in-client database).
• Is the document using content from third party services? (What is a thirdparty service?).

Other criteria that might be used

• Have the data been stored on the local filesystem? (Servers can suggest this for documents. A problem determining this is that content may be stored to a swapfile without the application's knowledge).
• Security of network name lookup, such as Secure DNS.

What does the user think the padlock indicate?

• Too little information is available about this topic, but there are indications that many users ignore the padlock, do not understand what it indicates, or rely on images of padlocks inside the document area (displayed by the server).
• There are also some that suggest that users that does check the padlock also think of it as a "trust" indicator.

Questions:

• Does the user associate the padlock indication with the entire client or just the document in the "tab"?

Current situation on clients

• No clients display a padlock if there are unencrypted content as part of the otherwise secure page.
• Some clients give a warning (which can be disabled) when the displayed document changes from an unsecure to a secure mode, or vice versa, and when a secure document includes an unsecure document.
• Clients give a warning when forms POST information from a secure document to an unsecure server.

Problems client-side

• Some clients have problems with some of the above mentioned indicators when unsecure content is loaded as a result of a redirect or by a plugin (through the client).

Current problems service-side

• Websites (for example banks) use "padlock" on unsecure pages to indicate the "security" of their login forms, which are posting to a secure server.
• Other sites use a secure login, then moves all interaction to an unsecure server "for performance reasons"
• And some sites keep the main document secure but use images and other inline resources from unsecure servers, also due to "performance reasons".
• A number of sites, including banking sites, still use weak 512 bit RSA keys [1] in their server certificates.

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.

Applicability

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

7. Clients MUST display padlock/security information in a manner that clearly separates it from what the content controls.
8. 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.
9. 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.
10. 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.
11. POST actions to unsecure servers from secure document SHOULD NOT be permitted (also when performed by plugins through the client).
12. The results of immediate (within 15-30 seconds?) automatic Meta/javascript redirects SHOULD NOT get a security level higher than the original document.

13. 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.

14. 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.

15. 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 2³² times more effort than can currently be broken in about a year using currently known techniques and technology. (2³² 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)

16. 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.

Techniques

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.

Dependencies

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).

Examples

Non-conforming services

• A website hosted on a secure server that is referencing unsecure content as part of the displayed document. For example: Unsecure external Javascripts and CSS stylesheets, unsecure images and frames.
• A website hosted on an unsecure server that have login form for username and password that submit directly to a secure server. The form may be assiciated with a padlock image and/or be located in a frame hosted on a secure server.
• A webmail service (for example) that have a secure login, but then perform all transactions on an unsecure server, including reading and composing email.
• A company homepage that have a "login" link (no form) that first go to a HTTP server that then redirects to the HTTPS login form.
• A secure website with a form that POSTs to an unsecure server.

Conforming services

• A website hosted on a secure server that retrieve all elements from the secure server(s)
• A website hosted on an unsecure server that have a link to "login" which takes the user directly to a secure server where the user can enter credentials for the login. The link is not associated with a padlock.
• An unsecure website that knows who the user is, after he has logged in, but have to send the user to the secure portion to do any sensitive transactions because the credentials are not sent to the unsecure server, but are available to the secure part of the service.
• A secure website that want to provide access to unsecure services, but the user first have to click on a link that moves the user away from the secure service.

Non-conforming clients

• A client that shows a padlock when part of the content was loaded unsecurely, and does not block it.
• A client that lets the user directly, or through (for example) a plugin, POST requests unsecurely, or at least does not challenge the submission and require the user to accept the action.
• A client that lets the user submit passwords from an unsecure document to a secure server.
• A client that shows the EV indication if an image or other inline element that is part of an EV-validated document was loaded from a non-EV-validated server.

Conforming clients

• A client that block unsecure content in a secure document.
• A client that does not show a padlock for content served over a connection using weak encryption, for example 40 or 56 bit symmetric encryption, 512 bit RSA key used in the key exchange.

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:

• Man-in-the-middle attacks on an unsecure inline element that is an active part of a secure page, and that can be used to manipulate the page, for example external JavaScripts and external CSS files.

• Man-in-the-middle attacks on login forms in unsecure pages that submit to a secure server. The actions on these forms can be manipulated by such an attacker.
• By discouraging weak encryption methods, protocols and keys, one achieves enhanced protection against man-in-the-middle attacks on encryption protocols. At present that is a realistic possiblity for servers using 512 bit RSA keys in their server certificate.
• The restrictions on mixed content also reduce the possiblity of leaking information about what the user is doing inside the secure session. This protection does not extend to analysis of the secure traffic if this traffic contain discernible patterns.

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

• Users need to understand at least a little about what the security context information (for example the padlock) means, and where to find it.
• Proposal 1-5 should make it easier for users to determine the actual security context information for the site.
• For most proposals it is necessary for the user to look for the security context information.
• Some proposals, in particular 1, 2, 3, 4, 5, 8 and 10, does not directly require action by the user, but does improve on her ability to determine the correct security context information.

Disruptions

• Proposals 8 and 9 may cause the security context information, and parts of the expected content to disappear and the document's appearance may be changed or not behave as expected. This can only be fixed by the website.
• Proposal 10,11 can cause several types of unsecure forms to break. This can only be fixed by the website.
• Proposal 13 may cause confusion if the change is not properly explained. This can be fixed in part by the client explaining clearly why the URL is gone, and in part by the website using better security protocol parameters.
• Proposals 9, 12, 14, 15 may cause the secure indication to disappear for pages that the user would expect it to be displayed for. This can only be fixed by the web site.
• Proposal 16 may cause EV-validated sites to be displayed without the EV indicator. This can only be fixed by the involved websites.

References

• Eric Lawrence (Microsoft) about critical mistakes in the design of secure services

• IE7 backs off on blocking unsecure content in secure pages

• "'Secure' bank logins?"

• "Secure sites that aren't"

• "Low security sites, what to do about them?"

• [1] "(51)2-bit banks"

• [2] "It ain't EV 'til it's EV, all EV"

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

• https://opodouk.custhelp.com/cgi-bin/opodouk.cfg/php/enduser/ask.php This otherwise secure page includes an unsecure external Javscript, leaving the secure page vulnerable to an attacker that can edit the network traffic.

• https://www.beatport.com/ The "secure" Flash-applet is initiating the loading of the unsecure images, and also POSTs (several times) from secure to unsecure. According to the webmaster this is done due to performance reasons.

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".

• http://www.americanexpress.no/ redirects to http://www.americanexpress.com/norway/homepage.shtml >. On the other hand the US branch seem to use a secure login page now. According to George Ou (ZDnet) they did not do that by default a year ago.

• http://www.chase.com/

• http://www.wachovia.com/