The point of SSL is to provide (possibly) data integrity (detection of tampering and validation of the source of the data) and secrecy services /on the wire/. The endpoints have always been known to be points of concern as they must maintain the keys, both private and symmetric, in their memory space somewhere.
Putting these keys in shared memory arguably reduces overall security, by bypassing the OS's normal mechanisms of process memory isolation. This should certainly be an implementation concern, because if your webserver gets compromised through a buffer overflow, integer misreflection (overflow or fencepost errors on arrays for example), or any other remote code execution vulnerability, then the shared memory is readable. In practice, this doesn't matter all that much because it's very likely that the process that's compromised is running in the same context as the key manager anyway. The way OpenSSL works, unless it has an ENGINE doing its encryption work for it, the keys are in accessible memory. (Unless the ENGINE is a tamper-resistant/detectant piece of hardware, they keys are going to be in accessible memory again/as well.) Also, OpenSSL's memory space is vulnerable to a debugger. This has also always been the case. These are issues that are common to all software SSL/TLS implementations. Without adequate OS security, putting encrypted data on the wire is like putting a deadbolt with an integrated alarm on a pressboard door, and leaving the windows open. These are some of the issues that need to be taken into consideration when deciding whether to allow SSL/TLS connections to be passed back and forth, not merely allowing SSL/TLS sessions to be resumed (which implies keeping the session state for some period of time). Since UNIX domain sockets can pass file descriptors back and forth, the ability to pass SSL and SSL_CTX objects back and forth as well might be useful... but it's not important enough to me for me to code it. :) -Kyle H On 10/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Since he's talking about a process that forks, there >> shouldn't be a problem. >> He just needs to create a shared mapping in the parent. After >> the 'fork', the address will still be the same. > >However if the program forks and calls exec* then this issue could >arise. The title of the thread suggests this ;-) > >Cheers, >Mark Yeh, you are quite right Mark as when this thread started, I was considering fork()/exec() scenario. Later the discussion over several other approaches to the problem were discussed and an attempt to solve the problem by getting rid of exec() was under consideration. As far as the application that I am working on is concerned, it already has a mechanism in place to map the shared memory at exactly the same address in all the related processes. So no issue withe the address there. Of course, it will be great to have a feature in OpenSSL implementation iteslf that will enable SSL session handover / or even session sharing between multiple related processes. But I am not quite sure if this would involve any security hazards like session hijacking, that would in fact defete the purpose of SSL (which is to provide security). ~ Urjit DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
-- -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
