File transfer over the network using FTP protocol (defined by RFC 959 and later additions) takes roots in year 1980, when the first RFC for FTP protocol was published. FTP provides functions to upload, download and delete files, create and delete directories, read directory contents. While FTP is very popular, it has certain disadvantages that make it harder to use. The major drawbacks are lack of the uniform format for directory listing (this problem has been partially solved by introducing MLST command, but it\u2019s not supported by some servers) and presence of the secondary connection (DATA connection). Security in FTP is provided by employing SSL/TLS protocol for channel encryption as defined in RFC 2228. The secured version of FTP is called FTPS.
In UNIX systems another security standard has grown. It was SSH family of protocols. The primary function of SSH was to secure remote shell access to UNIX systems. Later SSH was extended with file transfer protocol \u2013 first SCP (in SSH 1.x), then SFTP (in SSH2). Version 1 of the SSH protocol is outdated, insecure and generally not recommended for use. Consequently SCP is not used anymore and SFTP gains popularity day by day.
\u201cSFTP\u201d abbreviation is often mistakenly used to specify some kind of Secure FTP, by which people most often mean FTPS. Another (similar) mistake is that SFTP is thought to be some kind of FTP over SSL. In fact SFTP is an abbreviation of \u201cSSH File Transfer Protocol\u201d. This is not FTP over SSL and not FTP over SSH (which is also technically possible, but very rare).
SFTP is a binary protocol, the latest version of which is standardized in RFC 4253. All commands (requests) are packed to binary messages and sent to the server, which replies with binary reply packets. In later versions SFTP has been extended to provide not just file upload/download operations, but also some file-system operations, such as file lock, symbolic link creation etc.
Both FTPS and SFTP use a combination of asymmetric algorithm (RSA, DSA), symmetric algorithm (DES/3DES, AES, Twhofish etc.) and a key-exchange algorithm. For authentication FTPS (or, to be more precise, SSL/TLS protocol under FTP) uses X.509 certificates, while SFTP (SSH protocol) uses SSH keys.
X.509 certificates include the public key and certain information about the certificate owner. This information lets the other side verify the integrity of the certificate itself and authenticity of the certificate owner. Verification can be done both by computer and to some extent by the human. X.509 certificate has an associated private key, which is usually stored separately from the certificate for security reasons.
SSH key contains only a public key (the associated private key is stored separately). It doesn\u2019t contain any information about the owner of the key. Neither it contains information that lets one reliably validate the integrity and authenticity. Some SSH software implementations use X.509 certificates for authentication, but in fact they don\u2019t validate the whole certificate chain \u2013 only the public key is used (which makes such authentication incomplete and similar to SSH key authentication).
Here\u2019s the brief list of Pros and Cons of the two protocols:
FTPS
Pros:
* Widely known and used
* The communication can be read and understood by the human
* Provides services for server-to-server file transfer
* SSL/TLS has good authentication mechanisms (X.509 certificate features)
* FTP and SSL/TLS support is built into many internet communication frameworks.
Cons:
* Doesn\u2019t have a uniform directory listing format
* Requires a secondary DATA channel, which makes it hard to use behind the firewalls
* Doesn\u2019t define a standard for file name character sets (encodings)
* Not all FTP servers support SSL/TLS
* Doesn\u2019t have a standard way to get and change file and directory attributes
SFTP
Pros:
* Has good standards background which strictly defines most (if not all) aspects of operations
* Has only one connection (no need for DATA connection)
* The connection is always secured
* The directory listing is uniform and machine-readable
* The protocol includes operations for permission and attribute manipulation, file locking and more functionality
Cons:
* The communication is binary and can\u2019t be logged \u201cas is\u201d for human reading
* SSH keys are harder to manage and validate
* The standards define certain things as optional or recommended, which leads to certain compatibility problems between different software titles from different vendors.
* No server-to-server copy and recursive directory removal operations
* No built-in SSH/SFTP support in VCL and .NET frameworks
What to choose
As usually, the answer depends on what your goals and requirements are. In general, SFTP is technologically superior to FTPS. Of course, it\u2019s a good idea to implement support for both protocols, but they are different in concepts, in supported commands and in many other things.
It\u2019s a good idea to use FTPS when you have a server that needs to be accessed from personal devices (smartphones, PDAs etc.) or from some specific operating systems which have FTP support but don\u2019t have SSH / SFTP clients. If you are building a custom security solution, SFTP is probably the better option.
As for the client side, the requirements are defined by the server(s) that you plan to connect to. When connecting to Internet servers, SFTP is more popular because it\u2019s supported by Linux and UNIX servers by default.
For private host-to-host transfer you can use both SFTP and FTPS. For FTPS you would need to search for a free FTPS client and server software or purchase a license for commercial one. For SFTP support you can install OpenSSH package, which provides free client and server software. For commercial use we recommend Bitvise SSH server.
Please refer to https://www.eldos.com/security/articles/4672.php?page=all
Thursday, July 10, 2014
Understanding Key Differences Between FTP, FTPS and SFTP
Perhaps the most common protocols used in file transfer today are FTP, FTPS and SFTP. While the acronyms for these protocols are similar, there are some key differences among them, in particular how data are exchanged, the level of security provided and firewall considerations. Learning these key differences can help you when choosing a file transfer protocol or troubleshooting common connection issues.
FTP
The FTP (File Transfer Protocol) protocol has been around for quite some time. It was first proposed in RFC 114 over 40 years ago and eventually evolved into RFC 959 which is the standard that FTP clients and servers follow today.
Data Exchange
The FTP protocol exchanges data using two separate channels known as the command channel and data channel.
The command channel typically runs on server port 21 and is responsible for accepting client connections and handling the exchange of simple commands between an FTP client and server. The USER and PASS commands used for authenticating an FTP user are examples of commands that are exchanged on the command channel. The command channel remains open until the client sends the QUIT command to disconnect, or the server forcibly disconnects the client due to inactivity or other reason.
The data channel, runs using on-demand temporary ports listening on the server (passive mode) or on the client (active mode) and is responsible for exchanging data in the form of directory listings and file transfers. The LIST, STOR and RETR commands used for getting a server directory listing, uploading a file and downloading a file are examples of commands (sent using the command channel) that open a data channel. Unlike the command channel which remains open during the entire FTP session, the data channel is closed once the transfer of data is complete. In order to handle concurrent file transfers or directory listings a range of data channel ports must be used.
Security
Using FTP both the command and data channels are unencrypted. Any data sent over these channels can be intercepted and read.
Firewall
Server - Allow inbound connections on port 21. Define passive port range (e.g. 2000-2500) for file transfers and directory listings and allow inbound connections on passive port range. Consult your server documentation for instructions on how to set a passive port range.
Client - Allow outbound connections to port 21 and passive port range defined by server.
FTPS
When the FTP protocol was initially drafted security was not a concern. Since then many things have changed and sending data over any public network without encryption is considered very risky and in some cases prohibited. In order to address this issue a set of security extensions to the original FTP protocol were proposed in RFC 2228 that protect FTP data as it travels over the network using SSL encryption.
Data Exchange
See FTP
Security
Secure variants of FTP include FTPS Implicit SSL and FTPS Explicit SSL. Both utilize SSL encryption.
FTPS Implicit SSL
In implicit SSL mode a required SSL session is established between client and server before any data is exchanged. As it's name suggests, the use of SSL is implied and any connection attempt made by a client without using SSL are refused by the server. FTPS implicit SSL services generally run on port 990. Although still in use today, FTPS Implicit SSL is considered by many to be obsolete in favor of FTPS Explicit SSL.
FTPS Explicit SSL
In explicit SSL mode the client and server negotiate the level of protection used. This is very useful in that the server can support both unencrypted FTP and encrypted FTPS sessions on a single port. In an explicit SSL session the client first establishes an unencrypted connection to the FTP service. Prior to sending user credentials, the client requests that the server switch the command channel to an SSL encrypted channel by sending the AUTH TLS or AUTH SSL command. Upon successful setup of the SSL channel the client then sends user credentials to the FTP server. These credentials along with any other commands sent to server during the FTP session are automatically encrypted by the SSL channel. Similar to the way in which the command channel may be protected, the level of protection used on the data channel is negotiated between the client and server using the PROT command.
Firewall
Server - Allow inbound connections on port 21 and / or 990. Define passive port range (e.g. 2000-2500) for file transfers and directory listings and allow inbound connections on passive port range. Consult your server documentation for instructions on how to set a passive port range.
Client - Allow outbound connections to port 21 and passive port range defined by server.
SFTP
SFTP is often confused with FTPS and vice-versa even though these protocols share nothing in common except their ability to securely transfer files. SFTP is actually based on the SSH (Secure Shell) protocol which is best known for it's use in providing secure access to shell accounts on remote servers.
Data Exchange
Unlike FTP/S, SFTP does not utilize separate command and data channels. Both data and commands are transferred in specially formatted packets via a single connection.
Security
All data sent between client and server is encrypted using an agreed upon encryption cipher.
Firewall
Server - Allow inbound connections on port 22.
Client - Allow outbound connections to port 22.
Share files via FTP, SFTP, or FTPS
JSCAPE MFT Server allows you to share files via FTP, SFTP, FTPS, and other file transfer protocols. This Managed File Transfer server runs on all popular platforms (including Windows, Linux, Unix, AIX, Solaris, and Mac OS/X) and now supports OpenID and SAML Single Sign On. Download a free evaluation edition now.
please refer to http://www.jscape.com/blog/bid/75602/Understanding-Key-Differences-Between-FTP-FTPS-and-SFTP
FTP
The FTP (File Transfer Protocol) protocol has been around for quite some time. It was first proposed in RFC 114 over 40 years ago and eventually evolved into RFC 959 which is the standard that FTP clients and servers follow today.
Data Exchange
The FTP protocol exchanges data using two separate channels known as the command channel and data channel.
The command channel typically runs on server port 21 and is responsible for accepting client connections and handling the exchange of simple commands between an FTP client and server. The USER and PASS commands used for authenticating an FTP user are examples of commands that are exchanged on the command channel. The command channel remains open until the client sends the QUIT command to disconnect, or the server forcibly disconnects the client due to inactivity or other reason.
The data channel, runs using on-demand temporary ports listening on the server (passive mode) or on the client (active mode) and is responsible for exchanging data in the form of directory listings and file transfers. The LIST, STOR and RETR commands used for getting a server directory listing, uploading a file and downloading a file are examples of commands (sent using the command channel) that open a data channel. Unlike the command channel which remains open during the entire FTP session, the data channel is closed once the transfer of data is complete. In order to handle concurrent file transfers or directory listings a range of data channel ports must be used.
Security
Using FTP both the command and data channels are unencrypted. Any data sent over these channels can be intercepted and read.
Firewall
Server - Allow inbound connections on port 21. Define passive port range (e.g. 2000-2500) for file transfers and directory listings and allow inbound connections on passive port range. Consult your server documentation for instructions on how to set a passive port range.
Client - Allow outbound connections to port 21 and passive port range defined by server.
FTPS
When the FTP protocol was initially drafted security was not a concern. Since then many things have changed and sending data over any public network without encryption is considered very risky and in some cases prohibited. In order to address this issue a set of security extensions to the original FTP protocol were proposed in RFC 2228 that protect FTP data as it travels over the network using SSL encryption.
Data Exchange
See FTP
Security
Secure variants of FTP include FTPS Implicit SSL and FTPS Explicit SSL. Both utilize SSL encryption.
FTPS Implicit SSL
In implicit SSL mode a required SSL session is established between client and server before any data is exchanged. As it's name suggests, the use of SSL is implied and any connection attempt made by a client without using SSL are refused by the server. FTPS implicit SSL services generally run on port 990. Although still in use today, FTPS Implicit SSL is considered by many to be obsolete in favor of FTPS Explicit SSL.
FTPS Explicit SSL
In explicit SSL mode the client and server negotiate the level of protection used. This is very useful in that the server can support both unencrypted FTP and encrypted FTPS sessions on a single port. In an explicit SSL session the client first establishes an unencrypted connection to the FTP service. Prior to sending user credentials, the client requests that the server switch the command channel to an SSL encrypted channel by sending the AUTH TLS or AUTH SSL command. Upon successful setup of the SSL channel the client then sends user credentials to the FTP server. These credentials along with any other commands sent to server during the FTP session are automatically encrypted by the SSL channel. Similar to the way in which the command channel may be protected, the level of protection used on the data channel is negotiated between the client and server using the PROT command.
Firewall
Server - Allow inbound connections on port 21 and / or 990. Define passive port range (e.g. 2000-2500) for file transfers and directory listings and allow inbound connections on passive port range. Consult your server documentation for instructions on how to set a passive port range.
Client - Allow outbound connections to port 21 and passive port range defined by server.
SFTP
SFTP is often confused with FTPS and vice-versa even though these protocols share nothing in common except their ability to securely transfer files. SFTP is actually based on the SSH (Secure Shell) protocol which is best known for it's use in providing secure access to shell accounts on remote servers.
Data Exchange
Unlike FTP/S, SFTP does not utilize separate command and data channels. Both data and commands are transferred in specially formatted packets via a single connection.
Security
All data sent between client and server is encrypted using an agreed upon encryption cipher.
Firewall
Server - Allow inbound connections on port 22.
Client - Allow outbound connections to port 22.
Share files via FTP, SFTP, or FTPS
JSCAPE MFT Server allows you to share files via FTP, SFTP, FTPS, and other file transfer protocols. This Managed File Transfer server runs on all popular platforms (including Windows, Linux, Unix, AIX, Solaris, and Mac OS/X) and now supports OpenID and SAML Single Sign On. Download a free evaluation edition now.
please refer to http://www.jscape.com/blog/bid/75602/Understanding-Key-Differences-Between-FTP-FTPS-and-SFTP
Subscribe to:
Posts (Atom)