KERMIT FTP CLIENT - FREQUENTLY ASKED QUESTIONS

As of: K95 2.1.3, C-Kermit 8.0.209
This File Last Updated: Tue Oct 28 11:42:23 2003

CONTENTS

• THE NATURE OF THE PRODUCT

---

THE NATURE OF THE PRODUCT

What Are Active and Passive Mode?

FTP protocol uses two connections; one for commands and responses, another for data. When you give your FTP client a data transfer command such as GET or PUT, a second port is opened for the data. The server's command (control) port is normally 21 and its data port is normally 20. The client, however, can use any random port numbers greater than 1024 for its end of each connection:

• In Active Mode, the client tells the server its data port number and then waits for the server to open a data connection to that port.

• In Passive Mode, the client tells the server to enter Passive Mode with a PASV command; the server responds with its port number and waits for a connection from the client on that port.

Passive is Kermit's default mode since it tends to work better with firewalls. This is because the choice of port numbers is controlled inside the server-side firewall, and thus the server and the firewall can be configured by the site's network and system administrators to accommodate each other.

On secure FTP connections, commands and responses are encrypted and therefore cannot be understood by firewalls. Which brings us to the next question...

How Do I Use Secure FTP Through a Firewall?

If you have a firewall that filters the FTP command stream, it does not understand the encrypted messages and therefore is likely to terminate the control connection and/or block the data connection. Error messages will usually be uninformative, as in this example where the firewall closes the connection as soon as the client and server begin to encrypt their messages:

K-95> set ftp authtype ssl
K-95> set ftp debug on
K-95> ftp open xyzcorp.com
---> AUTH SSL
234 SSL enabled and waiting for negotiation
SSL accepted as authentication type
ftp: SSL/TLS connect command error:
error:00000000:lib(0):func(0):reason(0)
SSL authentication failed
K-95>

If you can't log in at all, you have to talk to the firewall administrator. If you can log in but can't transfer data (DIR, GET, PUT, etc), try switching modes (Active/Passive). FTP passive mode should work if the firewall is configured to allow connections to the ports that the FTP server chooses. If not, the problem can be solved only by your network/firewall administrator. Failing that, you'll have to make clear-text FTP connections (if the servers to which you need to make connections allow them), or else a different protocol (such as Kermit, which uses only one connection, not two).

What Are the Variations on SSL/TLS Security for FTP?

The following variations have come up during development of Secure FTP (FTPS):

1. "SSL CONNECT", in which a connection is made to a special port (e.g. 990 instead of 21) and SSL negotiations happen automatically. Kermit does this when you include the /SSL (or /TLS) switch in the FTP OPEN command.

2. "AUTH SSL", in which the connection is made to port 21 and then SSL negotiations are started when the client sends an AUTH SSL command.

3. "AUTH TLS", in which the connection is made to port 21 and then TLS negotiations are started when the client sends an AUTH TLS command, and then a protection level is negotiated with the PROT command.

You have to use a method that is supported by the server. Method 3 is currently favored; the other two are "deprecated". Method 1 is not used by Kermit unless you ask for it. Methods 2 and 3 are negotiated automatically, with the first preference going to TLS; i.e. Kermit sends AUTH TLS first and then sends AUTH SSL only if AUTH TLS is refused. If necessary you can force Kermit to send AUTH SSL first (or send only AUTH SSL) with the SET FTP AUTHTYPE command.

For a table of FTPS servers that shows which of the three methods each uses, see:

http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

How Do I Force a Clear-Text (Non-Secure) FTP Connection?

Secure FTP is rather new on the scene and not all combinations of client and server interoperate smoothly. When faulty negotions for SSL, TLS, or other security methods prevent Kermit from getting through to a server, you might have to force a particular kind of negotiation, or disable security negotiations altogether. For example:

SET FTP AUTHTYPE TLS  ; Forces AUTH TLS because AUTH SSL is "deprecated".
SET FTP AUTOAUTH OFF  ; Disables negotiation of an authentication method.

Why Can't I Make a Secure Connection to WS_FTP?

When Kermit 95 attempts to make a secure FTP connection ("set ftp auth ssl" or "set ftp auth tls") to the Ipswitch FTP server, WS_FTP:

http://www.ipswitch.com/Products/file-transfer.html

the connection fails. Debugging messages show:

ftp: SSL/TLS connect COMMAND error: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number

The protocol for this is still in the discussion (Internet Draft) stage. The current draft is here:

http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-11.txt

According to the proposed specification, when negotiating AUTH TLS, the TLSv1 protocol is required. WS_FTP, however, does not seem to support SSLv3 or TLSv1 but only SSLv2.

Experimentation shows that the WS_FTP implementation of AUTH SSL and AUTH TLS is incorrect, or at least undependable, in WS_FTP versions 3.0 to 3.1.4 to 4.0.0. In each case it was possible to establish connections using SSLv3. However, more often then not after the SSLv3 client Hello packet was sent to WS_FTP the server Hello packet was never returned. Eventually the connection timed out and the Kermit client reported an incorrect version number because the connection was dropped. There is nothing that can be done about this problem from within the Kermit client, which follows the specification.

Note that there is no way to tell the client to select between SSLv2, SSLv3, and TLSv1. These are (and must be) negotiated between client and server.

What Other Secure FTP Servers Are Available?

See Peter Runestig's public ftp server at ftp://ftp.runestig.com/ for source code to popular FTP servers patched to support AUTH TLS. Also see http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html for more FTPS implementations and a great deal more information on this topic.

[ Top ]