httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit Vasudevan <amitvasude...@gmail.com>
Subject Re: Heartbleed Bug
Date Fri, 11 Apr 2014 15:56:01 GMT
>>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
>>nsufficient.

>>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.

The apache + openssl prototype that was built had the goal of protecting
the web server's long-term private SSL signing key. It was built as a static
binary after porting the security-sensitive portions to run as two isolated
execution environments (IEE).

For porting purposes, the original intention was to identify the modules in
OpenSSL that manipulate the web server's private SSL key and register them
as
one or more IEEs. However, with the complexity of the OpenSSL codebase, it
was
decided to replace the relevant RSA calls with equivalent functions
borrowed from another embedded SSL library (I believe it was PolarSSL).

The first IEE runs when the apache webserver starts and generates the
private
key and encrypts it using sealed storage. The sealing is performed based on
the measurement of the second IEE which runs in response to incoming client
connections during SSL session establishment and is able to use the private
key to sign appropriate SSL handshake messages. You can find more details in
the TrustVisor paper.

>>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.

Since the prototype involved changes to both apache and openssl (built as
a single static binary), I reached out here first to see if/how one could
move forward in kick-starting a secure webserver development
while keeping in mind the existing ecosystem for the relevant
components (e.g., apache, openssl).

Thanks for your inputs!

On Fri, Apr 11, 2014 at 9:37 AM, Roman Drahtmueller <draht@suse.de> wrote:

> >
> > 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.
>



-- 
Amit Vasudevan, Ph.D.
Research Systems Scientist
CyLab/Carnegie Mellon University

Mime
View raw message