[nly]

This really isn't really the end of the story. As far as your web app goes, HTTP cookies can be just as or more sensitive than your SSL keys, and they also slop around in your web servers memory. This is one reason why we run SSL/TLS in the first place, after all. In many cases we really use TLS as a way to ensure application layer authentication. Confidentiality, in and of itself, is often not the primary concern. Do you care more about people accessing your Amazon account, and buying things in your name, or people seeing what you're buying? With your Amazon cookies, I can do the former.

So are we all going to jump back to pre-forked, multi-process Apache now, tack on a TLS slave daemon, and ignore gaping big holes in the application layer?

[phamilton]

They are orthogonal issues. The point of separating private keys is to contain exposure. Heartbleed still would have happened, and all data could be exposed. But right now we not only have to deal with data leakage, but after we patch and fix the bug we have exposure due to the private keys potentially being leaked. We then have to get new certs signed and experience all sorts of additional certs. If the private keyvwas not leaked, then while we still have to deals with the security breach, we can at least avoid having to revoke and reissue all certs.

[nly]

As long as forward secrecy is/was used then the impact on the individual user is more or less the same. Remember we're largely talking about active MITM.

In the short term your user is compromised whether it's a cookie, an AES key for the TLS session (which will presumably still have to be resident in the process sending you data), a credit card number in a POST request, or your certificate master key.

Anyone who can intercept my traffic in close to real time, and wishes to target me, is going to know I'm talking to amazon.com, IP x.y.z.f, and that that's where they should target their Heartbleed attack for a good stab at accessing my PHP session cookie or TLS session AES key.

There are some cases, like e-mail phishing, where this isn't the case of course... but then a redirection service would be sufficient to let me script an attack against many sites.

[phamilton]

Agreed that the effect on the user is the same, for the most.

It does make my life easier in the event of a vulnerability, with little cost to users. Since I can more efficiently respond, the user arguably gets a better experience.

I agree this doesn't solve everything, but it is a strict improvent over our current system.

[remosi]

You're right, this doesn't solve 100% of the problem. If I could solve 100% I'd be creating a startup...

Cookies are remarkably sensitive, but they can be far more easily rotated. I can make sure that every cookie is rotated transparently every day or so and leave that running as a sensible background precaution. If we had infrastructure that let us renew our TLS keys every 24 hours or so, this wouldn't be such a big deal (it would still be a big deal, but not quite as bad as it is today). But TLS keys have an expiry of usually years.

[nly]

> If we had infrastructure that let us renew our TLS keys every 24 hours or so

The sad thing is... we do. 24 hours is a bit much, but why not have a different certificate for each server? The whole point of a certificate chain is to give us the flexibility to issue and revoke certificates from lower down in the tree... of course most of us serfs don't get the privilege of using our own intermediates.

Oh... and we're repeating some of the same mistakes in DNSSEC. Looking at deploying DNSSEC I kept reading that the general idea of the KSK was to function as a long-term key, and the ZSK as a short term key, but I have yet to see a method of managing things with the KSK offline that isn't like pulling teeth. The latest BIND requires that both the KSK and ZSK private keys be resident on your primary nameserver when you switch on the "auto-dnssec" magic.

Still, at least setting up DNSSEC is free.

[remosi]

The technique of not having the keys available to the process that's dealing in external bits works really well for DNSSEC. There's a program called opendnssec which takes care of keys, rotating them, and .... accesses them via PKCS#11. So you can use Hardware Security Module, or a softhsm. Since it's opendnssec that's doing the rotation of keys, that can run as a different user than your DNS server, so the fact that softhsm runs as a shared library is less of an issue.

opendnssec unfortunately is a little... industrial strength. It takes some time and consideration to configure unlike bind's "gimme the keys and I'll just take care of it for you" approach.