On Sun, Aug 18, 2002 at 09:32:43PM -0400, Tom Zerucha wrote:
> I hope everyone has heard by now of the IE SSL Certificate problem:
>
> http://online.securityfocus.com/archive/1/286895/2002-08-08/2002-08-14/1
> http://www.theregister.co.uk/content/4/26620.html
>
> Some time ago, the certificates and the directory would be
> automatically installed and included when I did something like
> s_client, it would display the cert chain and information and it
> usually found things and verified it properly. Now it doesn't work.
> ANYWHERE. Apple's Mac OS X / Darwin, Linux, etc.
I do not understand your statement. OpenSSL never installed any certificates.
> I can't find any implementation that has the certificates properly
> installed. Even if all the applications work properly, they will all
> fail because the root certs won't be there to validate the chain.
I do not understand your statement. What kind of applications are you
looking for?
>
> Curl and lynx-ssl both have cert bugs, probably more severe than IE
> since they don't seem to do anything to check the certs (I have
> contacted the authors and supplied patches). I haven't checked
> wget-ssl, links-ssl, and others, but I suspect they are broken too.
See below.
> I thought Open Source was supposed to be better than Microsoft,
> especially on issues like security.
It is.
> I just spent a while searching for implementation information about
> how to CORRECTLY write the cert callback on openssl.org. I even had
> trouble finding this list. No news. No information. Nothing. A few
> sparse docs. Some links, some broken.
Here is one of the problems. Before I wrote the manual page about
for SSL_CTX_set_verify() (including verify_callback()) there was no
documentation and the example code in s_cb.c is bad in the sense that
it does not properly handle verification failures.
I discovered this while writing Postfix/TLS.
> First, the certs and hashes aren't installed by default so things
> won't work even if implemented correctly. Right now the problems with
> the applications can't be fixed with a useful result since it requires
> the signing certs to do validation. I have to do "make rehash" then
> copy the contents of the directory.
OpenSSL does not ship with root certificates. The selection of these
root certificates is a political issue that should be handled by the
application.
> Second, SSL_CTX_set_default_verify_paths(conn->ssl.ctx) isn't being
> called. There are no default paths, so many apps couldn't find them
> anyway.
There is no problem in not finding certificates. Each application developer
should decide himself which root CAs to trust.
Microsoft has the model of a central CA store. OpenSSL has no such model.
> Third, even if the callback returns "not ok", the SSL_connect function
> returns and the SSL_get_error doesn't say anything about cert errors.
This I doubt. Did you read the manual pages I wrote?
> The default callback seems to check things, but doesn't report
> anything and doesn't prevent the connection. As far as I can tell,
> the only way to pass the information from the callback to the main
> routine is via a global variable and you have to use that to exit
> after the call to SSL_connect.
>
> I don't know what the historic reasons for doing things a particular
> way, but I would suggest the following (in order of importance):
>
> 1. Install the certs by default, or if there are nontechnical reasons
> not to, add something prominent to the readmes and make process so
> that the certs directory will be populated by the users or the
> distributor creators.
We should discuss the usefulness of such a model first.
> 1a. Add the rehash function to the tools/apps that are installed.
serv01 21: ls -al /usr/local/ssl/bin
total 812
drwxr-xr-x 2 root sys 96 Aug 12 15:04 .
drwxr-xr-x 9 root sys 1024 Aug 12 15:04 ..
-rwxr-xr-x 1 root sys 3597 Aug 12 13:22 c_rehash
-rwxr-xr-x 1 root sys 409902 Aug 12 13:22 openssl
It is installed by default.
> 1b. Create an "add-on" archive for just the certs directory or
> certs.pem file so no rebuilds would be necessary.
mod_ssl used to come with a root CA bundle extracted from Netscape(?).
I remember having read information, that some CAs even consider there
CA certificates to be "protected by copyright".
> Without 1, even if everything is fixed on the app level, it would just
> render the application unusable in most cases. This might be the
> reason most applications don't bother to check security - they can't.
That's nonsense. I wrote an application myself. It can check.
> 2. Have SSL_connect FAIL UNLESS a non-default verify callback forces
> ok to be true. Have the default verify callback check the cert chain
> properly.
SSL_connect() failes, as soon as SSL_VERIFY_PEER is set by the application
and it requires a verify_callback() to override this behaviour.
> Here, the idea is that with anything to do with security, the best
> thing to do is to fail unless explicitly told not to. Either it can
> be done once here, or every app using it for browsing will need
> fixing.
This already is OpenSSL's default.
> 3. (this would be optional, but it would break more things if not
> done) Make the default paths load upon context creation, have the user
> set these to NULL if that is what is wanted.
No. The application should explicitely call it.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
