Re: What Is A Secure Page - Templateified

Hello Mez,

Thanks for the feedback.

On Wed, 27 Jun 2007 22:49:36 +0200, Mary Ellen Zurko  
<Mary_Ellen_Zurko@notesdev.ibm.com> wrote:

> HI Yngve,
>
> Or maybe all you mean by "secure" is "using a secure form of transport,
> which is reflected in the primary SCI". Or maybe you mean "protected" as
> in "protected in transit with a cryptographic protocol that is reflected
> in the SCI".

I think the latter definition is the closest to what I mean.

In this discussion my primary concerns are end-to-end protection of the  
data, the strength of the methods used to protect the data, and how to  
present (to the user) a summary of the information about the methods used  
to download the content presented to the user.

Another major concern is how to handle or present this information when  
part of the presented content is not protected by such methods.

A third major concern is how to handle a transition from unprotected to  
protected mode when the user provided data to be transmitted in the  
protected mode was entered into the client via content (aka forms) that  
was not received in the protected mode.

With respect to the term "padlock" I am using that as the name of the SCI  
as it is the most commonly used indicator.

I have added a defintions section at the top of the overview. Please take  
a look, and see if that resolves the definition problem, or if we should  
find some other phrasing. If new phrasing is in order I am open to  
suggestions. I am not sure that "protected" is better than "secure" as a  
description here.

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

There are IMO far too many sites that use a http->https redirect from  
their "sign on" link, and there are AFAIK quite a lot that bounces around  
between multiple HTTP servers before going to the HTTPS server.

Previously I mentioned that Bank of America seemed to be doing such  
"bouncing", including a forced reload to make sure they got a padlock, but  
it looks like they have gotten better, and are now using a HTTPS-only  
frontpage <thumb-up>.

> "Clients MUST display padlock/security information in a manner that
> clearly separates it from what the content controls."
> This shold be rephrased as:
>
> "Clients MUST display any primary SCIs in a manner that clearly separates
> them from what the content controls."

Just want to be sure: Do I understand this to mean that we should use SCI  
exclusively instead of "security level indicator", "padlock", etc?

> "A client MUST NOT submit passwords from an unsecure page (even if the
> form is in a "secure" frame) to a secure server. Enhancement suggestion:
> Do not permit focus/input to the password forms field. "
>
> There is a robust discussion on this on TAG (which I believe I'm meant to
> do something about). See this message and the replies:
> http://lists.w3.org/Archives/Public/www-tag/2007Jun/0130.html
> This will give you a sense of the potential comments on this one. It  
> would
> be good to do what we can to understand and minimize them.

This part of the proposal does somewhat overlap with the "do not solicit  
passwords in clear text" item, but I think the above is more limited in  
scope. The wording above only apply to situations where the password will  
not be sent in the clear, but the "input mechanism" was transmitted in the  
clear. In this case one cannot consider the password to be protected in  
any way from an attacker that is able to edit the unprotected data used to  
create the page.

With respect to the onsubmit aspect of the post you referenced, the  
security of a password encoded in this fashion is non-existent for a  
form/page transmitted in the clear (unprotected), unless one assume an  
attacker that can only listen to the traffic and not modify it. I suspect  
that such an attacker can only exist in theoretical scenarios (well, there  
may be one case: if the traffic from a network is somehow mirrored oneway  
to another network, such as a wiretap).

(I wasn't able to get to the references because the list server had  
stopped responding by the time I started looking for them)

About the warning about onsubmit: For quite a while Opera refused to let  
JavaScript access password fields due to security concern, then we had to  
step by step relax it via just giving the scripts bogus data, limited  
length, warning dialogs and so on, until we finally had to surrender and  
allow unlimited access because of usability issues and the number of  
websites that broke down because we restricted access.

IIRC some of the Netscape Javascript versions had a "tainted" flag meant  
to prevent some forms of outside distribution. AFAIK it's been removed in  
later versions.

> "The results of immediate (within 15-30 seconds?) automatic
> Meta/javascript redirects SHOULD NOT get a security level higher than the
> original document. "
>
> Why not? I missed any explanation of this one.

Maybe I should add something on this.

The point of this requirement is to prevent a page that have been mixing  
protected and unprotected content, for example as a result of redirect  
back and forth between HTTP and HTTPS servers, to get itself back to a  
"this is secure" SCI by doing a simple reload of the content (for example,  
what it looked like BoA was doing earlier).

> "A client SHOULD NOT display a padlock (or similar security indicator) if
> at least one of the resources required user interaction to accept the
> certificate of the server or other security protocol related problem,  
> also
> if the user have specified that he should not be asked about that
> particular site certificate again. This does not apply to root
> certificates installed separately by the user. "
>
> I disagree. I regularly work with certs not from a CA. I would deeply
> distrust any security indicator that did not claim that the IBM  
> configured
> servers I work with are secure (because in fact I believe they are). That
> said, if there is something IBM can and should be doing to properly
> install our certificates on our many, many desktops, I would change my
> opinion. Your last sentence indicates there might be something.

There are two scenarios here:

  1. The site's certificate is issued from a CA, and the CA root  
certificate can be installed. In this case there is (supposedly) a chain  
to somebody responsible for issuing the certificates. We have several  
internal servers with certificate issued in this fashion, and my guess is  
that this would be the situation at IBM, too. In this case it is quite  
allright to consider the site secure. (Please note the sentence "This does  
not apply to root certificates installed separately by the user")

  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.

As far as Opera is concerned we already implement the above for #2. If the  
user is asked to OK a site's certificate then Level 1 (of 3) security is  
assigned, and in 9.x that means no padlock.

> "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
> Sent by: public-wsc-wg-request@w3.org
> 06/23/2007 07:44 PM
>
> To
> "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
> cc
>
> Subject
> What Is A Secur ePage - Templateified
>
>
>
>
>
>
>
> <URL: http://www.w3.org/2006/WSC/wiki/WhatIsASecurePage#preview >
>
> Hello all,
>
> I have just modified my "What is a secure page?"-proposal so that it
> conforms (at least roughly) to the most recent template.
>
> There may still be a couple of rough spots, and I combined the overview
> and background section from the template into a single section.
>
> I added a couple of new proposals for EV, based on recent findings, as
> well as a comment about servers still using 512 bit RSA keys (the most
> recent I found are both banks).
>
> Comments and suggestions?
>



-- 
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, 28 June 2007 00:15:10 UTC