RE: ACTION-240 :TLS errors...

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?
 
Thx
Bill D
 
 

________________________________

	From: Mary Ellen Zurko
[mailto:Mary_Ellen_Zurko@notesdev.ibm.com] 
	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
useful. 
	
	          Mez
	
	
	
	
	
"Doyle, Bill" <wdoyle@mitre.org> 
Sent by: public-wsc-wg-request@w3.org 

07/02/2007 01:59 PM 

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

	




	
	Question - Should users be put in a position to debug web
sites? 
	
	Unless it is my web site, I only care that it is not working
correctly.
	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.
Pettersen
	(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
to
	complete  
	secure transaction" message and group the TLS errors into a
smaller set
	of  
	explanatory messages. We also precede this with a title that
indicates
	the  
	actual SSL/TLS/internal error code (for debug purposes) and
whether or
	not  
	it was the server that raised the alert.
	
	Examples:
	
	https://proj.koios.de/ (mentioned earlier) gives this
sub-message
	"Secure  
	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>
wrote:
	
	>
	> 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).
Anything
	> 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
gmt_unix_time
	> 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.
	
	
	
	-- 
	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
	
********************************************************************