9

I've just run into a problem with our FTPS server refusing connections due to missing SSL session reuse. Our client actually should reuse them, but it just doesn't work. I'm well aware that it's not good for performance, but with currently tens of connections per hour, it has a very low priority.

So I solved it by configuring ProFTPd using

TLSOptions NoSessionReuseRequired

I wonder, are there any security implications?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
maaartinus
  • 684
  • 5
  • 12
  • In case there are none, I don't understand why the server behaves by default the way it does, creating problems for clueless users. – maaartinus Apr 07 '18 at 03:13

1 Answers1

10

There are potential issues with disabling session resumption for PASV mode FTP. These issues are solved by session resumption as it allows the server to know that the party that initiated the connection is the same one who is now transmitting data (as PASV mode uses multiple ports).

In general however, there are no security implications for disabling session resumption, although it will put a higher load on the server if it has to do a complete TLS handshake for each connection, especially if there are many connections. Its only purpose is to reduce connection latency.

There are two types of session resumption:

  1. Session identifiers are the original technique for implementing session resumption. These identifiers are unique values a server gives to each client. The server will store the session information alongside the session identifier. When the client connects a second time, it presents the server with the session ID, and the server will resume the session.

  2. Session tickets are an encrypted blob of data containing information about the session that the server gives to clients. The clients will cache this ticket and will send it to the server next time it connects. The server now only has to store the key to decrypt the ticket. This is similar to a session ID, but rather than the server storing each per-client session, the server offloads this storage to the client. This is the most common form of session resumption.

TLS 1.3 will additionally add a new type of session resumption, called 0-RTT.

forest
  • 64,616
  • 20
  • 206
  • 257
  • Thanks. Now I understand what should be reused: I only though about the reuse between separate connections, but it's about the reuse between the control and data connections. This really makes sense. `+++` Why are calling the issues "potential"? We're using PASV. To me, guessing the port is not that improbable and doing it in the right time is not hard when you can observe the pattern for a while (we do it all pretty periodically). – maaartinus Apr 07 '18 at 03:58
  • @maaartinus The issues are "potential" because you do not always need to use PASV mode. Also, client certificates mitigate this issue even better if you do have to use PASV. – forest Apr 07 '18 at 03:59
  • But we're using PASV mode and no client certificate now, so I guess, I should change something with a high priority. – maaartinus Apr 07 '18 at 04:04
  • 2
    Yep, if you are using PASV with no client certificate or session resumption, you really need to up the priority of resolving this issue. Either get a client that supports it (or client certs), or switch to another protocol for file transfers (OpenSSH's SFTP or rsync, for example). – forest Apr 07 '18 at 04:07
  • "_There are potential issues with disabling session resumption for PASV mode_" How is PORT mode safer? – curiousguy Jun 20 '18 at 20:54