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 // [email protected]<mailto:[email protected]> // "One if by land, two if by sea, three if by the Internet." On Jan 27, 2016, at 2:32 PM, Viktor Dukhovni <[email protected]<mailto:[email protected]>> 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
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
