Page 1 of 1
TLS Session Ticket Not Received on Server
Posted: 2021-05-27 21:43
by greyreap
I've been working on a custom FTP server and am struggling to get session resumption working. The server uses TLS 1.3 which requires using session tickets for resumption. However, on the server when I inspect for a session ticket being sent none is present using a FZ 3.54.1 client. While I could downgrade the server to use TLS 1.2 and utilize session caching that would seem to be counter to wise security practice.
Is there something I'm missing in terms of FZ's session resumption support? I've not read anything that explicitly states session tickets are used in FZ but I've seen security advisories that would seem to imply they are. Any guidance here is appreciated.
Re: TLS Session Ticket Not Received on Server
Posted: 2021-05-31 06:56
by botg
Does your server send a session ticket at the end of the handshake on the control connection to the client?
If you set the debug log level to 4 in FileZilla, you should see a line with "Received NEW SESSION TICKET" shortly after the handshake completes.
Re: TLS Session Ticket Not Received on Server
Posted: 2021-06-01 13:57
by greyreap
Thanks so much for that guidance. Yes, it does appear FZ is getting the initial ticket from the server. Though it seems to happen a couple times during the handshake:
Code: Select all
2021-06-01 09:54:17 18592 1 Status: TLS connection established, waiting for welcome message...
2021-06-01 09:54:17 18592 1 Trace: CFtpControlSocket::OnReceive()
2021-06-01 09:54:17 18592 1 Trace: tls_layer_impl::on_read()
2021-06-01 09:54:17 18592 1 Trace: CFtpControlSocket::OnReceive()
2021-06-01 09:54:17 18592 1 Trace: TLS handshake: Received NEW SESSION TICKET
2021-06-01 09:54:17 18592 1 Trace: TLS handshake: Processed NEW SESSION TICKET
2021-06-01 09:54:17 18592 1 Trace: gnutls_record_recv returned spurious EAGAIN
2021-06-01 09:54:17 18592 1 Trace: TLS handshake: Received NEW SESSION TICKET
2021-06-01 09:54:17 18592 1 Trace: TLS handshake: Processed NEW SESSION TICKET
2021-06-01 09:54:17 18592 1 Trace: gnutls_record_recv returned spurious EAGAIN
2021-06-01 09:54:17 18592 1 Trace: tls_layer_impl::on_read()
2021-06-01 09:54:17 18592 1 Trace: CFtpControlSocket::OnReceive()
2021-06-01 09:54:17 18592 1 Response: 220 Ready
Re: TLS Session Ticket Not Received on Server
Posted: 2021-06-01 18:01
by botg
In TLS 1.3 resumption happens through the pre_shared_key extension in the client hello.
Re: TLS Session Ticket Not Received on Server
Posted: 2021-06-01 18:32
by greyreap
That definitely clarifies things on my side. I shall take that knowledge and try to get something working, thanks so much
Re: TLS Session Ticket Not Received on Server
Posted: 2021-06-02 00:43
by botg
Note that presence of the extension in the client_hello doesn't actually tell whether the session is actually resumed.
Which TLS library are you using? With a modern library such as GnuTLS it's as simple as checking whether gnutls_session_is_resumed returns non-zero.
Re: TLS Session Ticket Not Received on Server
Posted: 2021-06-02 02:00
by greyreap
I'm using OpenSSL via Node. I've relied too much on Node's docs which I'm either reading incorrectly (most likely this) or are not jiving with the actual RFC specs. Either way, based on the info you've provided and a look at the specs I think there is more work to do on the server implementation to get things working.
I really appreciate the info you provided, I will update if/when I find a solution within Node if for nothing but documentation purposes for future googlers.
Re: TLS Session Ticket Not Received on Server
Posted: 2021-06-02 07:09
by botg
OpenSSL at least has SSL_session_reused. The important bit with OpenSSL is to use a separate SSL_CTX for each FTP control connection to prevent session from one FTP connection contaminating the sessions of another. Such contamination would lead to data connection stealing attacks.
In addition, even if you verify that the connection is reused, you need to make sure the session actually matches the control connection, see
https://filezilla-project.org/misc/ftps ... xploit.cpp why this needs to be. I think these days, calling SSL_CTX_set_session_cache_mode with SSL_SESS_CACHE_NO_INTERNAL together with manual session caching callbacks could be an appropriate solution, haven't tested it though.