Re: What is a secure page?

Hi,

Yngve Nysaeter Pettersen wrote:
> I think VPN (or IPSec,etc.) cannot be considered part of this question, 

Note that the VPN example was raised simply as a counterexample to
the presumed statement "not via SSL => not secure".

> because 1) it's use is unknown to the application types (I think) we are 
> considering, and 2) it is a network-to-network connectivity which does 
> not provide any protection against eavesdropping inside either of the 
> end networks, but only secures the connection between the two networks.

I agree - there are generally no good interfaces to VPNs that a browser
could use in any case. However, I guess we might want to say something
about a VPN use-case somewhere, even if only to encourage the VPN folks
to finally offer such interfaces to applications. Do we want to do that?

> What this is about is the security of the client's connections to one or 
> more servers, what the application knows (and can know) about these 
> connections and whether or not the information might have been tampered 
> with on the way from the producing application to the client, and how 
> the resulting security summary can be presented to the user.
> 
> But to clarify, perhaps the subject can be rephrased to "What is a 
> secure networked page?"

IMO the above two paragraphs are in conflict. Information about
an SSL session is not the same as information about the content
of a page. They can be related, but I think they are not the same
from the security p-o-v.

> There are, of course, a number of other consideration, like what the 
> user knows about the network or the server, but this is information that 
> the client cannot know, act on, or include in what it presents to the user.

My hope would be that we can help browser developers to include
such information in future, where it is available (which sometimes
may be from the user/browser-history).

> 
> More inline, below.
> 
> On Wed, 03 Jan 2007 11:55:00 +0100, Stephen Farrell 
> <stephen.farrell@cs.tcd.ie> wrote:
> <snip>
>> 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?"
> <snip>
> 
>>> 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?)
> 
> No. Point B is about pages where the source is loaded over an encrypted 
> connection, but an image, frame, or a script was loaded unencrypted. 
> Such pages should not be considered secure.
> 
> Serious sites should not mix content from https and http servers, in 
> particular when the main document is https.

I guess I was wondering whether or not all "serious" sites actually
do do this. My impression was that they didn't, but that may be out
of date.

> 
> For why such mixing can be a problem, plase see this example I included 
> in my original post:
> 
>>>  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].
> 

Sure.

>>>  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?
> 
> I am not sure I understand what you want here.

I want the browser to be cleverer about how it deals with security...
...same as we all do!

Basically, I think that the current situation where the primary
browser security indicator is tied to the TLS protocol is not a
very good approach. I think we should (in this group) derive an
abstraction of the security context available (which may include
historic information as well as 3rd party information) and we
should then try figure out how to map that to some GUI that makes
sense to various types of user (and in doing that we should IMO
more-or-less ignore the existence of protocol experts - EKR is
not a user here:-)

A part of that mapping will be to consider what to do about the
current padlock scheme, but I think, for now, its premature for
us to be talking about specific changes to padlocks, since we
don't yet have the abstraction of the security context. (Getting
to know more about the details of how current padlocks work and
what developers are planning is of course entirely appropriate
at this stage),

Regards,
S.

PS: When I said "more-or-less" above, I mean that an expert
user should have to specially configure, click through or use
some odd tools to get the full details of what's going on. I
do think that the info should be available, but it ought not
be offered by default, or even easily.

Received on Thursday, 4 January 2007 18:01:30 UTC