Is there an industry standard for data encryption via FTP? We have
multiple sites with whom we transfer files but don't want to have to
install a client side app on their servers...
Thanks,
Chris
Printable View
Is there an industry standard for data encryption via FTP? We have
multiple sites with whom we transfer files but don't want to have to
install a client side app on their servers...
Thanks,
Chris
"chrislewis21@gmail.com" <chrislewis21@gmail.com> writes:[color=blue]
>Is there an industry standard for data encryption via FTP? We have
>multiple sites with whom we transfer files but don't want to have to
>install a client side app on their servers...[/color]
Sure, there's SFTP and FTPS, but most likely, you'll have to install
server and client apps on both sides to take advantage of either.
(SFTP isn't quite FTP, its file transfer over ssh, but it'll function
like that well enough).
[email]chrislewis21@gmail.com[/email] wrote:[color=blue]
> Is there an industry standard for data encryption via FTP? We have
> multiple sites with whom we transfer files but don't want to have to
> install a client side app on their servers...
>
> Thanks,
> Chris
>[/color]
If it must be FTP, then you need to encrypt the file before sending it.
And of course the remote site must have a compatible decrypting program.
We use GNU Privacy Guard for such file transfers.
[url]http://www.gnupg.org/[/url]
RFC4217 "Securing FTP with TLS" could be considered a standard for data
encryption for FTP.
There are some implementations available, but not necessarily for all
platforms.
Encrypting/Decrypting outside of the transfer is asking for someone to skip
the step, either accidentally, or due to being in a hurry and feeling that
the extra step takes too much time that is not "necessary". Of course if
you don't want to install an application on all the sites involved, this is
your only choice.
RFC4217 also addresses the problem of protecting the users' password during
the login process.
"Chuck" <skilover_nospam@bluebottle.com> wrote in message
news:cYsVh.1448$Qp.1201@trnddc07...[color=blue]
> [email]chrislewis21@gmail.com[/email] wrote:[color=green]
>> Is there an industry standard for data encryption via FTP? We have
>> multiple sites with whom we transfer files but don't want to have to
>> install a client side app on their servers...
>>
>> Thanks,
>> Chris
>>[/color]
>
> If it must be FTP, then you need to encrypt the file before sending it.
> And of course the remote site must have a compatible decrypting program.
>
> We use GNU Privacy Guard for such file transfers.
>
> [url]http://www.gnupg.org/[/url][/color]
Richard Whalen wrote:[color=blue]
> RFC4217 "Securing FTP with TLS" could be considered a standard for data
> encryption for FTP.
> There are some implementations available, but not necessarily for all
> platforms.
>
> Encrypting/Decrypting outside of the transfer is asking for someone to skip
> the step, either accidentally, or due to being in a hurry and feeling that
> the extra step takes too much time that is not "necessary". Of course if
> you don't want to install an application on all the sites involved, this is
> your only choice.
>
> RFC4217 also addresses the problem of protecting the users' password during
> the login process.
>
>
> "Chuck" <skilover_nospam@bluebottle.com> wrote in message
> news:cYsVh.1448$Qp.1201@trnddc07...[color=green]
>> [email]chrislewis21@gmail.com[/email] wrote:[color=darkred]
>>> Is there an industry standard for data encryption via FTP? We have
>>> multiple sites with whom we transfer files but don't want to have to
>>> install a client side app on their servers...
>>>
>>> Thanks,
>>> Chris
>>>[/color]
>> If it must be FTP, then you need to encrypt the file before sending it.
>> And of course the remote site must have a compatible decrypting program.
>>
>> We use GNU Privacy Guard for such file transfers.
>>
>> [url]http://www.gnupg.org/[/url][/color]
>
>[/color]
It still requires changes on the remote end doesn't it? They need to add
support TLS.
>>>>> "Chuck" == Chuck <skilover_nospam@bluebottle.com> writes:
Chuck> Richard Whalen wrote:[color=blue][color=green]
>> RFC4217 "Securing FTP with TLS" could be considered a standard for
>> data encryption for FTP. There are some implementations available,
>> but not necessarily for all platforms.
>>
>> Encrypting/Decrypting outside of the transfer is asking for someone
>> to skip the step, either accidentally, or due to being in a hurry
>> and feeling that the extra step takes too much time that is not
>> "necessary". Of course if you don't want to install an application
>> on all the sites involved, this is your only choice.
>>
>> RFC4217 also addresses the problem of protecting the users'
>> password during the login process.
>>
>>
>> "Chuck" <skilover_nospam@bluebottle.com> wrote in message
>> news:cYsVh.1448$Qp.1201@trnddc07...[color=darkred]
>>> [email]chrislewis21@gmail.com[/email] wrote:
>>>> Is there an industry standard for data encryption via FTP? We
>>>> have multiple sites with whom we transfer files but don't want to
>>>> have to install a client side app on their servers...
>>>>
>>>> Thanks, Chris
>>>>
>>> If it must be FTP, then you need to encrypt the file before
>>> sending it. And of course the remote site must have a compatible
>>> decrypting program.
>>>
>>> We use GNU Privacy Guard for such file transfers.
>>>
>>> [url]http://www.gnupg.org/[/url][/color]
>>[/color][/color]
Chuck> It still requires changes on the remote end doesn't it? They
Chuck> need to add support TLS.
I'm not sure I understand your original question. If your existing FTP
software does not support encryption, and you don't have any external
encryption software available (e.g. gnupg), *and* you don't want to
install any new software -- how do you expect to solve your problem?
WebDAV over https is a great alternative for this sort of thing over FTP,
since most browsers already support it.
--
Richard Silverman
[email]res@qoxp.net[/email]
On 17 Apr, 19:05, "chrislewi...@gmail.com" <chrislewi...@gmail.com>
wrote:[color=blue]
> Is there an industry standard for data encryption via FTP? We have
> multiple sites with whom we transfer files but don't want to have to
> install a client side app on their servers...
>
> Thanks,
> Chris[/color]
The answer is "No". There are numerous different techniques and
technologies with the word "ftp" in them, but they diverge into
several distinct technologies.
ftps are tools that try to use the FTP protocol, but encryption
encapsulated in some way. There have been several: none have become
popular.
sftp is basically an FTP like interface stapled on top of SSH and SCP.
While convenient and part of OpenSSH and ssh.com's product, it lacks a
lot of basic features of FTP, such as well managed anonymous access,
the ability to force particular users and groups for upload, and a
working chroot cage at least for OpenSSH.
Instead of all these, I urge you to take a good look at WebDAV over
HTTPS. The interfaces of Internet Explorer and many other browsers are
cut&paste, it has good command line tools like lftp, and it easily
supports multiple distinct means of authentication by using standard
Apache with SSL as the server. And the clients are built into every
major operatng system.
On 2007-04-20, Nico <nkadel@gmail.com> wrote:
[...][color=blue]
> sftp is basically an FTP like interface stapled on top of SSH and SCP.[/color]
[...]
No, it's not, they're distinct protocols which have almost nothing
in common other than starting with the letter "s". Normally they use
SSH as a transport in different ways, too.
OpenSSH's sftp certainly doesn't use scp in any way. I'm not aware of
any implementation's "sftp" program that uses scp.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
On 20 May, 22:41, Darren Tucker <dtuc...@gate.dtucker.net> wrote:[color=blue]
> On 2007-04-20, Nico <nka...@gmail.com> wrote:
> [...]> sftp is basically an FTP like interface stapled on top of SSH and SCP.
>
> [...]
>
> No, it's not, they're distinct protocols which have almost nothing
> in common other than starting with the letter "s". Normally they use
> SSH as a transport in different ways, too.
>
> OpenSSH's sftp certainly doesn't use scp in any way. I'm not aware of
> any implementation's "sftp" program that uses scp.[/color]
Thank you for the correction. But it certainly suffered from some of
the same limitations as scp, or has the transfer of symlinks as
symlinks been corrected yet? And yes, I'm a brokern record about this,
but neither ssh nor scp nor sftp have proper chroot cages for their
server's home directories to keep clients out of the rest of the
operating systems system files.
Most of the other so-called "sftp" services include that chroot
business as a matter of course. As much as I like SSH for its
usefulness and shell access, the difference between sftp and scp was
aways..... small. Has the funtionality changed in any noticeable way?