Re: SSL error anti patterns

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

Received on Thursday, 3 May 2007 13:59:15 UTC