× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'm not an expert on FTPS, but my understanding of reading
https://en.wikipedia.org/wiki/FTPS#Scope_of_use is this:

If using implicit mode, everything is encrypted all the time. In this mode
you start the connection encrypted and it uses port 990 by default.

If using explicit mode, you connect unencrypted. You have to explicitly
issue an AUTH TLS command to enable encryption. Once you issue the AUTH
TLS command, the command channel is encrypted, but the data channel is not
(ftp commands are encrypted, but data being put/get is not). To secure the
data channel, you must issue a PROT command, which can take a single
argument C, S, E, or P to determine the level of security on the data
channel. If you only want to encrypt the authentication you can issue a
CCC command to clear the command channel once authenticated:

"It is desirable in some environments to use a security mechanism
to authenticate and/or authorize the client and server, but not to
perform any integrity checking on the subsequent commands. This
might be used in an environment where IP security is in place,
insuring that the hosts are authenticated and that TCP streams
cannot be tampered, but where user authentication is desired."

It might be good to peruse RFC 2228 as well (
https://tools.ietf.org/html/rfc2228), which where the previous quote comes
from.

If using FileZilla, it seems to have full support for explicit connections
and setting PROT options:
https://wiki.filezilla-project.org/FTP_over_TLS#Explicit_vs_Implicit_FTPS

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 03/31/2016
01:15:21 PM:

From: John Yeung <gallium.arsenide@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 03/31/2016 01:15 PM
Subject: Re: Plain FTP - Using Encrypted Authentication.
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

On Thu, Mar 31, 2016 at 12:59 PM, Rob Berendt <rob@xxxxxxxxx> wrote:
FTPS <> FTP with session authentication encrypted.

That may well be true, but you haven't demonstrated that *you* know
whether or not you're talking about FTPS.

FTPS has the entire session encrypted, not just the session
authentication.

Not necessarily. Scott has discussed this at least once and probably
several times on these lists. FTPS allows the session to be in
encrypted or unencrypted mode at arbitrary points during the session.
Here is a relevant passage:

[from http://archive.midrange.com/midrange-l/201009/msg00091.html]
"So FTPS typically uses the encryption only for the userid/password,
and then drops back to plain-text mode. That's not nearly as secure as
sftp, which stays encrypted throughout the conversation."

Granted, that's from 2010. But it's from Scott Klement. And the point
is that FTPS doesn't *necessarily* require the entire session to be
encrypted.

Did someone actually read the suggestion to check out wikipedia???

Well, the only suggestion to check out Wikipedia that I see is from
Chris, who sent his response a hair after I sent mine. Propagation
issues may have caused some people to receive his message before mine,
but mine is numbered and threaded before his in the archives.

In any case, sure, check out the Wikipedia article on FTPS (which is
what Chris suggested). It's a little difficult to follow, in my
opinion, but if you really understand what it's saying, you'll realize
that FTPS indeed allows parts of the session to be unencrypted. Chris
actually mentions this right in his message:

"The secondary data channel may be encrypted or not depending on the
server configuration."

On the other hand, you quote this:

<snip>
For secure transmission that protects the username and password,
and encrypts the content,
FTP is often secured with SSL/TLS (FTPS)
</snip>
The key part being: "and encrypts the content"

But it's from the Wikipedia article on FTP, rather than on FTPS. Your
interpretation of the quote is an example of the logical fallacy that
amounts to assuming every rectangle is a square. Yes, you CAN send
encrypted content using FTPS. And one way that people DO send
encrypted content is by using FTPS. But FTPS does not *require* that
content is encrypted.

I believe it is possible to secure just the authentication and not the
content.

Right. And even if you do that, you have not precluded the possibility
that you are using FTPS.

For example, Go Anywhere's Managed File Transfer product supports:
- HTTPS/AS2
- FTP
- FTPS
- SFTP
When configuring FTP (not ftps) there is an option on the Listener
part
called "Force Encrypted Authentication". That only encrypts the
authentication and not the entire session. I'm pretty sure if it
substituted the entire thing for FTPS the options would not be blank,
yes
and no but instead would say something to the effect of "Start the
FTPS
service instead of FTP!"

Fine. So GoAnywhere may either have its own crazy
FTP-without-SSL-but-with-encrypted-auth, or it may be rejiggering the
terminology such that when they say "FTPS" it means one form of FTPS,
and when they say "FTP with encrypted authentication" it means a
different form of FTPS. I don't know.

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.