New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reuse Session key on data connection #5087
Comments
The issue is that our SSL session cache is by both host and port number. Using PASV to initiate the download will give a different port number than the control connection on port |
Thanks for your feedback. Haven't looked at the code myself, but couldn't we retrieve and clone the session key from the cache and create a new related entry in the session cache instead of doing a renegotiation? I guess at the time of creating the new connection for the download it's still known what the related control connection is. |
Replying to [comment:3 abrax5]:
The session caching is in a private class in the |
Cross referencing to bug reports in thirdparty software: |
I looked at GNU classpath, and there's a file called ClientHandshake.java:
Maybe Cyberduck could use a modified version of GNU classpath for this use case and modify the AbstractSessionContext implementation so that it returns a previously used session for the same host even though the port is different? |
I'm not really that familiar with Java, but looking at this: The protected constructor for an SSLContext allows you to specify an SSLContextSpi. Maybe we could override SSLContext implementation with one that uses an SSLContextSpi derived from the default one, that just differs in what it would return for These are just some rough ideas, but may through this path we could tell the TLS engine to try reusing a session. We don't really need access to the masterSecret of the session, I think. We just need to make sure that the TLS engine can find the old ID and advertise the reuse ID to the server in the CLIENT_HELLO msg. |
Replying to [comment:7 abrax5]:
Yes, the peer port is what is causing a new session being created. The solution must somehow overwrite the peer port. |
Replying to [comment:8 abrax5]: We have a problem delegating to the default context because everything has protected access. Also a new |
In OpenJDK, this code is in ClientHandshaker.java: (from http://download.java.net/openjdk/jdk6/)
So it'd be really useful if we can hook in there to replace the SSLSessionContext with our own implementation. |
Replying to [comment:11 abrax5]:
Yes, that is what I meant above that the relevant code is in |
A workaround if the server allows would be to open the data socket without TLS. Uncheck Try to use TLS for data channel in Preferences → FTP → Data Channel Security. |
Replying to [comment:11 abrax5]:
Let me know if you have found any resolution for this. I am clueless how this could be best achieved. |
I saw that it's described as a known issue in the Wiki, but still, could this be implemented?
From the ProFTPd documentation (http://www.proftpd.org/docs/contrib/mod_tls.html)
I see this incompatibility with my Debian ProFTPd 1.3.3a.
Thanks
The text was updated successfully, but these errors were encountered: