Re: What is a secure page?

I'm afraid my primary viewpoint concerns application-to-application  
protocols like HTTPS/TLS/SSL vs. HTTP, without any knowlegde about the  
underlying system (which have to be considered untrusted).

I think VPN (or IPSec,etc.) cannot be considered part of this question,  
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.

Likewise, I also think document loaded via the file system is out of scope  
because, depending on your operating system, it is not possible to tell if  
a resource is really served by another computer and whether or not that  
connection is secure. OTOH, security of temporary files (such as cache)  
might be an issue, but websites can control this to some extent using  
Cache-Control directives.

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?"

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.

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.

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


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

Redirects are usually not kept for long, and in any case there might not  
be any previous visits to the site to base any evaluation on.

<snip>

-- 
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 Thursday, 4 January 2007 17:18:00 UTC