Re: Challenge/response and nonces
- From: "David Hooker" <david.d.hooker@xxxxxxxxx>
- Date: Mon, 11 Sep 2006 07:53:42 GMT
By the way, are you sure that this is necessary? Are people
exploiting this in the wild to mount denial-of-service attacks
against SSL webservers?
Thankyou for your quick reply.
This server has to handle many simultaneous connections (with only
small amounts of data on any particular connection) and TCP connections
require kernel memory, which puts a hard limit to the number of
connections that can be supported. So, this is actually SSL operating
over a reliable transport built on top of UDP.
I'd considered hashcash (as an aside, can hashcash be used for password
stretching?), which would be a good idea if I was dealing with unknown
clients, but I'm dealing with known clients and having the client prove
its identity and that it has done some CPU work is better than just
having proven that it has done CPU work. Having the server brought to
its knees could be damaging for us, so it would be negligent of me not
to explore options for reducing that risk. Of course, is someone
builds a botnet and DDoSes us, there's probably not much that we can do.
For instance, server sends a random 64-bit nonce N;
the client responds with F(K, N), where K is the shared key and F
is a pseudorandom function (e.g., AES).
* How good does the source of random numbers for N have to be? If a
CSPRNG is required, then could malicious clients could drain the
server's entropy pool?
* Can the man-in-the-middle learn K by impersonating the server?
Also, is it safe to generate a stream of random numbers at the server,
transmit to the client within the encryption envelope, and have the
client quote them back to the server in order to prevent someone else
from injecting bad data into the connection?
No, this defense won't prevent man-in-the-middle attacks.
Could you elaborate please? Because the clients are known to us, we
plan on issuing each client a certificate that is signed by us, and to
have the clients trust our signature. As far as I can tell, once the
client has a SSL connection to the server, there's not much a
man-in-the-middle can do. Once the client has a pool of nonces, it can
quote them (in the clear) in future packets; the server would then
ignore packets that contain invalid nonces, which avoids feeding SSL
invalid data that might cause it to drop the connection (which would
require a CPU-intensive renegotiation).
Thankyou for your time,
David Hooker
.
- Follow-Ups:
- Re: Challenge/response and nonces
- From: David Wagner
- Re: Challenge/response and nonces
- References:
- Challenge/response and nonces
- From: David Hooker
- Re: Challenge/response and nonces
- From: David Wagner
- Challenge/response and nonces
- Prev by Date: Re: name for resistance to rubberhose cryptanaysis?
- Next by Date: Re: Challenge/response and nonces
- Previous by thread: Re: Challenge/response and nonces
- Next by thread: Re: Challenge/response and nonces
- Index(es):
Relevant Pages
|