Re: What is a secure page?

Yngve,

I wonder if you (or somebody else) would be willing to summarize
this thread from late December / early January, and extract possible
best practices / recommendations from it?

I think this is a general question that we'll need to reconsider as
we move forward.

Thanks,
-- 
Thomas Roessler, W3C  <tlr@w3.org>







On 2006-12-31 17:16:59 +0100, Yngve N. Pettersen wrote:
> From: "Yngve N. Pettersen" <yngve@opera.com>
> To: "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
> Date: Sun, 31 Dec 2006 17:16:59 +0100
> Subject: What is a secure page?
> Organization: Opera Software ASA
> X-Archived-At: http://www.w3.org/mid/op.tlfl6lz6kvaitl@lessa-ii.domain
> 
> 
>  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 Monday, 2 April 2007 16:24:02 UTC