Really? The private key in asymmetric cryptography should never/is assumed to never be known to anyone other than the key-holder. Session keys are understood to be shared, and so are by definition not secure (equivalently, I can log my part of the "conversation" with a server, even if over TLS with PFS). So session keys, session cookies, transmitted data -- is always known by more than one party, a secret key should never be known by more than one party.
It is true that most TLS server deployments don't enforce this -- they don't do the asymmetric operations in a trusted computing module, smart card etc -- but they should. They shouldn't store the key in ram, but they currently do.
If you get the secret key, you can do many more things than merely intercept traffic. You can impersonate and fake traffic (fake evidence).
In addition to all this, being able to read arbitrary memory controlled by the same process is also worse than being able to read stuff that is already being transmitted. This isn't strictly a Rust/other language issue (I imagine, but do not know, that one eg could sanely (if foolishly) share buffers across thread pools, and so potentially leak information across clients -- this would probably be a design error wrt. trust boundaries etc ... but no-one is arguing that any language can prevent design errors).
As mentioned in other comments, privilege separation (a la openssh etc) is a great way to help leverage the os/kernel in order to enforce assumptions about the security primitives used. But that's a little beside the point.
In a general sense, yes. It would suck to lose your private PGP key and have someone send fake messages. Probably more so than losing any one (or few) encrypted messages.
HTTPS is a little different. You need to verify you're talking to the real paypal.com, but that's so you know you're not sending your password to a stranger. paypal doesn't send signed emails, for instance. (maybe they should, but not with the website key, for sure). Stealing passwords and cookies is pretty much the end game for https private key theft.
Is anyone willing to say that a bug which only leaks passwords and cookies is a minor issue?
wrt heartbleed, there seems to be a gap between the "could happen" and "did happen" consequences. Besides the one test server pummeled with millions of requests, were any private keys actually compromised? On the other hand, we know yahoo passwords were compromised because people were doing it within hours of the heartbleed announcement. I'm more concerned with the latter.
Yes, if I'm writing a sort function for vulnerabilities, "read arbitrary memory" is worse than "read some memory", but there should be some accounting for degree of difficulty as well.
Really? The private key in asymmetric cryptography should never/is assumed to never be known to anyone other than the key-holder. Session keys are understood to be shared, and so are by definition not secure (equivalently, I can log my part of the "conversation" with a server, even if over TLS with PFS). So session keys, session cookies, transmitted data -- is always known by more than one party, a secret key should never be known by more than one party.
It is true that most TLS server deployments don't enforce this -- they don't do the asymmetric operations in a trusted computing module, smart card etc -- but they should. They shouldn't store the key in ram, but they currently do.
If you get the secret key, you can do many more things than merely intercept traffic. You can impersonate and fake traffic (fake evidence).
In addition to all this, being able to read arbitrary memory controlled by the same process is also worse than being able to read stuff that is already being transmitted. This isn't strictly a Rust/other language issue (I imagine, but do not know, that one eg could sanely (if foolishly) share buffers across thread pools, and so potentially leak information across clients -- this would probably be a design error wrt. trust boundaries etc ... but no-one is arguing that any language can prevent design errors).
As mentioned in other comments, privilege separation (a la openssh etc) is a great way to help leverage the os/kernel in order to enforce assumptions about the security primitives used. But that's a little beside the point.