On 20 April 2011 12:50, Sai Pullabhotla <[email protected]> wrote:
> 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.
There seems to be a bug in Mina-core. I'm seeing the following log
message sequence:
[ INFO] 2011-04-20 13:47:52,537 [anonymous] [127.0.0.1] RECEIVED: CCC
[ INFO] 2011-04-20 13:47:52,553 [anonymous] [127.0.0.1] SENT: 200 Okay
[ INFO] 2011-04-20 13:47:52,553 [anonymous] [127.0.0.1] SENT:
HeapBuffer[pos=0 lim=23 cap=32: 15 03 01 00 12 C9 5D 89 4B BA 39 1C 52
FD F0 5E...]
with the default mina-core-2.0.0-RC1.jar. If I change to
mina-core-2.0.3.jar the message changes to:
[ INFO] 2011-04-20 13:45:55,675 [anonymous] [127.0.0.1] RECEIVED: CCC
[ INFO] 2011-04-20 13:45:55,675 [anonymous] [127.0.0.1] SENT: 200 Okay
[ INFO] 2011-04-20 13:45:55,675 [anonymous] [127.0.0.1] SENT:
HeapBuffer[pos=23 lim=23 cap=32: empty]
Looks like there may be a dummy IO entry somewhere that should be
skipped when logging?
In both cases the last SENT message causes a class cast error:
[ WARN] 2011-04-20 13:54:25,641 [anonymous] [127.0.0.1] EXCEPTION :
java.lang.ClassCastException:
org.apache.mina.core.buffer.SimpleBufferAllocator$SimpleBuffer cannot
be cast to org.apache.ftpserver.ftplet.FtpReply
at
org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageSent(FtpHandlerAdapter.java:67)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageSent(DefaultIoFilterChain.java:724)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageSent(DefaultIoFilterChain.java:459)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:46)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageSent(DefaultIoFilterChain.java:799)
at
org.apache.mina.filter.logging.LoggingFilter.messageSent(LoggingFilter.java:183)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageSent(DefaultIoFilterChain.java:459)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:46)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageSent(DefaultIoFilterChain.java:799)
at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:75)
at
org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:136)
at
org.apache.mina.filter.util.CommonEventFilter.messageSent(CommonEventFilter.java:75)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageSent(DefaultIoFilterChain.java:459)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:46)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageSent(DefaultIoFilterChain.java:799)
at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageSent(ProtocolCodecFilter.java:274)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageSent(DefaultIoFilterChain.java:459)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:46)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageSent(DefaultIoFilterChain.java:799)
at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:75)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:780)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:772)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:714)
at java.lang.Thread.run(Thread.java:662)
This appears to be due to the unexpected SENT entry, but it's
difficult to trace because it's all done asynchronously.
Perhaps the SSL deregister needs to be followed by a wait for the IO
to complete?
> 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?
>>>>>>
>>>>>
>>>>
>>>
>>
>
