Re: IMAP certificate warning

[Brian Stafford <brian stafford uklinux net>]

On Fri,  9 November 10:20 Carlos Morgado wrote:
> 
> On 2001.11.09 09:11:22 +0000 Brian Stafford wrote:

>> I guess you know what is in the next paragraph but I'll say it anyway :)
>> ===
>> 
>> Regarding validation of the server certificate in a client; the SSL/TLS 
>> protocol will supply the server certificate to the client.  The default 
>> validation callback in OpenSSL handles the typical case reasonably, however 
>> if it cannot verify the certificate based on the trusted CAs or the cert is 
>> self signed or is otherwise inconsistent, the call to SSL_connect() will
> 
> aparently this is not the case. Toralf has a 'real' cert

that was my guess too.

>> fail and no TLS session is established.  For this reason, it might be 
>> useful to supply a custom validation callback which accepts any certificate 
>> for establishing a connection, this will allow SSL_connect() to succeed 
>> with unknown CAs etc.  Either way, SSL_get_verify_result() can then be used 
>> to decide whether to proceed; even with the default callback there are 
>> conditions where some clients might not accept a certificate that is 
>> otherwise acceptable to OpenSSL.
>> 
> the openssl callback stuff looks yucky to me. maybe i don't understand the 
> paradigm :)

Its not that easy; I haven't got to the bottom of it either :(

> 
>> ===
>> End of stating the obvious ;)
>> 
>> What I suspect is happening is that Balsa does not have a list of trusted 
>> top level CAs and hence is unable to verify that the official certificate 
>> is genuine.  If you look for starttls_create_ctx() in smtp-tls.c (with the 
>> libESMTP distro) you will see my approach to setting up the trusted CA 
>> list.  I guess libmutt does something similar.
>> 
> SSL_CTX_new

OK, probably need to make sure SSL_CTX_load_verify_locations() is called too.

>> Part the problem here is that OpenSSL (AFAIK) has no system wide structure 
>> for configuring CRLs, CA certifictates etc. so every application does its 
>> own thing.  It is possible that the top level CAs are set up for another 
>> app. but balsa (or libESMTP for that matter) has no idea where they are, 
>> even if the other app is an OpenSSL one.  Another problem is that certs are
> 
> oh. crap crap crap. i my disgust for openssl grows everyday.

documentation would help - sigh!

Actually there is a SSL_CTX_set_default_verify_paths() which sounds like it is 
some kind of default for certs but I don't know for sure.  Also app has to 
call it so its not really a system location which is used if an app specific 
directory is not requested.  Uugh!

>> stored in PEM format which is simple but not used by most CAs.  This means 
>> most punters will have a problem installing the CA certificate - worse, it 
>> has to be done for every app.  Since some apps will try to use more
> 
> hum. mutt does have a 'always accept this cert' option in the user iteraction

Can be handy, but the real problem is determining that the server certificate 
is not a forgery.  You need the CA certificate for that.  If unverifiable 
certs are accepted the client becomes susceptible to a man-in-the-middle or 
other spoofing attack.

E.g. client is tricked into connecting to hostile server.  Hostile presents 
forged cert, client cannot verify (so is protected) but user accepts anyway 
(not protected any more).  Hostile connects to real server.  Client presents 
cert or other authentication to hostile which is passed on to the real 
server.  Hostile now monitors all traffic between client and real server and 
steals mail and passwords, credit card numbers etc.

>> conventional certificate formats than PEM installation is a nightmare - 
>> convert to format for app a, store in directory for app a - convert to 
>> format for app b ... you get the picture.
>> 
> *barf*

Yep!

>> A thought occurrs to me.  I noticed the GNU TLS suite mentioned on 
>> Freshmeat the other day.  Perhaps we should look into this for TLS in our 
>> (L)GPLed programs; if we got in soon enough it might be in time to solve 
>> the certificate management side of things on a system wide basis.  Thoughts?
>> 
> 
> aparently it uses libgcrypt which should be a good thing. is supporting only
> tls and ssl3 bad ? is ssl2 still used ?

SSL 2 is supported mostly be web servers because there are a lot of old 
netscapes out there with no ssl 3 support.  For other protocols, there 
shouldn't be any reason to support ssl 2.  Given SSL 2 is subject to downgrade 
attacks supporting it at all is probably a bad idea.

Brian