>
> I am writing to this developer's list regarding the recent heartbleed bug.
>
[...]
> We have in the past developed a XMHF hypapp called TrustVisor at CMU
> where we propose to keep the OpenSSL private key inside an isolated
> execution envionment within the apache web server. This would have
> defended against this vulnerability.
Yes and no. This question isn't so easily ansered as it is asked.
> I was wondering if there would be any interest in kick-starting a
> XMHF/TrustVisor hypapp enhanced version of the apache web server software
> which would be hardened against such vulnerabilities?
Heartbleed allows for disclosure of memory, which is by far not limited
to the x509 keypair or the symmetric session key. A privilege boundary
supported by the processor (TXT, ...) that helps protecting assets
private to openssl by means of separation is therefore clearly
insufficient.
Along with that, it is not an apache problem, but a challenge for
openssl:
If there is a separation between API and { protocol, key store, ciphers
} such as if there is an entirely different process that handles the
crypto, there is a real benefit. TXT could be particularly helpful in
exactly such a domain-separated construct to protect the keys from the
rest of the crypto-context memory.
For that reason I find it useful/beneficial for the idea to approach the
openssl people with it. I'd definitely want a concept where the crypto
part is forked off, and additionally protected within the spin-off.
> Thanks!
Thanks,
R.
