Failing data connection with STARTTLS (Explicit TLS): tls session not reused about goftp

[LitixThomas]

No issue,

golang tls lib handle SessionTickets automatically. The tls.Config.SessionTicketsDisabled must be set to false and the important step is define a tls.Config.ServerName. Only with a valid ServerName can tls lib handle Sessionstickets correctly.

tls.Config.SessionTicketsDisabled = false // is default
tls.Config.ServerName = "<your servername>"

Tested with Filezilla Server and go1.17.3. Working for me.

[mickael-kerjean]

Same issue here as well. I tried the ClientSessionCache trick with a size of 32 and 0 and the FTPS server still complain ReadDir unexpected response: 522-SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page

It seems TLS has 2 ways to avoid renegociating SSL on every request:

1. a ticket based mechanism
2. a session based mechanism

The catch is Golang doesn't seem to support the session based mechanism: FiloSottile/go@2a38c62. I hope I an wrong somewhere and that my understanding of TLS simply isn't good enough 🤞

[jwatson-gcu]

I think setting the cache to size zero is the key.

tls.Config.ClientSessionCache = tls.NewLRUClientSessionCache(0)

[dropthemasquerade]

I think setting the cache to size zero is the key.

tls.Config.ClientSessionCache = tls.NewLRUClientSessionCache(0)

tlsConfig := &tls.Config{
	ClientAuth:               tls.RequestClientCert,
	InsecureSkipVerify:       true,
	//MinVersion:               tls.VersionTLS12,
	//CurvePreferences:         []tls.CurveID{tls.CurveP521, tls.CurveP384, tls.CurveP256},
	//PreferServerCipherSuites: true,
	//CipherSuites: []uint16{
	//	tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
	//	tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
	//	tls.TLS_RSA_WITH_AES_256_GCM_SHA384,
	//	tls.TLS_RSA_WITH_AES_256_CBC_SHA,
	//},
	SessionTicketsDisabled: false,
	ServerName: ftpAddr,
	ClientSessionCache: tls.NewLRUClientSessionCache(0),
}

I was trying many times, finally, ClientSessionCache: tls.NewLRUClientSessionCache(0), is working, thank you ! @jwatson-gcu

[BobCashStory]

Did you have a look at : #30

[wackerm]

Yes i have seen #30 and even tried the recommended fix. But this does not help. I think this is a different issue. Here the EPSV-Mode is not a problem, the above mentioned error exists also with PASV-Mode.
I try to find more informations about the SSL-Session-Reusage. I will dig deeper into the function prepareDataConn()...

[wackerm]

I found some details on tls session reusage here https://security.stackexchange.com/a/183135:

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.

So RFC5077 seems to be applicable here (https://tools.ietf.org/html/rfc5077).

It would be great if anybody has some hints how we could implement this in go...

[muirdm]

Go already supports session tickets via the standard library crypto/tls package. It looks like you need to set ClientSessionCache in tls.Config to enable session caching. Can you try setting ClientSessionCache (to e.g. tls.NewLRUClientSessionCache(0))?

[wackerm]

@muirdm well, i was using this configuration ClientSessionCache in tls.config right from the start, but it did not help (same experience than @mickael-kerjean)...

The issue is, that the ssl session for the data channel should be the same as the established session for the control channel.
I am not sure, if it has to be a session id based caching as session resumption could also work based on session tickets. this leads to following questions, which i could not answer at the moment:

1. Do common FTP-Servers (ProFTPD, vsftpd, FileZilla) support session tickets for session resumption or is this independet from the server side (i guess not)?
2. Is the implementation of session tickets working with the current code of goftp?
3. Since crypto/tls does not support session id based caching yet and the corresponding proposing issue #25228 is on hold since may 2018, there might be no help from @FiloSottile or other core devs. So
   do we need a custom implementation of session id based caching for goftp?

[wackerm]

To answer the first question, i just checked with the source code from FileZilla Server (see AsyncSslSocketLayer.cpp, around Line 1259) which uses OpenSSL under the hood. It seems to support both session cache variants. So i guess it should work indeed also with session tickets...
By the way ProFTPD uses OpenSSL under the hood aswell (mod_tls )...

[wackerm]

I can confirm, that session resumption with FileZilla Server is working, because as mentioned above, FileZilla Server supports session tickets, while ProFTPD (at least in Version 1.3.5b, default in Debian Stretch) does not...
This answers question 1 and 2.

[luckcolors]

Hello.
I'm trying to use the library to connect to a Filezilla FTP server with implicit, but i'm running in the same problem, the client is not reusing the tls session.

Current attempts i've tried as suggested:
ClientSessionCache(32).
and not defining a session cache (haven't tried using a cache with size 0 but i don't think it makes a difference).

The error i get is specifically when attempting to upload/download anything wich causes the creation of a data connection:

EOF

Have there been any updates on this? I really would like to avoid having to disable SSL session reuse on the server.

[yakuter]

Thank you LitixThomas We were dealing with this problem for two days When we set ServerName and ClientSessionCache, it just worked smoothly 👌 Thank you very much for this great advice