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

Viktor Dukhovni openssl-users at dukhovni.org
Wed Jan 27 19:04:00 UTC 2016


On Wed, Jan 27, 2016 at 02:19:32PM +0000, Salz, Rich via RT wrote:
> 
> > This suggests that you have on-path capabilities between each of the
> > reflectors and the victim, right?
> 
> I don't think so:  you need the first attacker to get the cookie, then you spread it out.

   Cheng, et al.                 Experimental                      [Page 8]
   RFC 7413                      TCP Fast Open                December 2014

   The server is in charge of cookie generation and authentication.  The
   cookie SHOULD be a MAC tag with the following properties.  We use
   "SHOULD" because, in some cases, the cookie may be trivially
   generated as discussed in Section 7.3.

   1. The cookie authenticates the client's (source) IP address of the
      SYN packet.  The IP address may be an IPv4 or IPv6 address.

   2. The cookie can only be generated by the server and cannot be
      fabricated by any other parties, including the client.

   3. The generation and verification are fast relative to the rest of
      SYN and SYN-ACK processing.

   4. A server may encode other information in the cookie and accept
      more than one valid cookie per client at any given time.  But this
      is server-implementation dependent and transparent to the client.

   5. The cookie expires after a certain amount of time.  The reason for
      cookie expiration is detailed in the "Security Considerations"
      section (Section 5).  This can be done by either periodically
      changing the server key used to generate cookies or including a
      timestamp when generating the cookie.

      To gradually invalidate cookies over time, the server can
      implement key rotation to generate and verify cookies using
      multiple keys.  This approach is useful for large-scale servers to
      retain Fast Open rolling key updates.  We do not specify a
      particular mechanism because the implementation is server
      specific.

What attack do you have in mind via spreading a cookie good for
just one source IP address?  Sure the botnet can source TFO
from that same IP address that got the original cookie.  Why is
that useful?

-- 
	Viktor.


More information about the openssl-dev mailing list