[openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Short, Todd]

However, we’re talking about botnets. They do bad things, they don’t follow the rules. They can masquerade as the original sender and send additional data.

The received data held ought to be limited to the initial window of the connection, AND, since these are all original SYNs (pun intended) the server receiving the data ought to only be saving one packet worth of data (i.e. TFO queue), since the first data pack should be repeated (because it’s the initial data on the connection) on subsequent SYNs on the to-be established connection.

So, the problem isn’t other members of the botnet receiving cookies, because they can’t exceed the TFO queue, but multiple members of the botnet doing TFO on their own, and not responding to the SYN-ACK, potentially opening up thousands of embryonic sockets with thousands of bytes of data, which is what the original SYN-cookies were meant to prevent in the first place.

Regardless, this can happen with or without OpenSSL support, and any server that supports TFO is “Asking For Trouble”, IMHO.

While I personally don’t think that TFO should be supported anywhere for security reasons (it is “experimental”), there’s no reason to not support it in in OpenSSL.

On the other hand, if someone really wanted to support this, they could write their own BIO.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Jan 27, 2016, at 2:32 PM, Viktor Dukhovni <openssl-users at dukhovni.org<mailto:openssl-users at dukhovni.org>> wrote:

On Wed, Jan 27, 2016 at 07:20:04PM +0000, Salz, Rich wrote:

Please explain.  The traffic can only come from the party who initially obtains
the cookie in a full round-trip.  How does the botnet DoS some third party
with this?

Attacker wants to bring down an akamai host.  They connect to one of our
servers with the fast-open option and get the cookie.  They then spread
that cookie all over the internet and zillions of bots connect.

The connections need to be from the attacker's original IP address that
obtained the cookie.

Our server
spawns zillions of threads and starts to do some work, or the TCP queue
fills up.  I can't filter on IP address to stop the attack because the
client IP address is bogus.

The client IP address is not entirely "bogus", it is the IP address
of the client that obtained the cookie, otherwise the cookie is
not valid.  Block sending cookies to sources whose cookies are
abused.

Also note that the TFO queue length is limited, and most requests
will require a full round-trips when the request volume is high.

Anyway, this is not the right forum for TFO threat analysis that
has nothing to do with SSL.  We should add client-side support
for TFO.

--
Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160128/444dc572/attachment-0001.html>