You are right, I guess I missed the other arrow when I was looking at it. Sai Pullabhotla
On Tue, Apr 19, 2011 at 7:57 PM, sebb <seb...@gmail.com> wrote: > On 19 April 2011 17:35, Sai Pullabhotla <sai.pullabho...@jmethods.com> wrote: >> Looking at the sequence diagrams in the RFC 4217, the server should >> initiate the TLS shutdown. > > Not sure I read it that way: > > CCC ----------------------------------------------> > <---------------------------------------------- 200 > TLSshutdown() <-------------------------------------> TLSshutdown() > > The above sequence looks to me as though both ends need to invoke shutdown. > >> Is it possible for the client (JSSE) to >> determine when this shutdown finishes, so the client can wait before >> it sends the next command on the plain socket? What would happen if >> the client sends the next command while TLS shutdown is in progress? > > If both ends invoke shutdown after the CCC response, that should not > be a problem. > >> Sai Pullabhotla >> >> >> >> On Tue, Apr 19, 2011 at 10:57 AM, David Latorre <dvl...@gmail.com> wrote: >>> 2011/4/19 sebb <seb...@gmail.com>: >>>> On 19 April 2011 14:46, Sai Pullabhotla <sai.pullabho...@jmethods.com> >>>> 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. >>> >>> I do believe that TLS_CLOSE signal is the expected behaviour. RFC4217 >>> states that: >>> Otherwise, the server is accepting the CCC command and should do >>> the following: >>> >>> o Send a 200 reply. >>> >>> o Shutdown the TLS session on the socket and leave it open. >>> >>> I'm trusting here this link that explains ssl shutdown: >>> http://linux.die.net/man/3/ssl_shutdown >>> >>> So, I guess that close notify is the way to go and if that's the only >>> reason to fail, it's the client which is broken. >>> >>> This said, Sun Java SSL implementation seems more restrictive than >>> others. I found an issue with WinSCP where , for some file sizes >>> (when you're using a block cipher for the encryption of the secure FTP >>> data connection - which I think is most often the case in SSL >>> connections), the TLS_CLOSE message gets truncated. >>> This is a bug in WinSCP, of course, but it caused Mina FTPServer to >>> abort the transfer (when the file has been already received!) whilst >>> other servers completely ignored the fact that the TLS_CLOSE message >>> was incorrect. >>> >>> So I would only implement CCC if I was sure that most clients that >>> support this command can interact seamlessly with FTPServer, to my >>> mind it's not that useful a feature if it means we can end up with >>> unexpected (and 'superflous') connection losses. >>> >>>>> >>>>> 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. >>> >>> Oh, that's great news. I just reviewed a few changes I had to include >>> in the codebase and I think all of them are included - even better! >>> >>> >>>> Maybe between us we can fix ftpserver and net ... >>>> >>>>> Sai Pullabhotla >>>>> >>>>> >>>>> >>>>> On Tue, Apr 19, 2011 at 8:23 AM, sebb <seb...@gmail.com> wrote: >>>>>> On 19 April 2011 13:47, Sai Pullabhotla <sai.pullabho...@jmethods.com> >>>>>> 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? >>>>>> >>>>> >>>> >>> >> >
