Re: OpenSSL Security Advisory: Record of death

2010-03-26 Thread Adam Langley
On Thu, Mar 25, 2010 at 5:16 PM, Claus Assmann ca+ssl-...@esmtp.org wrote:
 So far I haven't been able to determine which change caused the
 problem, so I'm still looking at various diff's, but I'm not
 familiar with the source code to (easily) spot the problem.

I imagine the reason that the exact breakdown wasn't given was because
it would let attackers know exactly what to do.

From the advisory:

- If 'short' is a 16-bit integer, this issue applies only to OpenSSL 0.9.8m.
- Otherwise, this issue applies to OpenSSL 0.9.8f through 0.9.8m.

Almost certainly short is 16-bits for you, so it only matters if
you're running 0.9.8m. You are very unlikely to have introduced the
problem via a patch.


AGL

-- 
Adam Langley a...@imperialviolet.org http://www.imperialviolet.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL Security Advisory

2010-03-26 Thread Jean-Marc Desperrier

Bodo Moeller wrote:

it's code elsewhere that no longer tolerates the coarse logic we are
changing in the patch, which has been around forever.


In fact, I already suspected that, thanks for the confirmation.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: libcrypto safe for library use?

2010-03-26 Thread Mark Phalan

On 03/26/10 04:44 AM, David Schwartz wrote:


Mark Phalan wrote:


The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.


That is correct.


This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set the locking callbacks from within
the library itself. The calling application may or may not be using
OpenSSL or may be linking against multiple libraries some of which may
be linked against OpenSSL. The application may not even be aware that
it
will end up calling into OpenSSL code.


It's trivial -- adopt the same solution OpenSSL adopts. Have the application
set your library's locking callbacks and you pass them onto OpenSSL. It
won't matter then if you change the callbacks because you'd be changing them
to what they already were or would be anyway.



Unfortunately that's not really practical. To take an example I'm 
familiar with - libgss. libgss can end up calling into OpenSSL in the 
following way:


libgss - kerberos - pkinit plugin - openssl

It's simply not practical to change libkrb5 and libgss and all 
applications using those libraries.



The only safe way to ensure that the OpenSSL code will be MT safe would
be for the OpenSSL library itself to set locking callbacks, however I
don't see any compile-time option to do that.


It can't do that, it has no idea what threading model the application is
using. It would have no way to know whether the locks it provided were
suitable or sensible.



Well on Solaris it's most likely going to be using either POSIX threads 
or Solaris threads which are interoperable and can be used in the same 
application. If an application wants to do something unusual it can set 
the callbacks. I'm not suggesting that applications should lose the 
power to set locking callbacks.
Having default callbacks will simply mean that applications which don't 
use OpenSSL or don't set callbacks will be more likely to work.



Is there a reason I'm missing as to why this option isn't available?


The library has no way to know what threading model the application that
calls it is using. Only the application has this knowledge, so it's the
application's responsibility to pass this to the library.


Without this, the library can do its best to set the locking callbacks
when loaded if they are not set and then remove them when unloaded,
however this will always be inherently racy if there are other parts of
the process using OpenSSL.


I agree. Your library should impose a requirement on any application that
uses it that it inform you of the threading model it's using so that you can
use appropriate locking as well. Then you can set the OpenSSL locking
callbacks (just pass them through) and there's no chance of a race or
problem.


See above. That's simply not practical (the horse has left the stable).

-M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: libcrypto safe for library use?

2010-03-26 Thread Darryl Miles

Mark Phalan wrote:


The threads(3) manpage states that to use OpenSSL in multi-threaded 
applications then locking callback functions must be set otherwise 
random crashes may occur.


This poses a challenge when using OpenSSL in a library which should be 
MT safe. There is no safe way to set the locking callbacks from within 
the library itself. The calling application may or may not be using 
OpenSSL or may be linking against multiple libraries some of which may 
be linked against OpenSSL. The application may not even be aware that it 
will end up calling into OpenSSL code.


I agree this is a genuine concern.


Thing 1) It is one thing for OpenSSL to have multi-platform support by 
delegating the locking mechanism with callbacks via abstraction.  This 
allows the library to be used with all major large platforms as well as 
any tiny embedded platform (for which OpenSSL has not way in advance to 
know or understand the locking mechanism on that platform).  No one is 
saying this is not a good and correct thing to do and such a thing shall 
remain.



Thing 2) It is another thing not to provide a default implementation for 
setting up those callback with a usable locking mechanism specific for 
each platform it can be compiled for where one is known.  It is not like 
the WIN32 version is going to be used on Linux and the Linux on 
Nokia-Symbian.  This mechanism can have a common API symbol across all 
platforms which will attempt to setup the locking mechanism in a 
re-entrant multi-thread safe manner, it should also reference count the 
setup mechanism so multiple users can load OpenSSL DSO and initialize it 
independently in safety.



These two things are not mutually exclusive.  I think there is some 
common misconception that they are on the openssl-dev list.



--- THOUGHTS ON IMPLEMENTATION, SKIP IF BORED ---
On every large platform there is a default locking implementation that 
can be used, there really are not too many options any more, on every 
platform OpenSSL compiles for but does not know of such a lock mechanism 
the API would error.  Documentation would need to be produced about how 
the OpenSSL library startup/shutdown would be implemented that conforms 
to the re-entrant multi-thread safe requirements.


Maybe we should petition the binutils and ELF maintainers of open-source 
platform about providing hooks in DSO for on first load and on load 
and on unload and on last unload, maybe such things already exist ? 
 Maybe this could be implemented as a single section with a control 
word indicating a bitmask of which callbacks it is for followed by a 
function pointer.  Both items are of the platform native bit-width for 
function pointers.  The dynamic linker would then use this section if it 
exists to fire callbacks.  The use of the hook would be tagged in GCC 
using __attribute(()) around symbols.  Plenty of other criteria to add 
should it be taken forward.

--- THOUGHTS ON IMPLEMENTATION, SKIP IF BORED ---





In this modern day with dlopen/GetProcAddress that dynamically loads 
modules/DSOs/DLLs into executable which themselves can have compile time 
dependencies causing additional DSOs/DLLs to loaded with them.  The top 
level application is no longer in control of proceedings the dynamic 
linker is.


You are correct the application that needed to use OpenSSL doesn't know 
it is the first user of OpenSSL in the process address space since 
there is nothing provided within OpenSSL library API to arbitrate this 
matter.  If it could know it was the first user it could setup the 
multi-threading callbacks accordingly, but again this all needs to be 
arbitrated in a re-entrant thread-safe manner.


Not so long ago (~7 years) it was conceivable that OpenSSL developers 
could say the controlling application needs to perform the arbitration 
but this just isn't how people use dlopen/GetProcAddress these days, 
rightly or wrongly.


I think that developing the OpenSSL API in this area will not limit or 
change any existing behavior it will just ratify how to deal with these 
new situations consistently.



Is it this use case there the OpenSSL's historic (archaic) view of the 
world is wrong.  The world has evolved and OpenSSL should do so too.




The only safe way to ensure that the OpenSSL code will be MT safe would 
be for the OpenSSL library itself to set locking callbacks, however I 
don't see any compile-time option to do that.


With the above two things implemented it would them be a step away from 
a providing a compile time option.  But the same thing can be achieved 
on every platform is the API callback to set a default locking 
implementation was consistent (since part of what I'm claiming here is 
that new API call would be re-entrant multi-thread safe, i.e. bullet 
proof and not requiring multiple threads to co-operate outside of OpenSSL).




Is there a reason I'm missing as to why this option isn't available?


It just is so (at this time).


Without this, the 

[openssl.org #2206] [PATCH] Implicitly support non-delegated OCSP response signing

2010-03-26 Thread Rob Stradling via RT
The attached patches (generated against OpenSSL 0.9.8n and OpenSSL-1.0.0-
beta5) cause openssl ocsp to implicitly trust the Issuing CA Certificate (as 
denoted by the -issuer parameter) as a candidate OCSP Response signer.  This 
non-delegated model is allowed by RFC 2560.

With this patch, it's possible to do an OCSP check like this:
$ ~/local/openssl-0.9.8n-modified/bin/openssl ocsp -issuer ComodoEVSGCCA.crt -
cert secure.comodo.com.crt -no_nonce -url http://ocsp.comodoca.com
Response verify OK
secure.comodo.com.crt: good
This Update: Mar 25 19:03:00 2010 GMT
Next Update: Mar 29 19:03:00 2010 GMT

But without this patch, you have to also specify -VAfile ComodoEVSGCCA.crt 
to achieve the same result.

Here are an example End-entity Certificate and Issuing CA Certificate whose 
OCSP Responder uses the non-delegated model.

secure.comodo.com.crt:
-BEGIN CERTIFICATE-
MIIGUjCCBTqgAwIBAgIRAJQkYZmHGtbUyY0tko7rIB4wDQYJKoZIhvcNAQEFBQAw
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEENPTU9ETyBFViBTR0MgQ0EwHhcNMDkwMTA4MDAwMDAwWhcNMTEwNDA3MjM1
OTU5WjCCAX8xETAPBgNVBAUTCDA0MDU4NjkwMRMwEQYLKwYBBAGCNzwCAQMTAkdC
MSMwIQYLKwYBBAGCNzwCAQITEkdyZWF0ZXIgTWFuY2hlc3RlcjEbMBkGCysGAQQB
gjc8AgEBEwpNYW5jaGVzdGVyMRswGQYDVQQPExJWMS4wLCBDbGF1c2UgNS4oYikx
CzAJBgNVBAYTAkdCMQ8wDQYDVQQREwZNNSAzRVExGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEWMBQGA1UECRMNVHJhZmZvcmQg
Um9hZDEWMBQGA1UECRMNRXhjaGFuZ2UgUXVheTElMCMGA1UECRMcM3JkIEZsb29y
LCAyNiBPZmZpY2UgVmlsbGFnZTEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
GjAYBgNVBAsTEUNvbW9kbyBFViBTR0MgU1NMMRowGAYDVQQDExFzZWN1cmUuY29t
b2RvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWgPqeYQTL9
IdKWF/FxZ/y32XyGgU3gi2n6cd4ewDlSPkadoaYCeR8nTQBsssuFHaYA2T15+Iky
TZ/O63fFB5ZjWCaN6Ryjsk5PWDTYiYRieswQOREEvWr9N3Rpn9/l7vOd9L3Kngbz
QGTDzPxjba1Kz+5jx436y3s/0830c8bd002qPbSwvnrqdfSA2x6pHfY6mKvJI7Bj
p1FfYHk3Tt6P03j5l4rLu51dxf0u5J66sxQBJBjTWrc3YJzuRZ5BYs6GzKeUv0lz
X1RzkAUA0gq2PFUarCEVSd392rD9gXfVS+VEnssqpyjlScsbPD9EIopW+sXylHb4
CJx+kh/wFskCAwEAAaOCAdEwggHNMB8GA1UdIwQYMBaAFH/2TDYoFK7NHjev3lry
W8OgrCv+MB0GA1UdDgQWBBR3BpKJiE8F31jgH6F+yyU9mwXksDAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADA0BgNVHSUELTArBggrBgEFBQcDAQYIKwYBBQUH
AwIGCisGAQQBgjcKAwMGCWCGSAGG+EIEATARBglghkgBhvhCAQEEBAMCBsAwRgYD
VR0gBD8wPTA7BgwrBgEEAbIxAQIBBQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z
ZWN1cmUuY29tb2RvLm5ldC9DUFMwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny
bC5jb21vZG9jYS5jb20vQ29tb2RvRVZTR0NDQS5jcmwwawYIKwYBBQUHAQEEXzBd
MDUGCCsGAQUFBzAChilodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9Db21vZG9FVlNH
Q0NBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMDMG
A1UdEQQsMCqCEXNlY3VyZS5jb21vZG8uY29tghV3d3cuc2VjdXJlLmNvbW9kby5j
b20wDQYJKoZIhvcNAQEFBQADggEBAH/IFXTOFOEuxm38/yN1ssElb4hRS349eK8o
72Sn1HDdmvDnZaEDjZsHAH7Dtm6N6Wd67rkt2fLczTi+BJWX2qttw4ttwsnRJoIV
Rucu+QrqgX4Duce+smo3qXbTTWgrUNgHVmuOpyWtafIcKJ/CqPz3rkp+u8NSlXKj
/dvm/3P8i4RcRsE63+pR/o0sFrGzQaC6UdQtCUFcQXFQzrkWUAsxwnN3V7wXq+YH
h2OEDNsojuogH6zBkcknmd5cpoFu4BANx4lbbWDUr+rqJmXvZWa4jlsiI+k8wRhz
m83TXZpbVZI7VpZT7hnQyEeNxeu7jv9ygME84X6UPJp3004m2nw=
-END CERTIFICATE-

ComodoEVSGCCA.crt:
-BEGIN CERTIFICATE-
MIIEljCCA36gAwIBAgIQE2Lo61QaEIy4qA7ln7HUUTANBgkqhkiG9w0BAQUFADCB
gTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxJzAlBgNV
BAMTHkNPTU9ETyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjEyMDEwMDAw
MDBaFw0xOTEyMzEyMzU5NTlaMHMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh
dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMRkwFwYDVQQDExBDT01PRE8gRVYgU0dDIENBMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6M6qqSWvLo7ReZVepIgkT/2zXK4qnkp7
QODMUOmBWBXSh/ethXppUqCVbo9nCY7x81wX40lCyBJnpgX4N6APFmEPjzFSxuGH
4U+528n+aRvUyfctrEjXc0oEleOhN4dSWoiz1gEs8QNwLCZwK0c7Cq4xetflFE6s
LzDhfG022qD1g2JdiCYNBUVezveL65W04OsQetS5WXVGUt2GdITLX9McQerwmtqR
ZITf3p/y3dD6pmiWtz6XLX+x+4xsp/5ygtDjitO7484Bt51n6akTmjsh7fdzE+Mz
XXoBqcpJ0E5jh1eBOhdUMPYCXpS2YNIp+U7nKaCgnSpb6z+JLkWi/QIDAQABo4IB
FTCCAREwHwYDVR0jBBgwFoAUC1jli8ZMFTekQKkwqSG+RzZaVv8wHQYDVR0OBBYE
FH/2TDYoFK7NHjev3lryW8OgrCv+MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E
CDAGAQH/AgEAMCAGA1UdJQQZMBcGCisGAQQBgjcKAwMGCWCGSAGG+EIEATA+BgNV
HSAENzA1MDMGBFUdIAAwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t
b2RvLm5ldC9DUFMwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDovL2NybC5jb21vZG9j
YS5jb20vQ09NT0RPQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwDQYJKoZIhvcN
AQEFBQADggEBAIzZ2VIz7gf24eyrFeCfFdiZJdsZlSWbQ75ZK4EpyPjxX45JAjZG
HOvyof7RCkW60NtQRAxQozxuX4TUTxqoaY8kZgHSC7QIGbq9NAmQCWJxrTmOuHh5
sSR4tM2nSflteH9wh4KRNayxAIYhUdLNRss6gsBIGtMVJtvxD4JxZuKLd1Sjdi/X
bfgNDs46TmVXPxx3UMq7elP3+189dVaq0+MfErUdv8Pc4fk5Z4HxM5zIHsXm7iu5
2VjIxy7fSNHJ5LMaCF+aGG1h07CtJ14INTQloZ9CyHWY0wJkVZTjr9HnSrnk2QZu
cSj43azlRd/Y5ygFoWjOwSVbhfpGnf7bZPA=
-END CERTIFICATE-

On Wednesday 24 March 2010 12:38:07 you wrote:
 On Wednesday 24 March 2010 12:01:51 you wrote:
 snip
 
Well it would typically require giving a public responder access to a
CA key: increasing 

Re: libcrypto safe for library use?

2010-03-26 Thread Mark Phalan

On 03/25/10 02:13 PM, Mark Phalan wrote:


The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.

This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set the locking callbacks from within
the library itself.


I should also point out that libraries are setting the callbacks 
already. libldap_r (openldap) for example. I haven't done an extensive 
survey of common opensource libraries but I'm sure openldap isn't alone 
out there.


-M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


RE: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.

2010-03-26 Thread David Woodhouse
On Thu, 2010-03-25 at 17:57 +0100, PMHager wrote:
 
 As all major compilers for Intel CPUs support intrinsics and, if used 
 correctly, optimize to the same instructions as direct assembler, IMHO 
 these policies should be reconsidered to keep OpenSSL competitive.
 
 For good reasons perlasm is not an option for a company like Intel. To get 
 a solution, I now use a self-patched version of OpenSSL with intrinsics 
 which fulfills my and my customer's requirements. 

I'm not sure I understand you. You seem to be talking about the merits
of using inline assembler ('__asm__()' statements inside C code) vs.
external assembler-only files which are processed by perl and then
assembled (and which by necessity contain whole functions which are
called from the C code).

I have no interest in that debate. I'm quite happy using the perlasm
approach. It's a PITA sometimes, but I see the portability advantages of
it, and OpenSSL is a highly portable project.

My question was about the inconsistency between, for example,
SSE-optimised and AESNI-optimised functions. Both are implemented as
perlasm; that's not relevant. What _is_ relevant, however, is that the
SSE optimisations end up in the 'core' AES_encrypt() function which is
tested by 'openssl speed aes', while the AESNI version is in an engine
and isn't even used by default unless the application explicitly asks
for it.

My patch (unapplied for 6 months now) would at least fix the problem of
the AESNI engine not being used automatically, but I still don't quite
understand why it should be an engine while SSE support is not. I'd like
to understand the logic.

Should we be moving the SSE optimisations out into their own engine too?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.

2010-03-26 Thread Andy Polyakov
 My question was about the inconsistency between, for example,
 SSE-optimised and AESNI-optimised functions. Both are implemented as
 perlasm; that's not relevant. What _is_ relevant, however, is that the
 SSE optimisations end up in the 'core' AES_encrypt() function which is
 tested by 'openssl speed aes', while the AESNI version is in an engine
 and isn't even used by default unless the application explicitly asks
 for it.
 
 My patch (unapplied for 6 months now) would at least fix the problem of
 the AESNI engine not being used automatically,

The reason for low priority is that the code is in development, lack of
hardware...

 but I still don't quite
 understand why it should be an engine while SSE support is not. I'd like
 to understand the logic.

The original reason for suggesting the engine was alignment requirement
for key schedule imposed by submitter [from Intel]. The requirement
couldn't (and can't) be tolerated in common code. Another reason for
favoring engine is option to implement algorithms that otherwise
wouldn't make sense to implement. Simplest example in this particular
case is ECB. It's no point implementing dedicated ECB subroutine in
general code (won't be any faster), while dedicated ECB subroutine for
specifically AESNI delivers 3x performance improvement (over
non-dedicated procedure using single block AESNI subroutine). Another
such example is [Galois] counter mode (which is under development).

 Should we be moving the SSE optimisations out into their own engine too?

It's an option... If there was an inter-procedural or super-procedural
(something similar to above mentioned ECB) optimization specific for SSE
it would definitely be the case. But as of now, SSE code is limited to
lowest-level leaf functions and lifting it into an engine is problematic
to motivate. Not to mention that it would result in code duplication
(meaning more maintenance as if it wasn't enough). A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.

2010-03-26 Thread Andy Polyakov
PM,

 Though I am not a member of the OpenSSL team, I totally agree with you. 
 As for the AES, the Westmere CPUs have also a new instruction for the 
 GHASH (pclmulqdq / _mm_clmulepi64_si128).

It's not an instruction *for* GHASH, it's an instruction that among
other thing can be used for GHASH.

 This as well is only available 
 as intrinsic or in native assembler.
 
 So, when I offered some weeks ago a contribution regarding the GHASH for 
 the GCM, (now with a fallback from pclmulqdq to SSE2 to native C), I was 
 instructed that (at least inline) assembler or intrinsics are not an 
 option for OpenSSL. 
 
 Inline assembler (or exotic intrinsics) is not considered
 as viable option for MMX/SSE (or any code bigger than couple of
 instructions), perlasm code is.

Do you think it's groundless and totally unreasonable? Well, it's more
of a rhetorical question...

 As all major compilers for Intel CPUs support intrinsics and,

Well, I have neither of them. Of course it's not *completely* true, but
 OpenSSL does not assume that availability of such compilers is
universal. And I know it's appreciated.

 if used 
 correctly, optimize to the same instructions as direct assembler,

It's just that we have seen one too many compiler bugs, have observed
how performance varies among compiler versions, how compilers do poor
job allocating registers (and just poor job)...

 IMHO 
 these policies should be reconsidered to keep OpenSSL competitive.

??? Are OpenSSL assembler modules slower than compiler generated code?
Is perlasm less portable than intrinsics?

 For good reasons perlasm is not an option for a company like Intel.

??? OpenSSL is not Intel...

 To get 
 a solution, I now use a self-patched version of OpenSSL with intrinsics 
 which fulfills my and my customer's requirements.

Then fight for it (but not in this thread!). Your SSE2 code was
effectively dismissed, because it was slower. At least it was my
conclusion and as you didn't refute it, I assume it was correct. Well, I
still wouldn't actually accept intrinsic-based code, but ideas could
have been used in assembler. Cheers. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


RE: libcrypto safe for library use?

2010-03-26 Thread David Schwartz

Mark Phalan wrote:

 Unfortunately that's not really practical. To take an example I'm
 familiar with - libgss. libgss can end up calling into OpenSSL in the
 following way:
 
 libgss - kerberos - pkinit plugin - openssl
 
 It's simply not practical to change libkrb5 and libgss and all
 applications using those libraries.

In this case, I presume 'pkinit' only supports one threading model (or one
set of compatible threading models). So it can set the callbacks. Any
application that uses 'pkinit' must be okay with those callbacks.
 
  It can't do that, it has no idea what threading model the application
  is
  using. It would have no way to know whether the locks it provided
  were
  suitable or sensible.


 Well on Solaris it's most likely going to be using either POSIX threads
 or Solaris threads which are interoperable and can be used in the same
 application. If an application wants to do something unusual it can set
 the callbacks. I'm not suggesting that applications should lose the
 power to set locking callbacks.
 Having default callbacks will simply mean that applications which don't
 use OpenSSL or don't set callbacks will be more likely to work.

Then set default callbacks in your code that calls OpenSSL. OpenSSL can't do
it, because it has no idea what threading models your code uses.

  I agree. Your library should impose a requirement on any application
  that
  uses it that it inform you of the threading model it's using so that
  you can
  use appropriate locking as well. Then you can set the OpenSSL locking
  callbacks (just pass them through) and there's no chance of a race or
  problem.
 
 See above. That's simply not practical (the horse has left the stable).

If the horse has left the stable and the code supports more than one
threading model, then the problem is provable insolvable. There is simply no
way for OpenSSL to know what kind of locks are adequate. If your code
supports only one threading model, then you can tell OpenSSL this by setting
the callbacks.

Multi-threading issues, as a general rule, have to be resolved at
application level. It cannot be done by libraries because they don't have
sufficient knowledge. Things like signal handlers are process-level
resources. The same is true of what kind of mutexes are needed to protect
structures from concurrent accesses that come into a library from outside
it.

 I should also point out that libraries are setting the callbacks already.
 libldap_r (openldap) for example. I haven't done an extensive survey of
 common opensource libraries but I'm sure openldap isn't alone out there.

Since libldap_r knows what threading model the application is using, it can
do this. OpenSSL doesn't know, so it can't do this.

DS



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org