Actually, that's a good model. It would have kept the memory (and code execution domain) of the application server independent from the memory of the SSL terminator during Heartbleed. If you terminate SSL on the same box as your app server you're putting many eggs into one basket.

Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.

Yes, you could get the data going to and from the clients, which is most of the important user data. The big problem is when your SSL/http/whatever is being terminated on the app server itself, exposing things like database access, SANs, etc.

No, it wouldn't expose those things. It would only expose things that OpenSSL itself had allocated/deallocated in that single process due to the way it was saving memory allocations for later re-use...

You're right. I meant in the case of a code execution exploit in the openssl layer, those things would be exposed if they were all on the same host/network.