RE: What is a secure page?

In my opinion we need to move away from binary security indicators
(padlock).  Plus most users don't notice if the padlock is open or
closed, and those who do aren't sure what the difference means.

Even if every component of a document is delivered over SSL, there's
tremendous variation in what SSL can do:
 - It may encrypt the transmission strongly (e.g., AES-256), weakly
(e.g., DES-56), or not at all (NULL cipher).
 - It may authenticate the server strongly (cert trust & revocation
checks), weakly (no revocation check), or not at all (self signed cert).
 - It may imply site reputation is good (EV cert, WebTrust, etc.) or bad
(cert revoked) or unknown

This is too much information to convey with the old padlock metaphor.
Off the top of my head my preference would be something like a set of
thermometer bars that display strength of encryption, authentication, &
trustworthiness.

>Michael McCormick, CISSP
>Lead Architect, Information Security
>
>This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Yngve N. Pettersen
Sent: Sunday, December 31, 2006 10:17 AM
To: public-wsc-wg@w3.org
Subject: What is a secure page?


Hello all,

A part of security contexts that I do not think have been covered yet is
when a document can be called secure. Or, when should the closed padlock
(any padlock, ignore encryption strength) be dispayed?

A) I think everyone will agree that a secure (https) document loaded by
user action that only contain secure inline elements like images,
frames, applet's etc. should get the padlock.

B) I also think everyone will agree that such a document where at least
one element is loaded from an unsecure (non-https) server should NOT get
a padlock. It is generally not possible (for the client) to tell how
sensitive an inline element is, but in two cases, external Javascripts
and plugins/applets it should be apparent that receiving these from
unsecure sources compromises the document's security.

Opera does not display a closed padlock in such cases, and neither does
Mozilla or MSIE. Mozilla/MSIE give the user a warning about mixed
security. Originally, IE7 was supposed to block mixed security elements,
but the IE team encountered what they considered serious usability
problems on some sites, and (IMO, regrettably) reverted to IE6 behaviour
[4].

Of the more serious mixed security problems I've seen are external
Javascript served from an unsecure server (usually webbugs), but I have
also seen a case where a (secure) external Javascript link from a
payment
page(!) was redirected to the unsecure version by a misconfigured
loadbalancer. I have also seen secure flashapplets load data from
unsecure servers [1].

C) What I expect be a bit more discussion about is how to rate secure
main documents that started out (when the user entered the URL, or
clicked the
URL) as an unsecure http URL, which was then redirected to a secure
document (and all inline elements are secure).

There are three major redirect methods in use on the web:

   1) HTTP 30x redirects.
   2) Meta refresh redirects
   3) Javascript redirects

Except for Opera, most browsers apparently ignores the HTTP part as long
as the main document is secure. Opera only tolerates a direct
http->https HTTP redirect for GET requests, and do not display a closed
padlock for any other variation. I am not sure about how we currently
handle meta refresh redirects.

Opera's policy on this causes a number of support requests, along with
requests for a change to display a closed padlock for other types of
redirects. (The fact that we display a padlock for immediate HTTP
redirects is a modification of our original design that did not show a
closed padlock when the loading started as a HTTP URL.)

D) Additional scenarios we could look at, are how to handle

   - form submits from an unsecure document to a secure form (in
particular with passwords [2]).
   - unsecure form submits from secure pages or applets [2]
   - unsecure POST submits that redirect to secure pages.
  (- others?)

In some of the above cases, the question is not just whether or not the
browser should display a closed padlock, but whether or not the client
should even permit some of that actions above (e.g mixed security in
documents), and how to explain such refusals.


I've previously posted a couple of articles([1], [2], [3]) on my home
page that discusses some of these issues, and possible ways to handle
them.


[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  
>

--
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, 2 January 2007 17:19:42 UTC