Re: What is a secure page?

Hello Michael,

It is not my intention to discuss levels of encryption in this thread or  
indication of such levels, but one might add a presumption that the  
encryption used is "good enough" to be considered secure (Opera would  
display level 1 padlock, in 9.10 no padlock, *and* a warning in cases of  
any weak cipher suites being used).

My intention is to open up a discussion about what kind of  
combinations/sequences of (reasonably) secure, encrypted documents and  
(completely) unsecure documents can be considered secure, and should be  
indicated in the UI as secure (regardless of how such an indication works).

On Tue, 02 Jan 2007 18:19:24 +0100, <michael.mccormick@wellsfargo.com>  
wrote:

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



-- 
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 19:20:12 UTC