At 02:34 PM 8/12/2004, Marc Branchaud wrote:
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 Wheelerhttp://www.garlic.com/~lynn/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
