Board index » delphi » FTP vs Http+Sockets

FTP vs Http+Sockets

Hello All:

    I have built a client app which allows our customers to retrieve minor
updates and files off of our web server. The component works well so far as
tested.

    Somebody suggested that I switch to using http with sockets instead of
using FTP.

    What advantages would http via sockets have for file transfers ??? Would
this work better with proxy servers, etc ???

    Where could I find examples of how this is done with Indy ???

Thank you.

Neil Huhta

 

Re:FTP vs Http+Sockets


Quote
>    What advantages would http via sockets have for file transfers ??? Would
>this work better with proxy servers, etc ???

HTTP and FTP both should work well with proxies.
Maybe some network configurations will more easily allow HTTP than FTP
access, but again both protocols are pretty common.
In case of security, I guess that HTTPS is more common than FTPS, so
that might be an advantage of HTTP - if you need it.
I guess HTTP is used more often for the updating task because often
you would have a web server for the product anyway and this web server
can therefore additionally work as the update-server. Plus, you might
want to use CGIs or similiar to check for updates.
But then again - why break a working solution without reason, FTP
works just as well for the task and if there's no need to change it
(now or in the foreseeable future) you might save yourself the work
and trouble and just leave it with FTP.

Andy

Re:FTP vs Http+Sockets


One of the problems (from the security point of view) with ftp is the
inbound data connection.
If you have to use ftp, passive mode is recommended, but you still have to
allow the inbound data connection.
The HTTP protocol is  simply more firewall-friendly than ftp, as there is no
need for the inbound connection.

Danny
---

"Huhtaman" <nhu...@digital.net> schreef in bericht
news:3e73b383$1@newsgroups.borland.com...

Quote
> Hello All:

>     I have built a client app which allows our customers to retrieve minor
> updates and files off of our web server. The component works well so far
as
> tested.

>     Somebody suggested that I switch to using http with sockets instead of
> using FTP.

>     What advantages would http via sockets have for file transfers ???
Would
> this work better with proxy servers, etc ???

>     Where could I find examples of how this is done with Indy ???

> Thank you.

> Neil Huhta

Re:FTP vs Http+Sockets


I'm not sure that's accurate.  With PASV you reverse the direction of the
data session establishment so that the data channel is initiated from the
client.

Normal FTP sends a PORT command with paramenters that lets the server know
what IP address and socket to open the data channel to.  With PASV, the
server performs a passive open then responds with the address and port
details for the client to establish the data connection to.  Once connected,
the server pushes the file back to the client.

Of course you still have the issues surrounding cleartext usernames and
passwords, but with passive support you only have to deal with client >
server connections and not any incomming ones.  On the subject of HTTP
usernames and passwords, unless you're going to go to the trouble of using
HTTPS, HTTP basic authentication is just obfuscation not encryption anyway.

If it works fine, I wouldn't change it unless you need HTTPS or some other
feature that FTP does not support.

Quote
"Danny Heijl" <danny.he...@cevi.be> wrote in message

news:3e74a563@newsgroups.borland.com...
Quote
> One of the problems (from the security point of view) with ftp is the
> inbound data connection.
> If you have to use ftp, passive mode is recommended, but you still have to
> allow the inbound data connection.
> The HTTP protocol is  simply more firewall-friendly than ftp, as there is
no
> need for the inbound connection.

> Danny

Re:FTP vs Http+Sockets


On Mon, 17 Mar 2003 07:42:54 +1200, "Simon Devlin"

Quote
<simon.dev...@kremlin-computing.com> wrote:
>I'm not sure that's accurate.  With PASV you reverse the direction of the
>data session establishment so that the data channel is initiated from the
>client.

>Normal FTP sends a PORT command with paramenters that lets the server know
>what IP address and socket to open the data channel to.  With PASV, the
>server performs a passive open then responds with the address and port
>details for the client to establish the data connection to.  Once connected,
>the server pushes the file back to the client.

>Of course you still have the issues surrounding cleartext usernames and
>passwords, but with passive support you only have to deal with client >
>server connections and not any incomming ones.

There are some potential security problems such as connection
laundering, a FTP bounce attack, and connection theft.  Usually, good
FTP servers will require that data connections be used only for the
computer on the control connection.    It's not an ideal solution and
it does have a side effect in that it will break site to site file
transfers but sometimes, security does have its price.

Quote
> On the subject of HTTP
>usernames and passwords, unless you're going to go to the trouble of using
>HTTPS, HTTP basic authentication is just obfuscation not encryption anyway.

>If it works fine, I wouldn't change it unless you need HTTPS or some other
>feature that FTP does not support.

Actually, there is a version of FTP that supports SSL or TLS (see:
http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-10.txt).

A lot of servers still don't support this and Indy 9.0 doesn't support
it.    Indy 10 does support TLS with FTP.  There's still some work to
do to make sure it can work properly with OpenSSL.

J. Peter Mugaas - Chairperson, Distribution Team, Indy Pit Crew
Internet Direct (Indy) Website - http://www.nevrona.com/Indy
Personal Home Page - http://www.wvnet.edu/~oma00215
If I want to do business with you, I will contact you.  Otherwise, do not contact me.

Re:FTP vs Http+Sockets


"Simon Devlin" <simon.dev...@kremlin-computing.com> schreef in bericht
news:3e74d2c9@newsgroups.borland.com...

Quote
> I'm not sure that's accurate.  With PASV you reverse the direction of the
> data session establishment so that the data channel is initiated from the
> client.

I am sorry, you are right.

Danny
---

Re:FTP vs Http+Sockets


"J Peter Mugaas" <oma00...@mail.wvnet.edu> wrote in message
news:md1a7voq8rknked0d72eufflu8102ljoq8@4ax.com...

Quote
> There are some potential security problems such as connection
> laundering, a FTP bounce attack, and connection theft.  Usually, good
> FTP servers will require that data connections be used only for the
> computer on the control connection.    It's not an ideal solution and
> it does have a side effect in that it will break site to site file
> transfers but sometimes, security does have its price.

I agree 100% with all of the above, but none of the points are a large
enough problem that *I* would go to the trouble of changing a perfectly good
FTP solution to a HTTP(s) based one.  Most of the stuff you're refering to
is fairly esoteric (but worth reading up on for developers thinking of
including server "processes" in their own code -
http://www.cert.org/tech_tips/ftp_port_attacks.html)

Quote
> Actually, there is a version of FTP that supports SSL or TLS (see:
> http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-10.txt).

> A lot of servers still don't support this and Indy 9.0 doesn't support
> it.    Indy 10 does support TLS with FTP.  There's still some work to
> do to make sure it can work properly with OpenSSL.

I've come across a couple that do (Serve-U is one that springs to mind) but
as you say, most don't.  For deployment I couldn't really recommend FTP/TLS
at the present time.  The FTP server deployed with IIS 5.0 doesn't even
support PASV for petes (who ever he is) sake - so as for TLS support :-(

Simon

Re:FTP vs Http+Sockets


On Mon, 17 Mar 2003 23:48:13 +1200, "Simon Devlin"

Quote
<simon.dev...@kremlin-computing.com> wrote:
>[snip]
>I agree 100% with all of the above, but none of the points are a large
>enough problem that *I* would go to the trouble of changing a perfectly good
>FTP solution to a HTTP(s) based one.

I am inclined to agree but the security issues in FTP are things to be
considered.  In addition, FTP is not too friendly if the server is
behind a firewall because then a whole range of ports has to opened on
the firewall.

Quote
> [snip]
>I've come across a couple that do (Serve-U is one that springs to mind) but
>as you say, most don't.  

Most don't but I suspect that as time goes on, TLS FTP will grow in
demand.  Already, you have several commercial servers supporting TLS
such as:

GlobalScape Secure FTP Server (http://www.globalscape.com)
WS_FTP Server (http://www.ipswitch.com)
Surge FTP Server (http://netwinsite.com/surgeftp/)
Raiden FTP Server (http://www.raidenftpd.com/en/)
A few Unix FTP Servers (I've seen some source-code)

I suspect there is a number of them.  One thing we are working on with
Indy 10 is adding TLS support to the FTP Server.

There are currently quite a number of FTP clients supporting TLS
including

Cute FTP Pro (http://www.globalscape.com)
WS-FTP Pro 7.6 (http://www.ipswitch.com)
Smart FTP (http://www.smartftp.com/)
FileZilla (http://filezilla.sourceforge.net/)

Indy 10 already supports TLS FTP and the SecureBlackbox vendor
(http://www.secureblackbox.com/) today announced Indy 9.0 TLS FTP
support in that product (note that I and the Indy Pit Crew can not
vouch for it's merit).

Quote
>For deployment I couldn't really recommend FTP/TLS
>at the present time.  The FTP server deployed with IIS 5.0 doesn't even
>support PASV for petes (who ever he is) sake - so as for TLS support :-(

Actually, I think Microsoft IIS 4.0 and 5.0 support PASV.   The FTP
console client in Windows 95, 98, Me, and 2000 still doesn't support
PASV (and I wish it would).  There are still a few old servers that
don't support PASV and I've seen a few.

I'm not completely disagreeing with you about the merits of FTP
because I agree for the most part (I happen to maintain the FTP client
code in Indy 10).  I'm trying to give a balanced perspective on
things.
J. Peter Mugaas - Chairperson, Distribution Team, Indy Pit Crew
Internet Direct (Indy) Website - http://www.nevrona.com/Indy
Personal Home Page - http://www.wvnet.edu/~oma00215
If I want to do business with you, I will contact you.  Otherwise, do not contact me.

Other Threads