Opened on Aug 6, 2010 at 10:14:21 PM
Closed on Mar 16, 2013 at 4:26:47 PM
Last modified on Jan 12, 2021 at 10:12:44 AM
#5087 closed enhancement (fixed)
Reuse Session key on data connection
Reported by: | abrax5 | Owned by: | dkocher |
---|---|---|---|
Priority: | low | Milestone: | 4.3 |
Component: | ftp-tls | Version: | 3.5.1 |
Severity: | normal | Keywords: | proftpd |
Cc: | Architecture: | Intel | |
Platform: | Mac OS X 10.6 |
Description (last modified by dkocher)
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)
- NoSessionReuseRequired
As of ProFTPD 1.3.3rc1, mod_tls only accepts SSL/TLS data connections that reuse the SSL session of the control connection, as a security measure. Unfortunately, there are some clients (e.g. curl) which do not reuse SSL sessions.
I see this incompatibility with my Debian ProFTPd 1.3.3a.
Thanks
Change History (27)
comment:1 Changed on Aug 8, 2010 at 11:04:25 AM by dkocher
- Component changed from core to ftp-tls
- Description modified (diff)
comment:2 Changed on Aug 28, 2010 at 3:44:36 PM by dkocher
comment:3 follow-up: ↓ 4 Changed on Aug 30, 2010 at 1:10:57 PM by abrax5
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.
comment:4 in reply to: ↑ 3 Changed on Aug 30, 2010 at 1:38:17 PM by dkocher
Replying to abrax5:
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.
The session caching is in a private class in the sun.security package I cannot access.
comment:5 Changed on Sep 16, 2010 at 1:52:57 PM by dkocher
Issue is documented in the wiki.
comment:6 Changed on Sep 16, 2010 at 4:41:41 PM by dkocher
Cross referencing to bug reports in thirdparty software:
comment:7 follow-up: ↓ 9 Changed on Sep 17, 2010 at 10:23:05 AM by abrax5
I looked at GNU classpath, and there's a file called ClientHandshake.java:
case WRITE_CLIENT_HELLO: { ClientHelloBuilder hello = new ClientHelloBuilder(); AbstractSessionContext ctx = (AbstractSessionContext) engine.contextImpl.engineGetClientSessionContext(); continued = (SessionImpl) ctx.getSession(engine.getPeerHost(), engine.getPeerPort());
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?
comment:8 follow-up: ↓ 10 Changed on Sep 17, 2010 at 12:18:56 PM by abrax5
I'm not really that familiar with Java, but looking at this: http://download.oracle.com/javase/6/docs/api/javax/net/ssl/SSLContext.html
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 engineGetClientSessionContext(). This method returns an SSLSessionContext which allows enumerating SessionIDs.
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.
comment:9 in reply to: ↑ 7 Changed on Sep 17, 2010 at 1:12:43 PM by dkocher
Replying to abrax5:
I looked at GNU classpath, and there's a file called ClientHandshake.java:
case WRITE_CLIENT_HELLO: { ClientHelloBuilder hello = new ClientHelloBuilder(); AbstractSessionContext ctx = (AbstractSessionContext) engine.contextImpl.engineGetClientSessionContext(); continued = (SessionImpl) ctx.getSession(engine.getPeerHost(), engine.getPeerPort());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?
Yes, the peer port is what is causing a new session being created. The solution must somehow overwrite the peer port.
comment:10 in reply to: ↑ 8 Changed on Sep 17, 2010 at 1:18:45 PM by dkocher
Replying to abrax5:
We have a problem delegating to the default context because everything has protected access. Also a new SSLContext is created using the factory method getInstance. Have to dig further.
comment:11 follow-ups: ↓ 12 ↓ 18 Changed on Sep 17, 2010 at 2:28:19 PM by abrax5
In OpenJDK, this code is in ClientHandshaker.java: (from http://download.java.net/openjdk/jdk6/)
HandshakeMessage getKickstartMessage() throws SSLException { ClientHello mesg = new ClientHello(sslContext.getSecureRandom(), protocolVersion); maxProtocolVersion = protocolVersion; clnt_random = mesg.clnt_random; // // Try to resume an existing session. This might be mandatory, // given certain API options. // session = ((SSLSessionContextImpl)sslContext .engineGetClientSessionContext()) .get(getHostSE(), getPortSE());
So it'd be really useful if we can hook in there to replace the SSLSessionContext with our own implementation.
comment:12 in reply to: ↑ 11 Changed on Sep 17, 2010 at 2:50:42 PM by dkocher
Replying to abrax5:
In OpenJDK, this code is in ClientHandshaker.java: (from http://download.java.net/openjdk/jdk6/)
Yes, that is what I meant above that the relevant code is in sun.security. We would need to replace a very large part of the JDK with custom implementations if we want to replace that implementation.
comment:13 Changed on Sep 19, 2010 at 10:43:08 PM by dkocher
Because of the proposal to switch to a secure connection if the server advertises AUTH TLS in its features, this has become a major issue for many. See #5168.
comment:14 Changed on Oct 5, 2010 at 7:25:58 PM by dkocher
Added configuration note to wiki.
comment:15 Changed on Oct 5, 2010 at 7:27:14 PM by dkocher
#5285 closed as duplicate.
comment:16 Changed on Nov 26, 2010 at 4:39:04 PM by dkocher
- Priority changed from normal to high
comment:17 Changed on Nov 28, 2010 at 9:26:18 PM by dkocher
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.
comment:18 in reply to: ↑ 11 Changed on Nov 29, 2010 at 10:05:54 PM by dkocher
Replying to abrax5:
In OpenJDK, this code is in ClientHandshaker.java
Let me know if you have found any resolution for this. I am clueless how this could be best achieved.
comment:19 Changed on Nov 30, 2010 at 6:53:32 PM by dkocher
#5484 closed as duplicate.
comment:20 Changed on Jan 25, 2011 at 1:59:38 PM by dkocher
- Type changed from enhancement to defect
comment:21 Changed on Jan 25, 2011 at 2:00:48 PM by dkocher
#5658 closed as duplicate.
comment:22 Changed on May 30, 2011 at 9:03:32 AM by dkocher
Blocked by NET-408.
comment:23 Changed on Jun 23, 2011 at 1:28:06 PM by dkocher
#6027 closed as duplicate.
comment:24 Changed on Oct 10, 2012 at 8:04:04 PM by dkocher
- Priority changed from high to low
- Summary changed from Reuse Session key on Data connection to Reuse Session key on data connection
- Type changed from defect to enhancement
comment:25 Changed on Mar 16, 2013 at 4:26:47 PM by dkocher
- Milestone set to 4.2.2
- Resolution set to fixed
- Status changed from new to closed
In r10760.
comment:26 Changed on Apr 10, 2013 at 4:32:55 PM by dkocher
Addendum in r10836.
comment:27 Changed on Jan 12, 2021 at 10:12:44 AM by dkocher
Addendum for running with latest runtime in r50436.
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 21 and therefore uses a new SSL session context.