Perhaps the FTP server you are attempting to upload to has a max file size
configured?
-----Original Message-----
From: Zhu, Sonia [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 16, 2000 9:59 AM
To: [EMAIL PROTECTED]
Subject: Re: Secure FTP using SSL
Has anybody met this case: When using FTP "put" file to the server, there is
a limitation for the file size, around 250 X 512 byte, if the file is bigger
than that, FTP will hang up, and then exit with error:
[Aborting data transfer]CONNCLOSED, Connection closed
ABOR
<451 Transfer aborted due to receive error. File is deleted.
FTP>
Any idea?
Thanks,
Sonia Zhu
Information Systems Tel: (604)420-6611 ext 413
Dairyland Foods Division Fax: (604)444-7203
-----Original Message-----
From: Rosansky, Jay [SMTP:[EMAIL PROTECTED]]
Sent: Friday, June 16, 2000 6:09 AM
To: [EMAIL PROTECTED]
Subject: Re: Secure FTP using SSL
> -----Original Message-----
> From: Tzeweng Foong [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 15, 2000 9:14 PM
> To: [EMAIL PROTECTED]%internet
> Subject: Re: Secure FTP using SSL
>
>
> > -----Original Message-----
> > From: Rosansky, Jay [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, 16 June 2000 5:16
> > To: [EMAIL PROTECTED]
> > Subject: Re: Secure FTP using SSL
> >
> >
> > Jonathan,
> > Yes, the major difference is that the user ID and password
> > are sent in the clear in plain ftp. But, this is not an
> > issue because someone might read your data. (Can't without
> > the recipient's private key.) And, it is not an issue because
> > someone might send in a bogus message claiming to be you.
> > (Can't because they can't forge your digital signature.)
> >
> > The only potential problem that I known of with using ftp and
> > PGP happens if you use the ftp server to upload files to it.
> > If someone stole the user ID and password they could harass
> > you by uploading very large files to the server. This
> > problem does not happen if the ftp server is only used for
> downloads.
>
> You seem to have missed the potential for someone to take your
> files from the FTP server you are downloading data from.. also
> deleting the files waiting to be downloaded by you.
>
In this type set up the ftp server should be configured not to allow
the ftp client to delete the file. (Easily done with file permissions or
ftp server configuration.) The file should be removed by a process on the
server at some appropriate time. Also, since the file is encrypted it
doesn't matter who downloads it.
> There is also a new ftp client and server (cannot remember exactly
> what it is called, maybe sFTP ? ) that encrupts the user id and
> password (but not the session..) this would make it fairly safe
> to use PGP to encrypt the file.
>
> > The one problem with FTP/s (and why we ended up not using it)
> > is it is not proxy firewall friendly. In order to use that
> > program through a firewall it is either necessary to poke
> > huge holes in the firewall or get FTP/s proxy software for
> > the firewall. I don't know if this software exists yet.
> > Another approach would be to setup your ftp/s client on a box
> > outside your firewall and use some other method to get it
> > through. Not a very appealing idea.
> >
> > Good luck,
> > Jay Rosansky
> > ACS-GSG
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]%internet
> > > [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, June 15, 2000 2:16 PM
> > > To: Rosansky, Jay
> > > Cc: [EMAIL PROTECTED]%internet
> > > Subject: Re: Secure FTP using SSL
> > >
> > >
> > > Jay,
> > > Thank you very much for the information. I do have a
> > > follow-up questions.
> > > If someone is using PGP(or some other file encryption tool)
> > > to encrypt a file
> > > that is sent using FTP versus FTP using SSL, what are the
> > > major advantages and
> > > disadvantages? Is it that using FTP and SSL will protect the
> > > user id and
> > > password being passed? Where "standard" FTP would pass that
> > > in the "open"?
> > >
> > > Thanks
> > > Jonathan Showalter
> > >
> > >
> > >
> > >
> > > |--------+------------------------->
> > > | | "Rosansky, Jay"|
> > > | | <Jay.Rosansky@H|
> > > | | Q.DOE.GOV> |
> > > | | |
> > > | | 06/15/2000 |
> > > | | 10:51 AM |
> > > | | Please respond |
> > > | | to "Rosansky, |
> > > | | Jay" |
> > > | | |
> > > |--------+------------------------->
> > >
> > > >-------------------------------------------------------------
> > > ---------------|
> > > |
> > > |
> > > | To: [EMAIL PROTECTED]
> > > |
> > > | cc: (bcc: Jonathan Showalter/MutualOMA)
> > > |
> > > | Subject: Re: Secure FTP using SSL
> > > |
> > >
> > > >-------------------------------------------------------------
> > > ---------------|
> > >
> > >
> > >
> > >
> > >
> > >
> > > I think you have a few misconceptions.
> > >
> > > First, packets are sometimes "destroyed" or dropped in the
> > > normal functioning of
> > > any tcp/ip based network. That is why TCP numbers all of the
> > > packets it sends
> > > and automatically retransmits ones not acknowledged
> > > (conceptually similar to EDI
> > > 997s). FTP, adds another level of data corruption checking.
> > >
> > > Because information sent using standard FTP is not encrypted,
> > > including your
> > > user ID and password, it is possible for someone to see this
> > > information if they
> > > can gain access to a system along the actual path that your
> > > data takes. (not
> > > easy). Also, if they get your user ID and password they
> can spoof a
> > > transmission from you and send bogus data.
> > >
> > > SSL solves these problems using encryption algorithms RSA
> > > public key encryption
> > > for authentication and DES (or some other symmetric key
> > > encryption algorithm) to
> > > encrypt your data.
> > >
> > > The strength of these encryption mechanisms depends to a
> > > large extent on key
> > > length used. I believe, RSA encryption with a key of 1024
> > > bits is currently
> > > considered not crackable. Shorter key lengths may be
> > > crackable but only with
> > > great effort. A newer algorithm called elliptical curve can
> > > also serve a
> > > similar function but has not had time to be as well evaluated.
> > >
> > > DES usually uses 56 bit keys. This was considered
> > > uncrackable up until a few
> > > years ago. Now it can be cracked, but only with great
> > > effort. Triple-DES is
> > > being used as a replacement. (Triple DES has an effective key
> > > length of 112.) I
> > > believe it is currently not crackable. There are other
> > > algorithms that can be
> > > used instead of Triple-DES but, I believe, their security has
> > > been less well
> > > established.
> > >
> > > Of course the effectiveness of these algorithms can be
> > > compromised if they are
> > > not carefully implemented. (As has been recently
> > > demonstrated by problems with
> > > Internet Explorer, and Navigator.) But, even when the
> > > implementation is less
> > > than perfect and short keys are used these algorithms provide
> > > a vastly more
> > > secure mechanism for transporting files then plane FTP.
> > >
> > > I hope this helps some.
> > >
> > > Jay Rosansky
> > > ACS-GSG
> > >
> > >
> > >
> > >
> > >
> >
> > ==============================================================
> > =========
> > To signoff the EDI-L list,
> mailto:[EMAIL PROTECTED]
> > To subscribe,
> mailto:[EMAIL PROTECTED]
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
> ==============================================================
> =========
> To signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
> To subscribe,
> mailto:[EMAIL PROTECTED]
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
>
=======================================================================
To signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
To subscribe,
mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
