OpenSSL Applink

On Windows the OpenSSL guys have included code with 0.9.8 and above to
allow OpenSSL to work correctly regardless of the MSVC runtime libraries
that have been used with the host application. This has become noticable
with the MSVC++ build in which any client apps that connect using libpq
with a client certificate will bail out with an error such as:

C:\pgsql-8.3>bin\psql -p 5433 postgres
OPENSSL_Uplink(00314010,05): no OPENSSL_Applink

The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.

I'm not sure what the OpenSSL guys were thinking here - apps like
pgAdmin which previously didn't use OpenSSL directly now need the source
code to build. I've also seen reports on the -odbc list that psqlODBC is
similarly affected, though how on earth we're meant to get the AppLink
code into apps such as MS Access or Crystal Reports is beyond me.

Regards, Dave

Dave Page <dpage(at)postgresql(dot)org> writes:
> The server doesn't seem to be affected, but the attached patch fixes the
> problem for the client apps. Unfortunately it must be included in the
> app itself, and not libpq.

This is pretty much in the category of "they've got to be kidding".
I recommend sitting on the prior version until upstream fixes their
mistake.

regards, tom lane

Tom Lane wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
>
>> The server doesn't seem to be affected, but the attached patch fixes the
>> problem for the client apps. Unfortunately it must be included in the
>> app itself, and not libpq.
>>
>
> This is pretty much in the category of "they've got to be kidding".
> I recommend sitting on the prior version until upstream fixes their
> mistake.
>
>
>

That was my reaction.

cheers

andrew

Tom Lane wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
>> The server doesn't seem to be affected, but the attached patch fixes the
>> problem for the client apps. Unfortunately it must be included in the
>> app itself, and not libpq.
>
> This is pretty much in the category of "they've got to be kidding".

Agreed. Unless I've completely missed the point this does seem *really*
dumb.

> I recommend sitting on the prior version until upstream fixes their
> mistake.

Unfortunately from what I've seen it doesn't look like thats on their
agenda... and this has been around in release versions now since July 2005.

I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively few people using client-side certs I'd wager.

/D

Dave Page wrote:
>
> I believe we just didn't notice it until now because the older Mingw
> builds use the MSVC 6.0 runtimes which just happened to be compatible
> with the OpenSSL binary builds (we're now using 8.0), in addition to
> which there are relatively few people using client-side certs I'd wager.
>
>

So SSL works without this wart if you don't have a client cert?

cheers

andrew

Andrew Dunstan wrote:
>
>
> Dave Page wrote:
>>
>> I believe we just didn't notice it until now because the older Mingw
>> builds use the MSVC 6.0 runtimes which just happened to be compatible
>> with the OpenSSL binary builds (we're now using 8.0), in addition to
>> which there are relatively few people using client-side certs I'd wager.
>>
>>
>
> So SSL works without this wart if you don't have a client cert?

Yep.

/D

Dave Page wrote:
> Andrew Dunstan wrote:
>>
>>
>> Dave Page wrote:
>>>
>>> I believe we just didn't notice it until now because the older Mingw
>>> builds use the MSVC 6.0 runtimes which just happened to be
>>> compatible with the OpenSSL binary builds (we're now using 8.0), in
>>> addition to which there are relatively few people using client-side
>>> certs I'd wager.
>>>
>>>
>>
>> So SSL works without this wart if you don't have a client cert?
>
> Yep.
>
>

Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.

cheers

andrew

Andrew Dunstan wrote:
> Then I think I'd rather disable use of client certs for the offending
> openssl versions in libpq, or let the apps die and refer the customers
> to the openssl people to lobby them for a sane solution.

If this were 8.0 I'd agree, but thats not a nice solution for those
already using client certs (such as the pgAdmin user who brought this to
my attention).

:-(

/D

Dave Page wrote:
> Andrew Dunstan wrote:
>> Dave Page wrote:
>>> I believe we just didn't notice it until now because the older Mingw
>>> builds use the MSVC 6.0 runtimes which just happened to be compatible
>>> with the OpenSSL binary builds (we're now using 8.0), in addition to
>>> which there are relatively few people using client-side certs I'd wager.
>>
>> So SSL works without this wart if you don't have a client cert?
>
> Yep.

According to the OpenSSL FAQ, the purpose of the applink is to allow
mixing release and debug versions or multi-threaded and
non-multithreaded versions of libraries:

http://www.openssl.org/support/faq.html#PROG2

How come we only bump into the crash with client certs?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:
> Dave Page wrote:
>> Andrew Dunstan wrote:
>>> Dave Page wrote:
>>>> I believe we just didn't notice it until now because the older Mingw
>>>> builds use the MSVC 6.0 runtimes which just happened to be compatible
>>>> with the OpenSSL binary builds (we're now using 8.0), in addition to
>>>> which there are relatively few people using client-side certs I'd wager.
>>> So SSL works without this wart if you don't have a client cert?
>> Yep.
>
> According to the OpenSSL FAQ, the purpose of the applink is to allow
> mixing release and debug versions or multi-threaded and
> non-multithreaded versions of libraries:
>
> http://www.openssl.org/support/faq.html#PROG2

Yeah - which in itself is a pita because with their 'workaround' we now
need to ensure we use a debug libpq with a debug pgadmin whereas
previously mixing 'n' matching wasn't an issue.

> How come we only bump into the crash with client certs?
>

I assume it uses fopen() or one of the other functions it does a
GetProcAddress() on in that situation.

/D

Dave Page <dpage(at)postgresql(dot)org> writes:
> Andrew Dunstan wrote:
>> Then I think I'd rather disable use of client certs for the offending
>> openssl versions in libpq, or let the apps die and refer the customers
>> to the openssl people to lobby them for a sane solution.

> If this were 8.0 I'd agree, but thats not a nice solution for those
> already using client certs (such as the pgAdmin user who brought this to
> my attention).

Doesn't really matter. Even if we were willing to hack our own client
apps like that (which I'm not), we can *not* transfer such a requirement
onto every libpq-using application. It's just not acceptable.

regards, tom lane

Tom Lane wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
>> Andrew Dunstan wrote:
>>> Then I think I'd rather disable use of client certs for the offending
>>> openssl versions in libpq, or let the apps die and refer the customers
>>> to the openssl people to lobby them for a sane solution.
>
>> If this were 8.0 I'd agree, but thats not a nice solution for those
>> already using client certs (such as the pgAdmin user who brought this to
>> my attention).
>
> Doesn't really matter. Even if we were willing to hack our own client
> apps like that (which I'm not), we can *not* transfer such a requirement
> onto every libpq-using application. It's just not acceptable.

*We're* not transfering any requirement. I've fixed pgAdmin for example
without any need to touch any Postgres code. If you don't want to
include the fix (which I can quite understand) it'll just mean that the
PG utilities won't work with client certs.

/D

On 9/28/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
> > Andrew Dunstan wrote:
> >> Then I think I'd rather disable use of client certs for the offending
> >> openssl versions in libpq, or let the apps die and refer the customers
> >> to the openssl people to lobby them for a sane solution.
>
> > If this were 8.0 I'd agree, but thats not a nice solution for those
> > already using client certs (such as the pgAdmin user who brought this to
> > my attention).
>
> Doesn't really matter. Even if we were willing to hack our own client
> apps like that (which I'm not), we can *not* transfer such a requirement
> onto every libpq-using application. It's just not acceptable.

Is it possible to use GNUTLS on Windows?

--
marko

Marko Kreen wrote:
> On 9/28/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Dave Page <dpage(at)postgresql(dot)org> writes:
>>> Andrew Dunstan wrote:
>>>> Then I think I'd rather disable use of client certs for the offending
>>>> openssl versions in libpq, or let the apps die and refer the customers
>>>> to the openssl people to lobby them for a sane solution.
>>> If this were 8.0 I'd agree, but thats not a nice solution for those
>>> already using client certs (such as the pgAdmin user who brought this to
>>> my attention).
>> Doesn't really matter. Even if we were willing to hack our own client
>> apps like that (which I'm not), we can *not* transfer such a requirement
>> onto every libpq-using application. It's just not acceptable.
>
> Is it possible to use GNUTLS on Windows?
>

No, I don't think so. I didn't think we accepted Martijn's(?) patch for
it anyway?

Regards, Dave

Dave Page wrote:
>>
>> Is it possible to use GNUTLS on Windows?
>>
>
> No, I don't think so. I didn't think we accepted Martijn's(?) patch
> for it anyway?
>
>

This mess might make that worth revisiting, if it can be used on
Windows. See http://josefsson.org/gnutls4win/

cheers

andrew

Dave Page <dpage(at)postgresql(dot)org> writes:
> Tom Lane wrote:
>> Doesn't really matter. Even if we were willing to hack our own client
>> apps like that (which I'm not), we can *not* transfer such a requirement
>> onto every libpq-using application. It's just not acceptable.

> *We're* not transfering any requirement. I've fixed pgAdmin for example
> without any need to touch any Postgres code.

Well, yeah, we are, as evidenced by the fact that you had to do
something to pgAdmin. Every other application that uses libpq would
also be facing source code changes to make it work.

Is there really no way to solve this within libpq?

regards, tom lane

Tom Lane wrote:
> Dave Page <dpage(at)postgresql(dot)org> writes:
>> Tom Lane wrote:
>>> Doesn't really matter. Even if we were willing to hack our own client
>>> apps like that (which I'm not), we can *not* transfer such a requirement
>>> onto every libpq-using application. It's just not acceptable.
>
>> *We're* not transfering any requirement. I've fixed pgAdmin for example
>> without any need to touch any Postgres code.
>
> Well, yeah, we are, as evidenced by the fact that you had to do
> something to pgAdmin. Every other application that uses libpq would
> also be facing source code changes to make it work.

Yes, but it's not us requiring it (except in as much as we provide some
level of SSL support) but the OpenSSL crew.

> Is there really no way to solve this within libpq?

Including the applink code in libpq was the first think I tried but it
doesn't work (apparently because there is no way to ensure that any
random module containing it isn't unloaded before it's needed which
sorta makes sense).

I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my evening
trying to figure it out?

-----
But for new and evolving code [I suppose JNI would be rather
new and evolving] applink should not be preferable option, as there is a
way around it, namely avoid passing FILE* to BIO, but instead let BIO
open files for you, i.e. avoid BIO_new_fp and stick to BIO_new_filename.
Note that applink is engaged purely on demand and it doesn't have to be
present in application if application doesn't pass FILE* to BIO.
-----

/D

Dave Page wrote:
> I did stumble across this text on a mailing list in response to someone
> with a similar problem in some JNI code. I know little of the OpenSSL
> API, but perhaps it rings bells with you before I spend my evening
> trying to figure it out?

OK, I think I've figured out a fix. Working up a patch now...

/D

Dave Page wrote:
> Dave Page wrote:
>> I did stumble across this text on a mailing list in response to someone
>> with a similar problem in some JNI code. I know little of the OpenSSL
>> API, but perhaps it rings bells with you before I spend my evening
>> trying to figure it out?
>
> OK, I think I've figured out a fix. Working up a patch now...

Patch attached.

It appears to work fine except that if the client certificate is
missing, instead of:

could not open certificate file "C:\Documents and
Settings\Dave\Application Data/postgresql/postgresql.crt": No such file
or directory

I get:

Error connecting to the server: SSL SYSCALL error: Operation would block
(0x00002733/10035)

for reasons that are not clear to me. Any ideas?

Regards, Dave

Dave Page wrote:
> Dave Page wrote:
>> Dave Page wrote:
>>> I did stumble across this text on a mailing list in response to someone
>>> with a similar problem in some JNI code. I know little of the OpenSSL
>>> API, but perhaps it rings bells with you before I spend my evening
>>> trying to figure it out?
>> OK, I think I've figured out a fix. Working up a patch now...
>
> Patch attached.

(sorry, been offline for the day)

Is there any reason not to just do this on *all* platforms, and get rid
of all the #ifdefs?

The new code actually seems cleaner to me than what we did before,
really... Since it lets OpenSSL do all the work for it.

> It appears to work fine except that if the client certificate is
> missing, instead of:
>
> could not open certificate file "C:\Documents and
> Settings\Dave\Application Data/postgresql/postgresql.crt": No such file
> or directory
>
> I get:
>
> Error connecting to the server: SSL SYSCALL error: Operation would block
> (0x00002733/10035)
>
> for reasons that are not clear to me. Any ideas?

I wonder if it might be related to our socket/signal emulation stuff.
I'd be interested to see what happens with the same code on Unix, but
sorry, don't have time to test myself - will be offline again tomorrow :-(

//Magnus

Magnus Hagander wrote:
> Dave Page wrote:
>> Dave Page wrote:
>>> Dave Page wrote:
>>>> I did stumble across this text on a mailing list in response to someone
>>>> with a similar problem in some JNI code. I know little of the OpenSSL
>>>> API, but perhaps it rings bells with you before I spend my evening
>>>> trying to figure it out?
>>> OK, I think I've figured out a fix. Working up a patch now...
>> Patch attached.
>
> (sorry, been offline for the day)
>
> Is there any reason not to just do this on *all* platforms, and get rid
> of all the #ifdefs?

Yes, (see the comment in the code). We stat the private key on *nix to
ensure it hasn't changed underneath us which can't be done using the BIO
functions... though I wonder if we can get the FILE pointer from BIO and
do it that way. Should be as safe on *nix as what we currently do.

> I wonder if it might be related to our socket/signal emulation stuff.
> I'd be interested to see what happens with the same code on Unix, but
> sorry, don't have time to test myself - will be offline again tomorrow :-(

NP.

/D

Dave Page wrote:
> Magnus Hagander wrote:
>> Dave Page wrote:
>>> Dave Page wrote:
>>>> Dave Page wrote:
>>>>> I did stumble across this text on a mailing list in response to someone
>>>>> with a similar problem in some JNI code. I know little of the OpenSSL
>>>>> API, but perhaps it rings bells with you before I spend my evening
>>>>> trying to figure it out?
>>>> OK, I think I've figured out a fix. Working up a patch now...
>>> Patch attached.
>> (sorry, been offline for the day)
>>
>> Is there any reason not to just do this on *all* platforms, and get rid
>> of all the #ifdefs?
>
> Yes, (see the comment in the code). We stat the private key on *nix to
> ensure it hasn't changed underneath us which can't be done using the BIO
> functions... though I wonder if we can get the FILE pointer from BIO and
> do it that way. Should be as safe on *nix as what we currently do.

Hrrm. Obviously, I need to go sleep now. Sorry about that.

But it'd be nice to get rid of all those #ifdef blocks..

//Magnus

Magnus Hagander wrote:
> Hrrm. Obviously, I need to go sleep now. Sorry about that.
>
> But it'd be nice to get rid of all those #ifdef blocks..

See the attached revision. This is untested as I don't have a linux box
to hand, but I believe it's right.

/D

Dave Page wrote:
> Magnus Hagander wrote:
>> Hrrm. Obviously, I need to go sleep now. Sorry about that.
>>
>> But it'd be nice to get rid of all those #ifdef blocks..
>
> See the attached revision. This is untested as I don't have a linux box
> to hand, but I believe it's right.

Ignore that - I managed to break it :-(. Here's a corrected version.

/D

Dave Page <dpage(at)postgresql(dot)org> writes:
> Magnus Hagander wrote:
>> Is there any reason not to just do this on *all* platforms, and get rid
>> of all the #ifdefs?

> Yes, (see the comment in the code). We stat the private key on *nix to
> ensure it hasn't changed underneath us which can't be done using the BIO
> functions... though I wonder if we can get the FILE pointer from BIO and
> do it that way. Should be as safe on *nix as what we currently do.

Perhaps you could still open the file yourself, and use BIO_new_fp()
instead of BIO_new_file()? I'm not getting responses from openssl.org
at the moment, but here's another copy of the relevant man page:

http://developer.apple.com/documentation/Darwin/Reference/Manpages/man3/BIO_s_file.3ssl.html

I concur with Magnus that it'll be better if there's not two code paths
here. It's not entirely clear whether BIO_new_fp() would avoid the
problematic calls, but it doesn't look like it'd be hard to try.

regards, tom lane