You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-users@mina.apache.org by Sai Pullabhotla <sa...@jmethods.com> on 2011/04/19 14:47:06 UTC
Supporting CCC (Clear Command Channel) command
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.
Thanks.
Sai Pullabhotla
Re: Supporting CCC (Clear Command Channel) command
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Apr 20, 2011 at 1:50 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> I'm not sure if a server should allow CCC on an implicit SSL control
> connection. What do you guys think?
I think a CCC should be rejected on implicit SSL.
> Also, the server should reject CCC request on a un-authenticated
> session (or not logged in). Do you guys agree to this?
Agreed.
/niklas
Re: Supporting CCC (Clear Command Channel) command
Posted by sebb <se...@gmail.com>.
On 20 April 2011 12:50, Sai Pullabhotla <sa...@jmethods.com> 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 <se...@gmail.com> wrote:
>> On 19 April 2011 17:19, Sai Pullabhotla <sa...@jmethods.com> 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 <se...@gmail.com> wrote:
>>>> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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.
>>>>>
>>>>> 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 <se...@gmail.com> wrote:
>>>>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by Sai Pullabhotla <sa...@jmethods.com>.
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 <se...@gmail.com> wrote:
> On 19 April 2011 17:19, Sai Pullabhotla <sa...@jmethods.com> 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 <se...@gmail.com> wrote:
>>> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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.
>>>>
>>>> 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 <se...@gmail.com> wrote:
>>>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>>>
>>>>
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by sebb <se...@gmail.com>.
On 19 April 2011 17:19, Sai Pullabhotla <sa...@jmethods.com> 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 <se...@gmail.com> wrote:
>> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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.
>>>
>>> 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 <se...@gmail.com> wrote:
>>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>>
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by Sai Pullabhotla <sa...@jmethods.com>.
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.
Sai Pullabhotla
On Tue, Apr 19, 2011 at 9:09 AM, sebb <se...@gmail.com> wrote:
> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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.
>>
>> 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 <se...@gmail.com> wrote:
>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by Sai Pullabhotla <sa...@jmethods.com>.
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 <se...@gmail.com> wrote:
> On 19 April 2011 17:35, Sai Pullabhotla <sa...@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 <dv...@gmail.com> wrote:
>>> 2011/4/19 sebb <se...@gmail.com>:
>>>> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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 <se...@gmail.com> wrote:
>>>>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by sebb <se...@gmail.com>.
On 19 April 2011 17:35, Sai Pullabhotla <sa...@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 <dv...@gmail.com> wrote:
>> 2011/4/19 sebb <se...@gmail.com>:
>>> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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 <se...@gmail.com> wrote:
>>>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>>>
>>>>
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by Sai Pullabhotla <sa...@jmethods.com>.
Looking at the sequence diagrams in the RFC 4217, the server should
initiate the TLS 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?
Sai Pullabhotla
On Tue, Apr 19, 2011 at 10:57 AM, David Latorre <dv...@gmail.com> wrote:
> 2011/4/19 sebb <se...@gmail.com>:
>> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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 <se...@gmail.com> wrote:
>>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>>
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by David Latorre <dv...@gmail.com>.
2011/4/19 sebb <se...@gmail.com>:
> On 19 April 2011 14:46, Sai Pullabhotla <sa...@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 <se...@gmail.com> wrote:
>>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>>
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by sebb <se...@gmail.com>.
On 19 April 2011 14:46, Sai Pullabhotla <sa...@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.
>
> 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 <se...@gmail.com> wrote:
>> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>>
>
Re: Supporting CCC (Clear Command Channel) command
Posted by Sai Pullabhotla <sa...@jmethods.com>.
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.
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.
Sai Pullabhotla
On Tue, Apr 19, 2011 at 8:23 AM, sebb <se...@gmail.com> wrote:
> On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?
>
Re: Supporting CCC (Clear Command Channel) command
Posted by sebb <se...@gmail.com>.
On 19 April 2011 13:47, Sai Pullabhotla <sa...@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?