0

I'm trying to ensure that sensitive data (passwords, ...) are not kept in clear-text in process memory and I have found that all data sent to or received from OpenSSL is kept in memory...

This is a problem as data sent or received from an SSL connection may contain sensitive information that we don't want to keep in process memory.

Notes:

  • This is only the case when using SSLv3 or TLSv1. When using SSLv2, data is not kept in memory.
  • I am using version 0.9.8k-7ubuntu8.6 from Ubuntu Lucid. If this is related to a security fix, I think it is up to date.

Reproduction is easy:

  • Use 'openssl client -tls1 -connect hostname:443' to connect to an SSL server
  • Send data in TLS connection
  • Force generation of core file (kill -SEGV for example)
  • Inspect core file, received and sent data will be present

Is there a reason for which OpenSSL may need to keep that data? Is there an option to alter its behavior?

math
  • 2,811
  • 3
  • 24
  • 29
  • It may have to do with the operation of the different ciphers in use. You can use the `-ciphers` option to control the cipher list the client presents. In this way you can try forcing openssl to use one of the weaker ciphers available available in SSLv2 with your SSLv3/TLSv1 connections, and see if in that case you get consistent results. Probably sensitive data in process memory is not a big concern as long as it can't be paged: cold boot attacks work even without the data itself in memory; and if you can't trust root, you're screwed anyway. – rlibby Apr 21 '11 at 16:01
  • Thanks for the feedback. I have tried with the same cipher than SSLv2 and got the same result. – math Apr 22 '11 at 07:30
  • Where else would you expect data to be stored? It must buffer at least one SSL record until that record is ready to be written. In questions like these, you must know *exactly* what is acceptable to you securitywise. – President James K. Polk Apr 23 '11 at 14:07
  • My concern is not that it is temporally stored in memory but that the data can be kept a very long time in allocated buffers. I have traced the problem to the zlib buffers if compression is enabled. – math Apr 26 '11 at 10:17

3 Answers3

2

It's still in memory because you never specifically overwrote the memory contents. There isn't a good reason for it to do so automatically (everyone else would complain that it uses unnecessary cycles).

You would have to erase the memory contents yourself. That functionality is not exposed via the command-line program.

Jumbogram
  • 2,249
  • 1
  • 20
  • 24
1

The command-line 'client' tool is just for testing. It's not intended to provide actual security or to be suitable for real use. It has a number of features that make it very unsuitable for any kind of other use, for example, you cannot send a 'R' since that triggers renegotiation.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
0

Note: I'm replying to my own question after having found the explanation I was looking for.

The data is kept in zlib buffers if compression is enabled on the connection. That's why it is not observed with some configuration/server. It is surely required by zlib to correctly compress the flow.

If you don't need compression and you don't want unencrypted data to stay for a long time in process memory, you can disable OpenSSL compression.

STACK_OF(SSL_COMP)* cm = SSL_COMP_get_compression_methods();
sk_SSL_COMP_zero(cm);
math
  • 2,811
  • 3
  • 24
  • 29