On 24/02/2021 22:30, David Sommerseth wrote:
TFO has a bigger advantage in short-lived TCP sessions (like web
browsers) where you open several independent TCP connections to fetch
data in parallel and then close them down. Here TFO will have an edge.
Agreed.
Now you might argue about the crypto part in the TFO SYN cookies, but
that is entirely handled by the kernel and TCP stack - nothing OpenVPN
(or any other application) will need to or can care about.
Agreed.
My idea (as daft as it is) would only serve one purpose: To hide a
listening TCP port. Because there would be no SYN-ACK from the server
if the SYN failed security checks.
I do understand that designing the internet protocols is far more
complex than I realise and also under taken by people with far greater
knowledge than myself.
But as TFO is allowing data in the SYN packet, if the kernel were to
take this one step further and deliver that data directly to the
application (upon request of an "Extended TCO Socket" TM) then the
application could verify the connection attempt immediately and signal
that to the kernel ...
I know, in the big picture, this would really not achieve anything
particularly worth while. It was just a thought :)
Regards
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
