[openssl-users] Using TCP Fast Open with OpenSSL

[Nounou Dadoun]

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni
Sent: Wednesday, January 20, 2016 8:55 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Using TCP Fast Open with OpenSSL


> On Jan 20, 2016, at 9:27 AM, Sara Dickinson <sara at sinodun.com> wrote:
> 
> I have TFO + TLS (using OpenSSL) working on OS X. However, because of 
> the specifics of the TFO implementation on Linux, I can’t see how to 
> get that working with OpenSSL. On Linux using TFO requires that
> - the connect() call is skipped entirely
> - the first data sent on the connection must be sent using the sendto() function passing in the MSG_FASTOPEN flag. This sendto() call takes care of both the TCP handshake, and sending the data as payload in the SYN. 
> 
> I may well be missing something, but I can’t see anyway to use this in combination with the OpenSSL API, because the SSL_connect()/SSL_do_handshake() functions rely on the underlying socket already being setup and ready to accept a 'write'. Does anyone know of a solution/workaround, or a plan to add support for client TFO to OpenSSL?

Well, I am not shy to say that the Linux Kernel API for this is poorly designed.  However, we can perhaps work around this.

This could be done via an enhancement of BIO_s_socket() to support completing the connection on the first write.
Then you just configure the modified BIO as the network BIO of the SSL handle.

The construction of the BIO could be made transparent to users of SSL_set_fd() via a suitable new control operation that's passed through to the underlying BIO.

	SSL_set_fd(ssl, sock);
	SSL_set_tfo_addr(ssl, struct sockaddr *sa, int salen);

(Or some variant of these types for Windows, ...)

But of course the feature itself would not initially be available on all platforms.

-- 
	Viktor.

----------------------------

But if the TFO data payload is in the first SYN how can it be encrypted (etc) even before the TCP handshake is complete (let alone the SSL handshake) unless the calls are unbundled and serialized somehow.

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn