[
Lists Home |
Date Index |
Thread Index
]
At 10:28 PM -0500 1/7/04, Rich Salz wrote:
>> I'm understanding this attack correctly, using state would only
>> remove the need to verify after the initial, verified transaction.
>> Can the attacker not send just as many initial, malformed requests?
>> How does maintaining state present this attack?
>
>It narrows down where you have to do DoS
But it still allows it. Using session keys instead of state narrows
the hole through which the DOS attack can pass. However, it doesn't
close it, and since the hole is in a predictable place, the attacker
can still walk right through it. If there is a real problem with DOS
attacks based on malformed encrypted messages, using session keys
doesn't fix it. :-(
>> I see you're thinking here more about the DOS than key theft. For key
>> theft, the good guys and the bad guys do not benefit equally from
>> increased efficiencies.
>
>Not at all. If I get a more powerful processor, I can use a bigger
>nonce in my digest-auth. If the adversary gets a more powerful
>processor, he can do more dictionary, password-guessing, attacks.
No, the situation is not symmetric. Doubling the nonce (or the key
length) would double the work the encrypter (good guy) has to do. It
would more than double the work the attacker has to do to decrypt the
message without knowing the key.
>But it's not really DoS, but DDoS, a zillion zombie machines.
>That's because the workload is equally divided between client and
>server -- sending the bad packets is as costly as receiving them
>in a SYN flood, e.g. In a crypto DOS attack, it's one machine, one
>bad message, and I've doubled the load on your server. The asymmetry
>of creating bogus crypto versus detecting it is inherent.
It's much easier to defend against a non-distributed DOS than a
distributed DOS. And systems do defend themselves against even DDOS
attacks today using routers. Defending against a crypto-based DOS
would not be harder. And one machine, one packet will not double the
load on my server (unless it's a very lightly used server that only
gets one packet in normal usage.) It will double the load per
request, a very different thing. Many servers have cycles to spare.
This would need to be a DDOS to have a real impact. A problem? Yes. A
crippling, insurmountable problem much worse than the status quo? No.
>> Anything like this should be done with SSL.
>
>SSL isn't appropriate. SSL provides data privacy *while the data
>is in transit.* It does not provide any offline validation,
>authentication, or privacy. There is a real important reason why
>the IETF renamed it TLS. It's transport security, not application
>data security. SSL is hop-by-hop, not end-to-end.
Yes, the remote site can still be hacked and your credit card numbers
and other sensitive data be stolen. This is a much bigger problem in
practice than packet sniffing to steal individual passwords or
session keys. The ends are insecure. However, cookies don't solve
this problem either. My point is that while it may not be
theoretically ideal to send the encrypted password over SSL (TLS) in
every connection instead of just the first, it's not a practical
problem either. SSL effectively prevents both dictionary attacks on
digest authenticated keys and replay attacks on session keys. Without
SSL, there's no protection for cookies from replay attacks and some
protection for digest authenticated passwords.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
