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

RE: ACTION-240 :TLS errors...

From: Doyle, Bill <wdoyle@mitre.org>
Date: Tue, 3 Jul 2007 08:28:46 -0400
Message-ID: <518C60F36D5DBC489E91563736BA4B58018A2677@IMCSRV5.MITRE.ORG>
To: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>
Cc: <public-wsc-wg@w3.org>
Yes, details are not only needed but required. For debugging and help
desk activities.
I need to run,  are error codes standardized ? Can we do something  to
standardize or simplify help desk activities?
Bill D


	From: Mary Ellen Zurko
	Sent: Monday, July 02, 2007 6:13 PM
	To: Doyle, Bill
	Cc: public-wsc-wg@w3.org
	Subject: RE: ACTION-240 :TLS errors...
	Details that can be looked up during a help desk call are very
"Doyle, Bill" <wdoyle@mitre.org> 
Sent by: public-wsc-wg-request@w3.org 

07/02/2007 01:59 PM 

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>,
<stephen.farrell@cs.tcd.ie>, <public-wsc-wg@w3.org> 
RE: ACTION-240 :TLS errors...


	Question - Should users be put in a position to debug web
	Unless it is my web site, I only care that it is not working
	Yes it works, no it does not and who do I contact. I am not
going to
	spend time debugging someone else's web site unless they want
to kick
	in some $$. 
	Of course details need to be available to those who want or
need the
	details, what is this 5%-10% of the user population? Any stats
on users
	who know how certs work?
	Bill D.
	-----Original Message-----
	From: public-wsc-wg-request@w3.org
	[mailto:public-wsc-wg-request@w3.org] On Behalf Of Yngve N.
	(Developer Opera Software ASA)
	Sent: Thursday, June 28, 2007 4:11 PM
	To: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
	Subject: Re: ACTION-240 :TLS errors...
	What Opera does in these cases is to display a generic "Unable
	secure transaction" message and group the TLS errors into a
smaller set
	explanatory messages. We also precede this with a title that
	actual SSL/TLS/internal error code (for debug purposes) and
whether or
	it was the server that raised the alert.
	https://proj.koios.de/ (mentioned earlier) gives this
	connection: fatal error (554)".
	(the internal error code 554 = 0x22A, mod 256 this downgrades
to 0x2A =
	42, the bad_certificate alert code)
	https://mail.expedient.net/src/login.php has a revoked
certificate, and
	the following text is displayed in the warning page.
	    Secure connection: fatal error (44)
	    The certificate has been revoked by its issuer.
	On Thu, 28 Jun 2007 20:41:47 +0200, <stephen.farrell@cs.tcd.ie>
	> The action called for me to do a review of TLS errors. I went
	> through the RFC and found the attached.
	> Basically, I think that the only thing the normal user should
	> need to see is "secure connection error" (or whatever).
	> more should be a click-through to get more detail and that
	> detail should I think be intended for sys admins and not for
	> users.
	> There is probably no benefit in differentiating any of the
	> errors otherwise, since the PKI and authorization stuff is
	> afaik generally not useful. The former because no-one knows
	> what a cert is, the latter because I don't think anyone does
	> authorization at that layer - its done by the web server.
	> I don't see any point in tell normal users about crypto or
	> other errors.
	> So, I'd argue to add some text that only one TLS error ever
	> be shown, though I'm not sure how that'd be best done.
	> Regards,
	> Stephen.
	> PS: There's one potential additional thing - the
	> value in the ClientHello message could in principal cause an
	> error if a server required the time to be fresh/recent. But I
	> don't think that's done, is it? If not, then we could also
	> add a proposal that servers don't, in fact, cause an error
	> for that reason. Maybe something to raise with the TLS WG
	> in the IETF as a potential future correction.
	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 Tuesday, 3 July 2007 12:28:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC