Re: What is a secure page?

Yngve N. Pettersen wrote:
> 
> 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?

I agree with whoever said that maybe the padlock's day is done - esp. if
history is taken into account, I believe there's no way a simple binary
(or N-ary) padlock image can really express what we want. (The padlock
will of course probably have to be maintained for legacy reasons, but
perhaps its use can be restricted.)

Second preamble - I think the question is wrong since it conflates
security of the page content and the presence/absence of a TLS pipe
through which that content is accessed. The content can be entirely
secure with no use of TLS at all, e.g. when I access a local page, or
a set of pages via my VPN. And the opposite is clearly the case
unfortunately. A better question is however, hard to phrase nicely -
maybe "what combinations of TLS and cleartext accessed referenced
content makes sense to display as a "secure" unit?"

So since I'm disagreeing with the question I won't try answer most of
your questions below (probably not that qualified anyway:-)

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

Would that not disappear the padlock from may sites that really want it?
(Or am I missing some subtlety about frames or something?)

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

Again, I don't think that the rating should only be based on TLS. Is
it not practical for the browser history to detect whether or not that
content (or subunits thereof) has changed from the last time and take
that into account?

> 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]).

I find that one really annoying myself - its almost impossible for
even the paranoid to remember to check the page source, and in any
case, I don't know if the browser would reject an anonymous D-H
ciphersuite for this case. (Point being that "https://" is not
enough info.)

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

Good set of detailed questions though, even though I disagree with
the main question;-) Sorry I don't have good answers.

S.

> [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 Wednesday, 3 January 2007 10:54:23 UTC