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 Sunday, 31 December 2006 16:16:54 UTC