Re: SSL error anti patterns

On Mon, 21 May 2007 21:54:53 +0200, Mary Ellen Zurko  
<Mary_Ellen_Zurko@notesdev.ibm.com> wrote:

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

Yes. That is exactly what is going on.

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



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

Received on Monday, 21 May 2007 20:04:56 UTC