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
********************************************************************