I hope we see more key isolation going on in the near future even where titus is overkill. Process-per-connection tends to cross the cost-benefit threshold for high-traffic/low-to-medium importance stuff, but key compromise is a giant pain in the ass no matter what you're doing.
On the other hand, if you want to go further into tinfoil-hat territory, find a way to isolate each process in a separate container. :) (Bonus points: Tear down/rebuild the container for each new connection.)
There's definitely overhead to the process-per-connection approach, but I disagree that protecting the key is more important then protecting the state of the connection. A private key is just a means to the end of securing a connection, and what terrified me most during Heartbleed wasn't the private key compromises, but the fact that it exposed private user data like passwords:
(there was probably other sensitive content like emails in that dump too)
This kind of information is far more useful to attackers, since it can be used immediately and independently, whereas a compromised private key is only useful in conjunction with an active MitM attack (if forward secrecy is used) or a passive eavesdropping attack (if forward secrecy is not used).
As for containers, titus is already using a lot of container-like techniques, such as filesystem and network isolation, and I plan to use PID namespaces in a future version. So it's probably already deep in tinfoil-hat territory ;-)
I'd be willing to take the hit for the login process itself, but for most of the other stuff I care about, the biggest concern is MitM -- users need to trust that the (mostly non-personal, non-confidential) data they're receiving actually comes from me.
Good point about serving non-personal, non-confidential data - in this case, there's no benefit to the process-per-connection model, but there is still a benefit to isolating the private key. Unsure how you could easily separate out the login process from other pages on the site. I think you'd need to use separate hostnames/IP addresses and an SSO-like system.
Sure, but that's already a requirement for a lot of applications, and a lot more can be handled just by setting '.example.com' cookies if they don't have any untrusted subdomains.
Late edit: Ultimately this all comes down to a more general desire for better tools for segregating data and APIs into appropriate security domains. It's still way too much work, especially for small teams, to separate things into appropriate security domains with appropriate tradeoffs.
On the other hand, if you want to go further into tinfoil-hat territory, find a way to isolate each process in a separate container. :) (Bonus points: Tear down/rebuild the container for each new connection.)