Dynamically loading OpenSSL on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dynamically loading OpenSSL on Windows

Stuart Douglas
Hi everyone,

I am trying to implement a generic Java SSLContext that is backed by
OpenSSL that uses dynamic loading to link to OpenSSL.

This works well on Linux, however I am running into "no
OPENSSL_Applink" issues on Windows. According to the FAQ all that
should be required is including openssl\applink.c, however this will
not work in my case as the main process is the java executable, and
not my glue library, so the uplink function is not finding it.

Is there any way I can get this working? I have had a quick look at
the uplink code and as far as I can tell I am out of luck, but I am
hoping I have missed something.

Stuart
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Dynamically loading OpenSSL on Windows

Dr. Matthias St. Pierre


On 06.07.2016 09:37, Stuart Douglas wrote:

> Hi everyone,
>
> I am trying to implement a generic Java SSLContext that is backed by
> OpenSSL that uses dynamic loading to link to OpenSSL.
>
> This works well on Linux, however I am running into "no
> OPENSSL_Applink" issues on Windows. According to the FAQ all that
> should be required is including openssl\applink.c, however this will
> not work in my case as the main process is the java executable, and
> not my glue library, so the uplink function is not finding it.
>
> Is there any way I can get this working? I have had a quick look at
> the uplink code and as far as I can tell I am out of luck, but I am
> hoping I have missed something.
>
> Stuart
>


If you take a look at the OPENSSL_Uplink() function (ms/uplink.c), you
will see that the code gets the applink function pointer via

  apphandle = GetModuleHandle(NULL);
  applink = GetProcAddress(apphandle, "OPENSSL_Applink")

i.e., OpenSSL expects the OPENSSL_Applink() function to be "DLL-exported"
from  the executable itself, see [1].

(If this sounds weird to you, don't worry, you're  not alone ;-)

In my opinion this is a design flaw which makes it almost impossible to
have a wrapper dll around the OpenSSL library, since you always have to
modify the excutable to be able to link.

The back links are necessary, but the way they are obtained is bad design.
The best solution for this would be to have an OpenSSL API call such as
OPENSSL_register_applink(), which could be used by an executable or
a shared library likewise. The only problem I see is to add the new
api and stay compatible to the old hacky way.

Maybe you should open a ticket on the rt for this.


Regards,

Matthias



[1] MSDN - GetModuleHandle
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users