I'm not sure if a server should allow CCC on an implicit SSL control connection. What do you guys think?
Also, the server should reject CCC request on a un-authenticated session (or not logged in). Do you guys agree to this? Based on the above two, we may have to update the CCC command implementation accordingly. When I tried closing the TLS from both ends, I could not get it to work consistently with Commons-Net. It worked some times and did not the other times. I will try it again and let you know what I find. Sai Pullabhotla On Tue, Apr 19, 2011 at 9:31 PM, sebb <[email protected]> wrote: > On 19 April 2011 17:19, Sai Pullabhotla <[email protected]> wrote: >> I've created a JIRA >> https://issues.apache.org/jira/browse/FTPSERVER-411 and attached my >> preliminary patch. I got this to work consistently with commons-net >> FTP API (trunk/patched CCC). In order to get this to work, I had to >> comment out the line that removes the SslFilter on the MINA's >> IoSession. In other words, the commons-net initiates the TLS close, >> and MINA is handling it well it seems. Finally, I'm not sure if we >> need to synchronize the code that I did in the CCC class. Note that I >> did not code for sending correct negative reply codes as per the RFC. > > For explicit SSL, removing the filter works fine for me. > > However, for implicit SSL, the ftpserver throws an error: > > java.lang.IllegalArgumentException: Filter not found:sslSessionFilter > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.checkOldName(DefaultIoFilterChain.java:333) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.remove(DefaultIoFilterChain.java:192) > at org.apache.ftpserver.command.impl.CCC.execute(CCC.java:61) > > This is because implicit SSL uses a different filter name - > "sslFilter" - see NioListener.start(FtpServerContext context) > > I've attached a new version of the code to the JIRA, which uses the > class name rather than the filter name. > > This works fine for both explicit and implicit SSL. > > However, there appears to be a session close issue, because running > the code repeatedly can cause errors in the server. These usually > clear up if the server is left idle for a short while. And of course > the errors clear up on restart. > > The errors only occur when using CCC. > >> Sai Pullabhotla >> >> >> >> On Tue, Apr 19, 2011 at 9:09 AM, sebb <[email protected]> wrote: >>> On 19 April 2011 14:46, Sai Pullabhotla <[email protected]> >>> wrote: >>>> I was trying it with one of our own home grown client API and with >>>> Apache Commons-net. The current release of commons-net is broken, but >>>> there is a patch that was submitted, which is in the trunk. With the >>>> trunk code of commons-net, it works once in a while (one out of 4 >>>> times). The rest of the times, it thinks that it received a bad ftp >>>> reply (most probably because of timing issue, and the fact that the >>>> MINA code sends the TLS_CLOSE signal). Looks like the TLS close signal >>>> is becoming part of the reply to the command that was sent right after >>>> CCC. >>> >>> What is the exact error message? >>> >>>> Our home grown API also runs into the same issue because of the TLS_CLOSE. >>>> >>>> At this point, I am trying to figure out the correct procedure to >>>> unwrap/unprotect an SSLSocket into a plain socket and who should >>>> initiate the TLS_CLOSE, and if it is really needed. >>> >>> Can you attach your current code as a JIRA patch, and then I can try >>> with Commons Net? >>> >>> I'm hoping to release Net 3.0 soon, and if there are issues with CCC >>> it would be nice to sort those first. >>> >>> Maybe between us we can fix ftpserver and net ... >>> >>>> Sai Pullabhotla >>>> >>>> >>>> >>>> On Tue, Apr 19, 2011 at 8:23 AM, sebb <[email protected]> wrote: >>>>> On 19 April 2011 13:47, Sai Pullabhotla <[email protected]> >>>>> wrote: >>>>>> Has any one tried to implement the CCC command in FTPS? I've been >>>>>> trying to do this, but having issues. I was wondering if any one has a >>>>>> better knowledge of what should be done to unprotect the control >>>>>> channel. >>>>>> >>>>>> Here is what I've tried: >>>>>> >>>>>> 1. Added an implementation class for CCC, and registered it with the >>>>>> factory >>>>>> 2. Server receives the CCC command from the client >>>>>> 3. Server sends a positive reply back to the client, and waits for the >>>>>> message to be sent using the await() method on the future. This should >>>>>> ensure that the reply to CCC is still sent over the encrypted channel. >>>>>> 4. Server removes the SslFilter from the filter chain of the session >>>>>> >>>>>> In theory (according to my understanding) this should do the trick, >>>>>> but I'm seeing different results with different clients. I could not >>>>>> get it to work consistently with any client. >>>>>> >>>>>> I noticed that the MINA code does send a TLS_CLOSE message to the >>>>>> client when the SslFilter is removed (from the onPreRemoveFilter >>>>>> method). Is this needed on the server or should the client initiate >>>>>> the TLS_CLOSE sequence, by closing the SSLSocket (without closing the >>>>>> underlying socket)? >>>>>> >>>>>> Does SSL (SSL v2 for example) also have a special close sequence like >>>>>> the TLS does? >>>>>> >>>>>> I appreciate any feedback, pointers on how to get this to work. >>>>> >>>>> It would be great if you could get this to work! >>>>> There don't seem to be many ftp servers that support CCC. >>>>> >>>>> What results are you seeing, and what clients are you using? >>>>> >>>> >>> >> >
