Summary of "What is a secure page?" discussion, first draft

Hello all,

Here is my first draft of the summary of the earlier discussion of what a  
secure page is (or should be).

Comments, suggestions?

----------------------

* In scope:

Documents loaded from a server to a client via HTTP or HTTPS, and the
security of the loading procedure between the client and the server (how
protected was the information in transit?).

* Not in scope:

The security of the underlying network, such as VPNs.  Even an isolated
local network can have malicious users, so the network connection
environment should be considered unprotected.

The local security of the client and server systems. It is not possible
(except possibly in certain special cases) for software to protect itself
on a compromised system, and it is likewise very difficult, if not
impossible, for the software to tell if a system is compromised. For the
purpose of this discussion the end-point systems should be considered
secure.

--------

* What does the padlock indicate?

The padlock (whatever form it takes; There was some discussion about that)
displays the combined security level of the loaded document, based on
certain client specific criteria, such as the encryption methods used when
connecting to the server.

Criteria currently used by clients (clients may use a selection)

    - 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

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.

Criteria some think should be included

    - Information about the service's reputation
    - Previously registered information about the server
    - Is the document using content from third party services?

Other criteria that might be used

    - Have the data been stored on the local filesystem? (Problem: Swapfile)

* What does the user think the padlock indicate?

   - Too little information, 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 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:

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

* Suggestions for services best practices

   - Never 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 is safe"
   - All login forms to a secure service must be served from a secure  
server.
   - If a service require secure login, then all transactions/presentations
based on those credentials 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.)
   - Do not mix secure and unsecure content in the same document.
   - 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.

* Possible suggestions for clientside improvements

   - Do not permit unsecure content in otherwise secure documents.
   - Do not POST passwords from an unsecure page (even if the form is in a
"secure" frame) to a secure server. Perhaps input to the forms field
should also be ignored?
   - POST actions to unsecure servers from secure document should be
forbidden (also when performed by plugins through the client).
   - The results of immediate automatic Meta/javascript redirects should not
get a security level higher than the original document(?).



Background information:

[1] "'Secure' bank logins?" <URL:
http://my.opera.com/yngve/blog/show.dml/281609 >
[2] "Secure sites that aren't"  <URL:
http://my.opera.com/yngve/blog/show.dml/382945 >
[3] "Low security sites, what to do about them?" <URL:
http://my.opera.com/yngve/blog/show.dml/461932 >

[4] <URL:
http://blogs.msdn.com/ie/archive/2006/10/18/ssl-tls-amp-a-little-activex-how-ie7-strikes-a-balance-between-security-and-compatibility.aspx
>

Sites currently mixing secure and unsecure content

   <URL:
https://www.opodo.co.uk/opodo/StrutsServlet/DisplaySiteInfoPage?pageName=security
>
   <URL:
https://opodouk.custhelp.com/cgi-bin/opodouk.cfg/php/enduser/ask.php >

   <URL: 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.

   I have also seen both accidental and intentional redirects of inline
content, frames, images and external Javascript, from a secure URL to an
unsecure URL.

Sites POSTing login credentials from unsecure to secure:

   <URL: http://www.americanexpress.no/ > redirects to <URL:
http://www.americanexpress.com/norway/homepage.shtml >. OTOH The US branch
seem to use a secure login page now. According to George Ou (ZDnet) <URL:
http://blogs.zdnet.com/Ou/?p=201 > they did not do that by default a year
ago.

   <URL: http://www.chase.com/ >

   <URL: http://www.wachovia.com/ >


-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Tuesday, 24 April 2007 18:04:01 UTC