RE: What is a secure page?

I have problems mixing VPN and TLS due to the level of expertise and
availability of security services that the user has. The VPN protects
the user when the user is on the VPN protected network or Intranet, the
user may not understand the network boundaries and when they become at
risk. Users have a trust with the enterprise that I discuss later.

In addition if the page is built using stored data or applets that are
not secured or protected then the page may have no security, the stored
data could be compromised. I agree that a binary representation of
security no longer works because of the many levels of IA and yes IA
folks with the white hats are paranoid because they know that the folks
with the black hats will try everything to exploit a vulnerability.

When accessing enterprise services or a user's own services, the user
may have a high level of trust in these enterprise or local services.
The level of trust may be appropriate only because the user is an
expert and knows what they are doing and things to avoid and it may
also be possible that the enterprise has certified that they "know"
what they are doing and the IA (security) in place is at least "good
enough". 

Good enough IA between a user and a "trusted" organization like the
users enterprise may not be good enough IA when the user is adding
identity information to a 3rd party web form. We have detailed
information on how our enterprise functions that may include VPN,
encrypted backbone between sites and monitored firewalls that protect
the enterprise, this knowledge provides a level of implied trust. We
know little about the 3rd party, if the 3rd party provides the highest
level of security for the web session this may raise the level of trust
that the user has in that organization.

Bill D.
wdoyle@mitre.org



-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Stephen Farrell
Sent: Wednesday, January 03, 2007 5:55 AM
To: Yngve N. Pettersen
Cc: public-wsc-wg@w3.org
Subject: 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-active
x-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 16:37:07 UTC