<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Regardless, this can happen with or without OpenSSL support, and any server that supports TFO is “Asking For Trouble”, IMHO.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">On the other hand, if someone really wanted to support this, they could write their own BIO.</div>
<div class=""><br class="">
<div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">--</div>
<div class="">-Todd Short</div>
<div class="">// <a href="mailto:tshort@akamai.com" class="">tshort@akamai.com</a></div>
<div class="">// "One if by land, two if by sea, three if by the Internet."</div>
</div>
</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 27, 2016, at 2:32 PM, Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org" class="">openssl-users@dukhovni.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">On Wed, Jan 27, 2016 at 07:20:04PM +0000, Salz, Rich wrote:<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Please explain. The traffic can only come from the party who initially obtains<br class="">
the cookie in a full round-trip. How does the botnet DoS some third party<br class="">
with this?<br class="">
</blockquote>
<br class="">
Attacker wants to bring down an akamai host. They connect to one of our<br class="">
servers with the fast-open option and get the cookie. They then spread<br class="">
that cookie all over the internet and zillions of bots connect.<br class="">
</blockquote>
<br class="">
The connections need to be from the attacker's original IP address that<br class="">
obtained the cookie.<br class="">
<br class="">
<blockquote type="cite" class="">Our server<br class="">
spawns zillions of threads and starts to do some work, or the TCP queue<br class="">
fills up. I can't filter on IP address to stop the attack because the<br class="">
client IP address is bogus.<br class="">
</blockquote>
<br class="">
The client IP address is not entirely "bogus", it is the IP address<br class="">
of the client that obtained the cookie, otherwise the cookie is<br class="">
not valid. Block sending cookies to sources whose cookies are<br class="">
abused.<br class="">
<br class="">
Also note that the TFO queue length is limited, and most requests<br class="">
will require a full round-trips when the request volume is high.<br class="">
<br class="">
Anyway, this is not the right forum for TFO threat analysis that<br class="">
has nothing to do with SSL. We should add client-side support<br class="">
for TFO.<br class="">
<br class="">
-- <br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>Viktor.<br class="">
_______________________________________________<br class="">
openssl-dev mailing list<br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" class="">
https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>