This is a new attack, not the one Schneier was talking about. It's very elegant work -- they actually implemented an attack that can recover the long-term private key. The only caveat is that their attack currently works on LANs, not WANs, because they need more precise timing than is generally feasible over the Internet.
Hmmm... This means that it is safer for senior managers in a company to communicate using private ADSL Internet connections to their desktops rather than using a corporate LAN. Very interesting. Could IP Centrex be the wave of the future? Will ISPs offer random jitter insertion guarantees on such a service to foil people using timing attacks? --Michael Dillon
Michael.Dillon@radianz.com writes:
This is a new attack, not the one Schneier was talking about. It's very elegant work -- they actually implemented an attack that can recover the long-term private key. The only caveat is that their attack currently works on LANs, not WANs, because they need more precise timing than is generally feasible over the Internet.
Hmmm... This means that it is safer for senior managers in a company to communicate using private ADSL Internet connections to their desktops rather than using a corporate LAN. Afraid not. The timing attack is an attack on the SSL server. So as long as the SSL server is accessible at all, the attack can be mounted. And once the private key is recovered, then you no longer need LAN access.
-Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
This means that it is safer for senior managers in a company to communicate using private ADSL Internet connections to their desktops rather than using a corporate LAN.
Afraid not. The timing attack is an attack on the SSL server. So as long as the SSL server is accessible at all, the attack can be mounted. And once the private key is recovered, then you no longer need LAN access.
While the timing attack is the attack against the SSL server, it is my reading of the paper that the attacks' success largely depends on ability to tightly control the time it takes to communicate with a service using SSL. Currently, such control is rather difficult to achive on links other than ethernet. Alex
While the timing attack is the attack against the SSL server, it is my reading of the paper that the attacks' success largely depends on ability to tightly control the time it takes to communicate with a service using SSL. Currently, such control is rather difficult to achive on links other than ethernet.
Doesn´t MPLS provide consistent delay and minimal jitter and thus SSL servers connected to MPLS networks are more suspectible to attack? :-) Pete
While the timing attack is the attack against the SSL server, it is my reading of the paper that the attacks' success largely depends on ability to tightly control the time it takes to communicate with a service using SSL. Currently, such control is rather difficult to achive on links other than ethernet.
Doesn�t MPLS provide consistent delay and minimal jitter and thus SSL servers connected to MPLS networks are more suspectible to attack?
Have you seen MPLS cards for servers being widely deployed? :) The smaller the number of router(s) sitting between attacker and the target, the closer attacker can control the timing. Alex
alex@yuriev.com writes:
This means that it is safer for senior managers in a company to communicate using private ADSL Internet connections to their desktops rather than using a corporate LAN.
Afraid not. The timing attack is an attack on the SSL server. So as long as the SSL server is accessible at all, the attack can be mounted. And once the private key is recovered, then you no longer need LAN access.
While the timing attack is the attack against the SSL server, it is my reading of the paper that the attacks' success largely depends on ability to tightly control the time it takes to communicate with a service using SSL. Currently, such control is rather difficult to achive on links other than ethernet. Quite so. What I meant here was that as long as Ethernet access is provided to the server at all, having your own traffic sent over a non-Ethernet link doesn't protect you.
-Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
participants (4)
-
alex＠yuriev.com -
Eric Rescorla -
Michael.Dillon＠radianz.com -
Petri Helenius