I've been wondering, has a TLS server (or client, for that matter) key ever actually been compromised? I don't think I've ever heard of one.
I'm thinking of two possible avenues for compromise, and ignoring insider attacks. One is through defects in the protocol itself or its implementation. The other would be through a compromise of the server host (e.g. a buffer overflow in Apache) that allows the attacker to copy the TLS server's private key from the file system.
It seems to me that in-the-wild attacks on the protocol or its implementation are unheard of.
OTOH, we hear about server break-ins all the time. However, one never hears about these break-ins leading to a compromise of the server's key.
Perhaps the server's private key isn't a really useful target? Although posession of the key makes it easy to spoof a secure server, actually doing that spoofing requires a secondary attack, like phishing or an active attack on the Internet, to redirect a user to the false server.
So have there ever been any actual TLS private key compromises (through any non-insider attack)?
If TLS private keys aren't attractive enough a target for them to be compromised even when the opportunity presents itself (as I'm assuming it has), then to what extent do these keys really need to be protected?
One of the issues is some prior implication that at least some of the SSL/TLS port knocking was helping identify sites that might be indicative of something to protect. Lets say somebody finds some really juicy financial targets using the technique.
So the server is penetrated and the attacker is presented with two files .... one with the private key .... and one with a million financial transactions ... which are would they be more likely to take?
I would assert that the million financial transactions file .... yield possibly couple hundred thousand accounts numbers that could then be used directly in fraudulent transactions. The SSL/TLS private key just says that you have to put in some evesdropper in on the server's SSL/TLS sessions, decrypt the traffic and decide what it means. While it may be of some academic interest ... it would seem that letting the server keep on doing all that work for you ... and just harvesting the results ..... represents a lot bigger return for effort.
Part of the issue is that the threat model for server file exploit is frequently the same for the real data "at rest" and the private key file (which is just protecting the real data while in transit) ... the actual, real data can represent a lot higher immediate fraud potential. So lets say the attacker does take
both files for the fun of it .... but likely won't get around to any SSL/TLS evesdropping attacks until exhausting all the other financial fraud possibilities (from already having a huge number of account numbers). Even if they eventually exhaust any current crop of fraudulently harvested account numbers ... they will likely try the same attack on another server ... before they possibly decide that SSL/TSL evesdropping attacks are worth the effort.
It is possible, the SSL/TSL private key file might be more attractive target in non-financial sector circles (evesdropping for the sake of evesdropping .... possibly for other than direct financial incentive).
You would probably start hearing about the client keylogger exploits including any client private key file .... if client keys started being used for any significant purposes .... aka current client keylogger exploits are able to authenticate directly just from the pin/password key capture. any change to private key operations would mean that the client keylogger attacks would also need the private key file (with the pin/password capture then being used to decrypt the private key file in order to use the private key for authentication).
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
