IBM uses OpenSSL internally for crypto, though we have our own SSL library.
To make it consumable for IBM products we did most of the things you've
mentioned in a wrapper layer and provide essentially only the EVP layer to
IBM applications.
Anything where we've needed access to the underlying data more generally
we've added accessor functions, there's no noticeable performance impact.
Where this has been needed it's generally been for something that's
relatively slow anyway - i.e. Diffie-Hellman.
The opaque data types have generally been fine for normal use, the only
times we've been forced to cheat and peek under the covers has been when
we've been coding up some of the NIST test cases.
The only thing that's been really inconvenient to deal with in this way is
ASN.1 parsing, and again that's generally only been when writing test cases
or working around bugs - i.e. the recent PKCS#1.5 padding problem.
"
1) First and most fundamentally: Is the general idea of
attempting to only incorporate an API subset into the LSB ABI a good
or acceptable one? LSB ABIs typically do not include every last
interface of most libraries that are standardized either because the
non-included APIs are really library internals, the API is not stable
or is only useful in specialized cases. In this case the APIs I
didn’t include are as far as I can tell only useful in specialized
cases, or have higher level APIs that provide the same functionality
(EVP vs. DES).
2) Is my concern about API stability going forward using fully
typed structures unfounded?
3) Are there concerns about converting large numbers of macros
into functions? (Performance etc.)
"
1) EVP seems sufficient with a few small tweaks. OpenSSL's SSL layer may
not yet sit cleanly on that but it could.
2) Opaque data structures is the way to go in our experience. Some apps.
may claim they need more, but the same can be said of the data
structures within the kernel.
3) ASN.1 is the only obvious problem I've noticed, performance is
unlikely to be an issue.
There are a couple of other issues you may need to deal with:
Callbacks: "everyone +dog" setting the threading and memory allocation
callbacks doesn't work where you have multiple independent shared libraries
using OpenSSL within the same process. Various parts of the application end
up stealing one anothers callbacks and/or crashing because the shared
library where the callbacks point was unloaded while some other part of the
application was using OpenSSL. I'd guess you'd hit this if you started
using OpenSSL in a big way within Gnome or KDE. We just set them to a sane
default when the shared library containing our wrapper code gets loaded and
ignore further attempts to set them, this probably needs to be a build
option.
We also added namespacing to OpenSSL to avoid crashes when customer
application code linked with other versions of OpenSSL ended up in the same
process - for LSB you may not need that since the objective is to have
everyone use one common version.
Cheers
Peter
Peter Waltenberg
"Camp, TracyX E"
<[EMAIL PROTECTED]
tel.com> To
Sent by: <openssl-dev@openssl.org>
owner-openssl-dev cc
@openssl.org
Subject
OpenSSL and LSB
26/10/06 05:53 AM
Please respond to
openssl-dev
I’d like to re-start some discussion about including OpenSSL in LSB
(acronym expansion: Linux Standards Base see: http://www.freestandards.org
). There is apparently general interest in seeing OpenSSL in LSB both for
its SSL functionality as well as its utility as a general cryptographic
library. In particular applications that wish to be LSB compliant would
benefit from security bug fixes. Currently applications that use OpenSSL
and wish to be LSB compliant are forced to statically link OpenSSL and in
theory at least, may need to re-release binaries for each OpenSSL release
(or at least evaluate if a re-release is necessary), something that is
typically just not practical for most LSB applications.
The general issues with incorporating OpenSSL into LSB are ABI stability
since the magic 1.0.0 release (while closer) has not happened yet, and just
the shear size of the OpenSSL API.
I spent quiet a bit of time conducting an analysis of 0.7.x-0.9.8d OpenSSL
releases. (documented at
http://www.freestandards.org/en/OpenSSL_stability_analysis) The analysis
attempted to determine three things: What APIs are actually used by
released applications and can a sub-set of the total OpenSSL API be created
that is functionally useful and finally is that API subset ABI stable
across many releases of OpenSSL.
The answers are generally, yes it is possible to determine an API subset
that will work for most applications that make use of OpenSSL (language
bindings and the like are ignored here), and more-or-less yes that subset
is ABI stable. Further experiments attempted to determine if by treating
all or most OpenSSL structure types as opaque types (i.e. no stack
allocations or direct structure manipulations) would give ABI stability.
The quick answer there again is yes this provided almost perfect ABI
stability, but with a loss of functionality.
The loss of functionality was because a fairly large portion of the OpenSSL
API is implemented as macros that perform trivial manipulations on OpenSSL
data types. However since these are macros, it is not also possible to
force the data types they manipulate to be opaque. In almost all cases it
is fairly trivial to convert the macros into functions and remove the
dependency on fully typed data types. Which brings me to my questions for
the OpenSSL developer community:
1) First and most fundamentally: Is the general idea of
attempting to only incorporate an API subset into the LSB ABI a good
or acceptable one? LSB ABIs typically do not include every last
interface of most libraries that are standardized either because the
non-included APIs are really library internals, the API is not stable
or is only useful in specialized cases. In this case the APIs I
didn’t include are as far as I can tell only useful in specialized
cases, or have higher level APIs that provide the same functionality
(EVP vs. DES).
2) Is my concern about API stability going forward using fully
typed structures unfounded?
3) Are there concerns about converting large numbers of macros
into functions? (Performance etc.)
Thanks,
Tracy Camp
