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
> 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