> -----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.
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/
