Re: Secure file transfers

[Valdis Kletnieks <Valdis.Kletnieks () VT EDU>]

On Mon, 07 May 2007 08:54:10 EDT, Theresa M Rowe said:
> We've been getting a push back from some vendors that "standard FTP" is
> secure enough.  We've been saying it isn't good enough.

Just tell those vendors: We have decided to not do business with vendors who
have insufficient security clue to understand why "cleartext userid/password"
is a Bad Idea.  If said vendor doesn't have enough clue to understand *that*,
they are clueless enough that they are *likely* to lose your sensitive data
once it arrives at their system.

Or just ask them if they're willing to indemnify you to 100% of all potential
damages, direct *and* incidental, if credentials and/or data is sniffed or
otherwise compromised in transit.

You *may* encounter the occasional vendor who understands that on most modern
nonshared media (cat-5 cables and switches, fiberoptics), mounting a sniffing
attack is a bit more challenging than it was in the shared-media (thickwire
and thinwire Ethernet) era.  On the other hand, any vendor who is *that* clued
but still resistant to use the belt-and-suspenders of using SSL, VPN, or SSH
encapsulation should be avoided just because they're being intentionally
stubborn, with possibly disastrous results.

One other, non-directly security reason to encapsulate it in a crypto stream:

The basic TCP/IP headers only provide a CRC-16 checksum, which was "Good Enough"
for small transfers.  In an era of gigabyte transfers, the chances increase that
a data corruption will fail to be detected by the relatively weak CRC-16.  So
it is imperative for data integrity that you either use an out-of-band method
to send a stronger verification (MD-5 or SHA-n) *and check it*, or use a
strong crypto that will basically automagically detect an error and either
reset or retry, ensuring that bad data isn't transferred...

Attachment: _bin
Description: