- From: Doyle, Bill <wdoyle@mitre.org>
- Date: Fri, 6 Jul 2007 21:45:40 -0400
- 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 UTC