Getting a grasp on Heartbleed and IDPs

[Matthew Vernon]

On 10/04/14 19:14, Eric Goodman wrote:

> I've heard that an edge consideration is that any use of a key in an
> OpenSSL-managed operation puts that key at risk (through the
> library's shared memory) if any of the TLS endpoints are public
> facing; even keys that are never used on an external connection. Can
> anyone confirm if this is the case?

I think it's best to think about this based on processes, not libraries.
Anything in the memory of a process running a vulnerable TLS endpoint
can be leaked by heartbeat, but it can't leak memory from other
processes - the operating system keeps different processes' memory distinct.

> For example, the statement I've heard is that if I run a vulnerable
> public-facing https web server, then that web server's TLS heartbleed
> could leak information about keys that are not used by the web server
> itself, but are actually used by OpenSSL in other applications on the
> same machine. E.g., a non-public https server's (different) key, or
> perhaps even keys created or manipulated using OpenSSL on the command
> line could be leaked through heartbleed attacks against the web
> server.

So in this case, if your non-public server is served by the same apache
process as does your public server, then its key could be compromised.
But secrets accessed using openSSL on the command line are not exposed
by Heartbleed.

Regards,

Matthew