FZ server and IP*Works

[ik13]

I was evaluating the IP*Works component and found it
not to work with FZ server in FTP implicit mode.
The guys at IP*Works responded right away and tried to
research the issue. There's what they said:

"
Our developers have done some more research on this
issue, and there are
some problems here that appear to be with the server.
Since it is still in
beta, this is not very surprising. In Explicit mode on
upload, the component
simply closes the data connection but the server
reports a 426 FTP error.
I'm not sure why the server is doing this, since the
component is performing
the appropriate action. In Implicit, it appears that
the server is not even
responding to the SSL handshake for the data
connection. At this point,
there is nothing that can be done within the component
to accommodate this
server. Hopefully when the server is no longer in
Beta, these issues will
have been resolved. At that time, if there are still
some other problems, we
will be happy to investigate them. You may also
consider reporting these
errors to the makers of the FTP server for their input
and consideration.
"

Any comments?

[Tim Kosse]

In Explicit mode on upload, the component simply closes

the data

connection but the server reports a 426 FTP error.

That doesn't sound proper. The client should do a proper SSL
shutdown sequence prior to closing the connection. Can you
please request further information how exactly IP*Works
closes connections?

[ik13]

I can forward your message to them (though I'm still in evaluation and formally don't have
the support option).
That said - you might want to contact them directly - as vendor to vendor sort of thing.
Their components seem to be quite popular and it will be beneficial for both sides to iron
out the possible wrinkles between the products. From the few emails I exchanged with them,
they seem easy to work with...

​http://www.nsoftware.com/download/Default.aspx

[ik13]

There's the response from IP*Works:
"
...
From my wording it was not apparent, and I apologize for the confusion. The components
always perform the proper shutdown sequence here. This is the first server we've
encountered that has resulted in this behavior. In implicit mode, you can look at the
SSLStatus event and see that the server is not responding to the handshake data that we
sent upon the creation of the data channel. I realize the server is still in beta. As
mentioned previously, at this time, there is nothing that the component can do to avoid
either of these errors. If these errors are still present when communicating with the full
release, we will be more than happy to investigate the issue again at that time.
"

[Tim Kosse]

Is there any sample application showing the problem? I'd
like to analyze it further.

[ik13]

You can go to ​http://www.nsoftware.com/ and download their IP*Works! SSL (.NET) trial.
It comes with sample application.

[Tim Kosse]

It's definitely a bug in IP*Works.

In implicit mode, it sends no PROT command. RFC 2228
(​http://filezilla-project.org/specs/rfc2228.txt) states the
following in this case:
"The default protection level if no other level is specified
is Clear"

This gets further claried in RFC 4217
(​http://filezilla-project.org/specs/rfc4217.txt):
"To protect the data channel as well, the PBSZ command,
followed by the PROT command sequence, MUST be used."

Yet IP*Works tries to perform a SSL Handshake. Which
obviously will fail, since FileZilla follows RFC 2228 and
sends the data in plaintext.