Enable TLS tickets / resumption with OpenSSL on Linux

[stephentoub]

From dotnet/performance#1146 (comment)

On the OpenSSL side, tls tickets and resumption are possible but need to be explicitly requested and it is not used by default. If we believe there is value in this (mainly for microservices connecting to same endpoint) I can open a new issue in runtime repro to track it as feature work.

cc: @wfurt, @bartonjs

[mjsabby]

This would be a pretty good feature to have for reasons mentioned in the referenced conversation. Is there a prototype by any chance floating out there?

[wfurt]

part of it is in the linked PR. I just did not have time recently to push that to completion.
Are you mostly interested in client, server or both @mjsabby?

[mjsabby]

Both. Although server is likely more involved to change so it'll be better if it's just done by you. client you could imagine using other libraries and pinvoking.

[CumpsD]

If this would work, then maybe these can finally work:

• FTPS not working on Linux since SSL session resumption is not supported robinrodricks/FluentFTP#347
• FtpWebRequest not reusing ssl session on linux (FTPS) #27916

[webczat]

does that include any api to view/control session info? or is there any issue tracking it?

[wfurt]

not at the moment @webczat. For server I'm working on stateless support with session tickets to replace old #32763.
It feels like the client should have control via API but then there is the platform reality. AFAIK there is no way how to control this directly on Windows (other than global registry) That is very different from Linux where everything is contained in your app.

[webczat]

seems like using openssl even on windows could have it's advantages hah
And seriously, what about tls 1.3 way of session resumption? this uses none of that, or more like it uses something similar to session tickets if I get it correctly, unsure... like never read session ticket spec, and forgot details from tlsv13 spec

[heppth]

I am very surprised that such an issue remains open for so long, although the benefits are very significant. I really hope that this issue will be added to the next milestone.

To illustrate the significant limitations...

A) [Security][Performance] .net core based web servers assign TLS session IDs but do not accept them (see screenshot from SSL Labs)

B) [Security] It is not possible to run secure FTP servers on Linux with .net core (see screenshot from FileZilla)

C) [Security][Performance] efficient secure communication between microservices is limited

Please do not underestimate the value of this issue. Especially in view of the many linked issues.

[GregFinzer]

This also affects the Windows version of Filezilla Server. You can connect to the server but you can't get a directory listing, upload, or download files.

425 Unable to build data connection: TLS session of data connection not resumed.

My FTP Library that I built can no longer be used with Filezilla Server because it uses the SSL in the .NET Framework.
https://kellermansoftware.com/collections/frontpage/products/net-ftp-library

Other libraries have had to change as well:

• https://forum.rebex.net/19415/ftps-tls-session-of-data-connection-not-resumed?show=19435
• https://en.delphipraxis.net/topic/6114-tls-with-filezilla-ftp-server-tls-data-session-not-resumed/
• https://forum.filezilla-project.org/viewtopic.php?t=54027
• https://winscp.net/forum/viewtopic.php?t=31396
• https://community.progress.com/s/article/Error-425-Can-t-open-data-connection-1307565974920

[wfurt]

Note the even if this is implemented, this will IMHO not solve the FTP problems. Session resume is fully optional and there is really no API to force it - on either platform. Making FTP server to require it clearly breaks the protocol layering.
I would strongly recommend to fix the server as this going to be problematic.

[stephentoub]

@wfurt, is there more to do on this issue?

[wfurt]

Strictly speaking - no. I was thinking to add some more AppContext tuning like cache size or expiration. You can do it via registry on Windows.
And I wanted to go back to some of the old issues and re-run benchmarks.
And we do not try to resume inn number of cases - like client certificate are in use or cipher suite policy.
It may work but I was not sure so I excluded some cases just to be sure.
There are not common IMHO so I would feel the main spirit of this issue is fulfilled.

[karelz]

@wfurt should we close it in that case?