[Vortex] [ISSUE] API mismatch using custom SSL contexts

Jens Alfke jens at mooseyard.com
Tue Apr 22 16:51:57 CEST 2008

On 22 Apr '08, at 1:14 AM, Benoit Amiaux wrote:

> The issue is that the proposed API only allow us to create the context
> but not how to destroy it. This is cumbersome because, as usual, when
> vortex is used as a DLL, it forces us to use the exact same version of
> openssl under which the dll has been linked or you wil suffer instant
> heap corruption when any SLL context is deallocated.

I don't understand the issue here … assuming OpenSSL is a dynamic  
library, both Vortex and the host app will be calling into the same  
version/instantiation of it, so there shouldn't be a problem with  
version conflicts. (Or do DLLs behave very differently in Windows than  
what I'm used to from Mac/Unix?)

In any case, I've found it's necessary for my app to make OpenSSL  
calls to do things like authenticate certs, so I don't think it would  
be feasible to completely abstract out the entire OpenSSL API inside  

> - add an abstraction layer above SSL functions, which allows us to use
> any SSL implementation. This abstraction have to be complete,  
> including
> allocation, processing and deallocation functions. A default file- 
> based
> SSL implementation could be added.

I would like this actually, as using OpenSSL is a bit of a pain for my  
app. Certificates are stored in the Mac OS "Keychain" (secure  
storage), which transparently integrates with the SSL implementation  
in CDSA; but to get a private key securely from the Keychain into  
OpenSSL requires some gymnastics, such as first exporting it from the  
Keychain in wrapped form with a temporary session key, then importing  
that into OpenSSL. This is less secure than leaving the private key  
inside the Keychain/CDSA's storage area.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1875 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080422/47d9796a/attachment.bin 

More information about the Vortex mailing list