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?
>>>>>
>>>>
>>>
>>
>
