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

RE: ACTION-240 :TLS errors...

From: Doyle, Bill <wdoyle@mitre.org>
Date: Fri, 6 Jul 2007 21:45:40 -0400
Message-ID: <518C60F36D5DBC489E91563736BA4B58018A2983@IMCSRV5.MITRE.ORG>
To: <michael.mccormick@wellsfargo.com>, <tlr@w3.org>
Cc: <stephen.farrell@cs.tcd.ie>, <public-wsc-wg@w3.org>


Two things

1. I have trouble with WSC signing risk to a site. Due to the risk of
user system compromise and possible long lasting impact to the user if
site is broken the user should work risk out with help desk. If the web
server has been corrupted with malware and page allowed to load it may
be too late for the user, the users system can be taken over or
corrupted. Now that I know how easily a system compromise occurs and
this type of attack is expected to become more frequent I have changed
my mind on error processing. The site is broken, halt processing on
security error, out of band user queries help desk and figures out how
to proceed. If the help desk tells the user to proceed and users system
is compromised, it is a problem between the user and help desk.

2. maybe I read this wrong, do we have an error condition with a valid
self signed cert? If it is a trusted user site, it is perfectly valid.
User may even have a higher confidence in a self signed cert that a
high value cert.

Bill D.


-----Original Message-----
From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of
michael.mccormick@wellsfargo.com
Sent: Friday, July 06, 2007 6:53 PM
To: tlr@w3.org
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: RE: ACTION-240 :TLS errors...


We should probably add something like that as an example since the
recommendation is open to interpretation (although some may prefer it
that way :).

The recommendation lists 5 requirements:

1. Allow technical user to access details of the error in a secondary
user interface (UI) but hide them in the primary UI.
2. Primary UI security context indictors should reflect the error
without displaying details.
3. Confine technical jargon to the secondary UI.
4. When user is asked to make a decision, explain the risks of each
option presented.
5. Do not refer the user to the destination URL or domain for
assistance.

Here's an imaginary example of how (IMO) a browser maker might
reasonable apply them to a self-signed server SSL cert:

 - On main window display "Security connection error".
 - Allow the page to load.
 - Adjust graphical SCIs (padlock, color bar, speedometer, etc.)
appropriately.
 - If user clicks on the main error message or SCI, pop a dialog box
with tabs for "Cause" and "Risk".
 - If user click the Risk tab, s/he sees an explanation of the risks of
browsing a site with self-signed SSL.
 - If user click the Cause tab, s/he sees technical details about the
server cert and what's suspicious about it.

Mike

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Friday, July 06, 2007 1:01 PM
To: McCormick, Mike
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: Re: ACTION-240 :TLS errors...

On 2007-07-05 22:37:04 -0500, michael.mccormick@wellsfargo.com wrote:

> I think what you're proposing sounds consistent with the 
> recommendations presented in 
>
http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/CertErr

I'm not sure I can tell from the material in the Wiki what kind of
behavior would be expected from a self-signed certificate.  Mind
elaborating?  Or is that to be covered elsewhere?

--
Thomas Roessler, W3C  <tlr@w3.org>
Received on Saturday, 7 July 2007 01:45:56 GMT

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