On Fri, 28 May 2004 00:36:42 +0100 (BST)
Pete Turnbull <pete_at_dunnington.u-net.com> wrote:
> I recently had a discussion with our security advisor at work, about
> FTP being replaced by HTTP and SCP.
[...]
> For example, FTP understands the
> difference between a unix-style "stream of bytes" file, and a
> structured one such as might be found under VMS (or any of several
> other OSs) -- and can deal with the difference.
You are refering to "binary" versus "ascii" mode in ftp?
http can do the same. It is possible to specify encodings, charsets, ...
in the http headers. This way a http client is able to e.g. transcode
charsets of textfiles during reception.
scp allways copys files verbatim. (AFAIK)
The problem may be that ftp uses a "strange" way to handle connections.
You have one TCP stream for control and an other for data. Depending on
active or passive ftp the data connection is opened from the server to
the client or vice versa. (IIRC) If you have to admin a firewall for a
ftp server this can be a nightmare and possibly result in weaker
firewall rules. http uses only a TCP connection from the client to the
server on port 80. So you can secure a http server quite good by "allow
everything to server-IP port 80; allow everything from server-IP port
80; deny everything else" (or "allow everything to server-IP port 80
keep state; deny everything else") quite easyly.
An other issue may be that ftp allways transferes clear text passwords.
http does the same, but you can use https (http with SSL/TLS
encryption). There is a SSL variant of ftp, but I know of no client or
server that supports it. All http clients support https. You can do SSL
client certificate based authentification with most https clients and
servers as well...
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Received on Fri May 28 2004 - 03:39:07 BST