Re: [TLS] Sending fatal alerts over TCP

[Nico Williams <[e-mail]>]

On Tue, Dec 20, 2011 at 7:15 AM, Florian Weimer <[e-mail]> wrote:
> What is the best way to deal with this?  I plan to avoid closing the
> connection immediately after sending the alert, essentially waiting for
> the client to close the connection.  (There will be a short timeout, but
> denial-of-service issues have to be dealt with out-of-band anyway.)

Your approach seems to be a variable-sized queue with a minimum time
on the queue for each socket on that queue.

A variant on this: use a fixed-sized queue.  Create a fixed-sized
queue, shutdown() SHUT_RDWR (but don't close()) after sending the
fatal alert, add the socket to the queue; if the queue is full take
out the oldest socket and close() it.  No need for a reaper thread:
properly behaved clients will cause those sockets to close, leaving no
state beyond a file descriptor around on the server side; bad clients
will not be able to do anything more serious than a) consume a bound
number of server-side resources, b) cause legitimate clients to get
RST before being able to see fatal alerts.

The right size for the queue will depend on the latency for sending,
receiving and processing the fatal alert message relative to typical
connection lifetime.  But it will probably be easiest to size the
shutdown socket queue as a fraction of the max open connections you
can/want to handle.

A fixed-sized queue seems to have better DoS protection: you know what
is the max number of sockets in this state is that the attacker can
force you to have, and you convert a resource consumption DoS into a
case where bad clients can cause some legitimate clients will get an
RST without first seeing a fatal alert.

> Are there any better options?

I think a fixed-sized queue w/o a reaper thread is likely easier to
code and is simpler to analyze regarding DoS attacks than a variable
size queue with a reaper thread and a "reasonable" timeout per-socket
on that queue.

Nico
--