W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007

Re: What Is A Secure Page - Templateified

From: Yngve Nysaeter Pettersen <yngve@opera.com>
Date: Fri, 06 Jul 2007 01:47:27 +0200
To: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>
Cc: "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
Message-ID: <op.tu0m1dmuvqd7e2@killashandra-ii.oslo.opera.com>

Hello Mez,

Thanks for the further comments, and I have changed the proposals  
definitions section a little, and added a "concerns" sub-section at the  
top of the overview. We will probably need to do a reflow and larger  
rephrasing of some things in one of the next iterations to address some of  
your other points.

I've also added the link to the templatified section (looks like the edit  
got dropped somewhere)

On Thu, 05 Jul 2007 14:58:25 +0200, Mary Ellen Zurko  
<Mary_Ellen_Zurko@notesdev.ibm.com> wrote:

> "
> A secure website is, for the purpose of this proposal, defined as a
> website hosted on a SSL/TLS HTTPS server, or a similar protocol offering
> end-to-end (client-server) authentication, integrity and privacy of the
> communcation.
> "
> I don't remember the authentication aspect of SSL being critical when I
> read your proposal. And if it is, it would only be the server
> authentication, not the optional client authentication. You might want to
> clarify that part.

The authentication of the server is a necessary part of assuring the  
privacy of the connection, at least against an attacker that is able to  
observe the start of the connection.

It is possible to use anonymous SSL/TLS,  but these methods are vulnerable  
to man in the middle attacks, and there is no way to determine that it is  
happening.

>> > " Change from and unsecure to secure parts of a service SHOULD be done
> by
>> > direct links, and not redirects. If unsecure->secure redirects are
> needed
>> > then the redirect SHOULD be immediate, and not multistep. This lets
> the
>> > user know where he or she is headed before intiating the transition. "
>> >
>> > This reasoning seems wrong to me. Users don't really know where
> they're
>> > going, and we're not encouraging the use of URLs to figure out where
>> > you're going and where you are, since they're not secure and usable
> SCIs.
>>
>> This requirement encourages transparency to interested users, and it
> also
>> makes for easier logic when implementing the SCI.
>
> It will be easier to align this when everything is organized in the rec
> track document. But it sounds like you're talking about secondary SCI
> transparency ("interested users"), not primary SCI.

"Interested users" are the ones that will keep penny pinching webservices  
 from compromising security.

As I say, requiring direct transitions also reduces the complexity the  
logic for determining if the document is reasonable secure.

In fact, what I'd prefer is that the client only accept an unsecure to  
secure redirect as "secure" if it was the user that entered the address,  
in all other cases a unsecure to secure redirect should be considered the  
same as mixing secure and unsecure content. (In fact, Opera already does  
this if the user did not directly initiate the loading by clicking on the  
link, but the action was initiated by Javascript).

>> Just want to be sure: Do I understand this to mean that we should use
> SCI
>> exclusively instead of "security level indicator", "padlock", etc?
>
> I would like us to develop consistent terminology. Security Context
> Indicator (SCI) seems like the right one to me (unless we're referring to
> more specific instances of SCIs). If I use the "concensus" word, then
> anyone who disagrees should speak up :-). And it can/should be a term in
> the Glossary or Definitions section (which we'll need, OK Shawn?).

We can rephrase/add  that in the next iteration of the proposal.

>>   2. Server-only selfsigned certificates, or an broken chain that does
> not
>> link to a known root. In this case you do not generally know who is
>> running the server, and it may even be a man-in-the-middle. In such
> cases
>> accepting the connection offers little, if any, better protection than
>> clear text HTTP (i.e., none). This type of sites is the target for the
>> above proposal.
>
> Sure I do, it's IBM. I don't mean to be dense; how is it that,
> hypothetically, I don't know that a self signed cert for, say,
> shakespeare.notesdev.ibm.com isn't run by IBM?



Well, you don't know if the server was authorized by the network  
administrator, and hasn't been set up by some internal renegade (The  
Insider threat). It may even be that the renegade managed to hack the DNS  
server and is routing you to his server trying to get your passwords.

The key thing (as I am sure you know) is that, unless you phone the  
"shakespeare" administrator or walk down to the office, assuming you can  
be sure you get the right person, and then compare the certificate's  
fingerprints, you cannot be reasonably sure you are connecting to the  
correct site.

A major problem in these scenarios is how a client can tell the "Yes, this  
is our company's internal high secure site" scenario from the "Yes, I want  
to visit this amateur phishing site, just leave me alone so I can be  
defrauded" scenario. The best way to handle it would be to encourage all  
the administrators of the first to either get third-party site, or make  
their own root, then the second case would be more obvious.

My point is: In such a situation, where the client have to ask the user to  
validate the site's certificate (I am not talking about unknown CA roots),  
is it correct to represent the site as "secure" or "protected"? In my  
opinion (but I may be a little more hardline than most about this), we  
should not call such sites "secure".

-- 
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, 5 July 2007 23:47:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:48 GMT