Re: SSL error anti patterns

Very interesting. So in the sense that the DN specifies a single entity, 
it is "signed by the self", but it is not "self signed" in the sense that 
it's signed with the same key that's associated with the cert's public 
key. Is  that right? 

public-wsc-wg-request@w3.org wrote on 05/03/2007 09:55:11 AM:

> 
> Hello Stephen,
> 
> 
> Ordinary selfsigned certificates is not a problem, those will be 
forwarded 
> to the user as an unknown CA dialog, as you observed.
> 
> What we have in this case is that somebody creates a selfsigned root 
> certificate with the name X, including the server's name. So far, so 
good, 
> it can even be used on the server.
> 
> Then they issue a server certificate from that root, but uses the same 
> name X as subject, issued from X, but without the Authority Key 
> Identifier, (AKID, which would have solved the problem).
> 
> Then we have a certificate that looks like a selfsigned certificate, but 
 
> isn't. Trying to verify the server certificate's signature with the 
public 
> key in the server certificate will fail.
> 
> There are certainly people that think we are overly strict (and are 
quite 
> vocal about it), but I am not sure it is possible to separate out this 
> particular class of certificate and still fail on a faked or manipulated 
 
> certificate.
> 
> What it comes down to is which problems do the client block (and refuse 
to 
> load), which do they accept silently, and which do they ask the user 
> about? For this particular problem (signature verification failure) I am 
 
> not sure it is possible to separate the first and third type.
> 
> On Thu, 03 May 2007 14:18:29 +0200, Stephen Farrell 
> <stephen.farrell@cs.tcd.ie> wrote:
> 
> >
> >
> > IMO you're being overly strict there, but I can understand
> > why. I'm interested if you think that this is different from
> > a site that just uses a self-signed cert - do you & if so,
> > why?
> >
> > Opera 9.10 (installed here) does offer me the choice to go
> > ahead for my web server [1], which does have an entirely
> > good bogus self-signed cert. Would that fail with your
> > version?
> >
> > If so, then I definitely think you need a way to allow
> > users to get to such informally setup web servers. I
> > would however not have a problem if the question to the
> > user was turned around - instead of "do you want to
> > trust this cert" it could be "do you want to access this
> > site" - the former one could have other consequences if
> > the private key is also elsewhere.
> >
> > Stephen.
> >
> > [1] https://down.dsg.cs.tcd.ie/
> >
> > Yngve Nysaeter Pettersen wrote:
> >>  Hello all,
> >>  I am not quite sure if this fits into the anti-pattern discussion 
but 
> >> it may be relevant.
> >>  I occasionally have to deal with a particular type of homemade 
> >> certificates.
> >>  The certificate chain contain at least two certificates, but two of 
> >> them (A and B) have the same Distinguished Name (X) as Issuer and 
> >> Subject, but have different public keys (K_A and K_B), and one of 
them 
> >> was used to sign the other (that is, Cert_A have Subject X and Issuer 
 
> >> X, Key K_A, and is signed by K_B from Cert_B, Cert_B have Subject X 
and 
> >> key K_B, Cert B is usually selfsigned, but might be part of a longer 
> >> chain). There is no Authority Key Identifier extension.
> >>  That means that as far as the certificate validation (in Opera, at 
> >> least) is concerned the lowermost certificate (Cert_A) is selfsigned, 
 
> >> but the signature does not verify.
> >>  Opera treats this certificate as a signature verification failure 
and 
> >> issues a fatal TLS error (code 42, "Bad certificate") and refuses to 
> >> access the site, but other clients treat this is as an Unknown CA and 
 
> >> asks the user.
> >>  One live example (currently) is <URL: https://proj.koios.de/ >
> >>  Any opinions on this particular scenario, and how it should be 
handled?
> >>   On Tue, 24 Apr 2007 00:41:17 +0200, 
> >> <michael.mccormick@wellsfargo.com> wrote:
> >>
> >>> It appears ACTION-182 stems from my Lightning Discussion on 4 April 
> >>> about the cryptic IE6 browser errors that I received when I 
> >>> encountered a self-signed SSL certificate at the www.x9.org web 
site. 
> >>> According to my notes, as well as the official meeting notes from 
> >>> Thomas, we had a lively discussion about the security anti patterns 
> >>> implied by such browser error messages.  In particular I captured 
the 
> >>> following possible anti patterns in my notes:
> >>>
> >>> 1. Use of technical jargon containing terms with which the average 
> >>> layperson is not familiar.
> >>> 2. Providing a web site's URL as the only contact info for it. 
> >>> (creates "catch-22" dilemma for user)
> >>> 3. Actions suggested can't really be carried out.
> >>> 4. Consequences or risks of user actions not explained.
> >>> These are the [anti-]recommendations I propose we adopt. 
Anticipating 
> >>> comment, I haven't yet updated the wiki.  Cheers Mike
> >>
> 
> 
> 
> -- 
> 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
> ********************************************************************
>