Any TLS server key compromises?

[Anne & Lynn Wheeler]

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 Wheeler    http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com