Re: Secure file transfer

On Dec 17, 7:09 pm, Gerald Vogt wrote:
> On Dec 18, 8:17 am, "Sebastian G." wrote:
>
> > Gerald Vogt wrote:
> > > On Dec 18, 3:34 am, "Sebastian G." wrote:
> > >> Unruh wrote:
> > >>>> SSL. SSH/SFTP only protects the data transfer channel, not the command channel.
> > >>> No idea what you are talking about. ssh encrypts everything passing between
> > >>> the two computers.
> > >> We're talking about SFTP, which is a variant how to use SSH to secure the
> > >> FTP protocol. In the SFTP setup, the protection by SSH is only applied to
> > >> the data transfer channel.
>
> > > Do you have any URL to some documentation of this "SFTP" protocol?
>
> >
>
> This paragraph is titled "FTP over SSH" and not "SFTP". And it also
> says:
>
> "FTP over SSH is sometimes referred to as secure FTP; this should not
> be confused with other methods of securing FTP, such as with SSL/TLS
> (FTPS). Other methods of transferring files using SSH that are not
> related to FTP include SFTP and SCP; in each of these, the entire
> conversation (credentials and data) is always protected by the SSH
> protocol."
>
> SFTP is something else. It protects the "entire" conversation. Nowhere
> in this wikipedia article I find information that suggests "SSH/SFTP"
> or "SFTP" is this "FTP over SSH" mentioned in the article.
>
> Moreover, "FTP over SSH" is the protection of the command channel. You
> simply tunnel port 21 to the server. The return channel (i.e. the data
> channel) remains unprotected. This is in contrast to your former
> statement
>
> "SSL encrypts and authenticates both command and data channel, SSH/
> SFTP only the latter."
>
> Summarizing the wikipedia article:
>
> * FTP over SSH aka Secure FTP protects only the command channel. Not
> the data channel.
> * FTPS aka FTP over SSL is something different and protects the whole
> conversation.
> * SFTP is something different and protects the whole conversation.
>
> There is no information which says that SSH/SFTP or SFTP is what you
> claim it is nor that it is unsecure nor that any data is sent
> unencrypted.
>
> It looks to me as if you write about FTP over SSH. This was nowhere
> mentioned. SSH/SFTP was mentioned in the OP. But that is something
> completely different unless you have evidence the Core FTP does "FTP
> over SSH" for what is calls "SSH/SFTP".
>
> > Oh, and while we're at it:
> > , which discussed the difference between
> > implicit and explicit SSL mode on FTP-SSL.
>
> That one says "FTP over SSH (no acronym)" and otherwise says nothing
> about it or SFTP.
>
> Thus, so far both protocols in the OP - SSH/SFTP and AUTH SSL - are
> secure, don't transmit unencrypted data. They are both something
> completely different as the former uses a different protocol from the
> latter. Only the latter is derived from FTP while the former uses its
> own protocol which is not FTP.
>
> This brings us back to the original question in the OP:
>
> "In Core FTP, is it better to use AUTH SSL or SSH/SFTP?"
>
> As your original answer applies to FTP over SSH and not to SSH/SFTP we
> still have to discuss this issue. So far, I think both are secure.
>
> Gerald

(I am the OP'er)

Some questions...

1. When I use Auth SSL to connect, I see this message in the session
script:

AUTH SSL
500 This security scheme is not implemented

Does that mean that my login and password are in clear text? And/or
that any files I transfer are also vulnerable?

(The host would prefer that I use AUTH TLS, but this works only until
the program calls for a remote directory listing, and at that point it
hangs and times out for no obvious reason.)

2. Web-based services such as Yahoo Mail protect the login (https://
shows up on the URL bar when you log in), but thereafter it is
straight http://. This means that any mail I send or receive would be
visible as clear text to a sniffer, correct? There are a lot of people
who use such services, although there are some (like Gmail, I think)
which have an option for full SSL on messaging. But many do not. If
that's the case, why isn't it a huge problem? Is it simply a matter of
too much email, too few hackers?!

Thanks

Re: Secure file transfer

evans@silenceisdefeat.org wrote:


> 1. When I use Auth SSL to connect, I see this message in the session
> script:
>
> AUTH SSL
> 500 This security scheme is not implemented
>
> Does that mean that my login and password are in clear text? And/or
> that any files I transfer are also vulnerable?


If you're in implicit SSL mode: No, since you're already running everything
within an SSL session (and therefore trying to establish another SSL session
fails, intentionally). I guess this is what your tech guys tried to
communicate to you.

On the other, even in explitic SSL mode this is not the end of the world,
since there're a some othe rknown other variants to initiate SSL mode (like
MODE SSL and PROTP).


> 2. Web-based services such as Yahoo Mail protect the login (https://
> shows up on the URL bar when you log in), but thereafter it is
> straight http://. This means that any mail I send or receive would be
> visible as clear text to a sniffer, correct?


No, because they're target URL of their login forms is an https:// URL.
Yes, because this is still a problem since this form, send over an unsecured
HTTP connection, could be spoofed, and without looking at the websites HTML
code you don't know to which URL the form is pointing to (and after sending
the data it might be too late).

> If that's the case, why isn't it a huge problem?

It is, these idiots just don't want to acknowledge the problem.

> Is it simply a matter of too much email, too few hackers?!

No, it's about the additional processing cost and therefore hardware cost.