Jump to content


Photo

Clear Control Channel not working correctly?


This topic has been archived. This means that you cannot reply to this topic.
18 replies to this topic

#1 polivia

polivia
  • Members
  • 6 posts

Posted 11 August 2005 - 02:50 PM

If I setup SSL as follows:

Control Connection Mode: Clear
File Transfer: Private (Secure)
List Transfer: Private (Secure)

When I login it sends a PROT C (Clear Data Channel) and not a PROT P (Secure Data Channel) as I would expect. I see the CCC, but the data channel was not secured.

If I secure the Control connection, it sends a PROT P, but I need to CCC to clear the control channel to traverse NAT.

My server requires a secure data channel, so I'm getting rejected by the server.

Am I wrong here or is this a bug? Should it not send a PROT commands based on the Data Connection mode settings and not the control connection settings?

I referenced the ietf draft on this:
http://www.ietf.org/...-ftp-ssl-16.txt

10. Data Connection Security

The Data Connection security level is determined by the PROT command

The PROT command, as specified in [RFC-2228] allows client/server
negotiation of the security level of the data connection. Once a
PROT command has been issued by the client and accepted by the
server returning the '200' reply, the security of subsequent data
connections MUST be at that level until another PROT command is
issued and accepted; the session ends; a REIN command is issued;
or the security of the session (via an AUTH command) is re-
negotiated.

Data Connection Security Negotiation (the PROT command)

Note: In line with [RFC-2228], there is no facility for securing
the Data connection with an insecure Control connection.
Specifically, the PROT command MUST be preceded by a PBSZ command
and a PBSZ command MUST be preceded by a successful security data
exchange (the TLS negotiation in this case)

The command defined in [RFC-2228] to negotiate data connection
security is the PROT command. As defined there are four values
that the PROT command parameter can take.

'C' - Clear - neither Integrity nor Privacy

'S' - Safe - Integrity without Privacy

'E' - Confidential - Privacy without Integrity

'P' - Private - Integrity and Privacy

As TLS negotiation encompasses (and exceeds) the Safe /
Confidential / Private distinction, only Private (use TLS) and
Clear (don't use TLS) are used.

For TLS, the data connection can have one of two security levels.

1)Clear (requested by 'PROT C')

2)Private (requested by 'PROT P')

With 'Clear' protection level, the data connection is made without
TLS at all. Thus the connection is unauthenticated and has no
confidentiality or integrity. This might be the desired behaviour
for servers sending file lists, pre-encrypted data or non-
sensitive data (e.g. for anonymous FTP servers).

If the data connection security level is 'Private' then a TLS
negotiation must take place on the data connection, to the
satisfaction of the Client and Server prior to any data being
transmitted over the connection. The TLS layers of the Client and
Server will be responsible for negotiating the exact TLS Cipher
Suites that will be used (and thus the eventual security of the
connection).

In addition, the PBSZ (protection buffer size) command, as
detailed in [RFC-2228], is compulsory prior to any PROT command.
This document also defines a data channel encapsulation mechanism
for protected data buffers. For FTP-TLS, which appears to the FTP
application as a streaming protection mechanism, this is not
required. Thus the PBSZ command MUST still be issued, but must
have a parameter of '0' to indicate that no buffering is taking
place and the data connection should not be encapsulated.

Note that PBSZ 0 is not in the grammar of [RFC-2228], section
8.1, where it is stated:

PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any
decimal integer from 1 to (2^32)-1

However it should be noted that using a value of '0' to mean a
streaming protocol is a reasonable use of '0' for that parameter
and is not ambiguous.

Initial Data Connection Security

The initial state of the data connection MUST be 'Clear' (this is
the behaviour as indicated by [RFC-2228].)

He does mention that the data channel needs to start clear, but I did not find relevant text in the RFC that says that you must do a PROT C.

Here is the reference RFC:
http://www.faqs.org/rfcs/rfc2228.html

#2 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 11 August 2005 - 03:53 PM

Please post a log of your FTP session.

It should send a PROT P for your data connections you have set the data connection to private in the global settings or in case you are using a favorite in the favorite item setting. Make sure that the favorite settings do not override the global settings or vice versa.

Regards,
-Mat

#3 polivia

polivia
  • Members
  • 6 posts

Posted 11 August 2005 - 04:00 PM

SmartFTP v1.5.988.47
Resolving host name "elaftp01"
Connecting to 172.24.3.241 Port: 990
Connected to elaftp01.
220 208.11.141.245 FTP server ready
AUTH TLS
234 AUTH TLS successful
Connected. Exchanging encryption keys...
Session Cipher: 128 bit RC4
TLS encrypted session established.
PBSZ 0
200 PBSZ 0 successful
USER polivia
331 Password required for polivia.
PASS (hidden)
230 User polivia logged in.
SYST
215 UNIX Type: L8
FEAT
211-Features:
MDTM
REST STREAM
SIZE
AUTH TLS
PBSZ
PROT
211 End
PWD
257 "/prod/polivia" is current directory.
[b]PROT C[/b]
534 Unwilling to accept security parameters
CCC
200 Clearing control channel protection

#4 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 11 August 2005 - 04:22 PM

Hello ..

Thanks. You are right. SmartFTP should send a PROT P in your situation. This has been fixed in the latest beta build: http://www.smartftp....get/SFTPDev.exe.
But it looks your server doesn't accept a PROT command at all. The PROT command is sent prior to the CCC because PROT commands shouldn't be accepted after a CCC command due to security reasons.

BTW: Reverting back to a clear control channel (CCC) is only necessary if PASV mode is not allowed or your NAT router doesn't support UPnP with PORT mode.

Regards,
-Mat

#5 polivia

polivia
  • Members
  • 6 posts

Posted 11 August 2005 - 05:18 PM

Downloaded and used the latest build:
+- SmartFTP ---------------------------
Version : 1.5.988.54
Time Stamp : 2005-08-09 01:29:35

-------------------------------------------
Same problems:

SmartFTP v1.5.988.54
Resolving host name "elaftp01"
Connecting to 172.24.3.241 Port: 990
Connected to elaftp01.
220 172.24.3.241 FTP server ready
AUTH TLS
234 AUTH TLS successful
Connected. Exchanging encryption keys...
Session Cipher: 128 bit RC4
TLS encrypted session established.
PBSZ 0
200 PBSZ 0 successful
USER polivia
331 Password required for polivia.
PASS (hidden)
230 User polivia logged in.
SYST
215 UNIX Type: L8
FEAT
211-Features:
MDTM
REST STREAM
SIZE
AUTH TLS
PBSZ
PROT
211 End
PWD
257 "/prod/polivia" is current directory.
PROT C
534 Unwilling to accept security parameters
CCC
200 Clearing control channel protection
TYPE I
The system detected an invalid pointer address in attempting to use a pointer argument in a call.
Client closed the connection.

This version does the same thing. It sends a PROT C. You mentioned that my server does not support PROT, but the FEAT section lists it. I can do a fully secure connection (ctrl and data) which sends a PROT P. If you try to do a clear control session in sends a PROT C. My understanding is that this is an incorrect implementation based on the previous posts. What version is the one where CCC works correctly.

#6 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 11 August 2005 - 05:43 PM

Hello ..

It doesn't seem that you have installed the latest version (1.5.988.55). If you did, then your Data Connection Mode for File Transfers is not set to "Private".

The CCC in SmartFTP doesn't seem to work together with your server. It would require some debugging to see what's going on. The reason we do not recommend CCC is because it's implemented slightly different by each software. Feel free to do your own research and you will probably get to the same result.

If you can provide us an account which allows us to login to the server we will take a look at it.

Regards,
-Mat

#7 polivia

polivia
  • Members
  • 6 posts

Posted 11 August 2005 - 05:57 PM

+- SmartFTP ---------------------------
Version : 1.5.988.55
Time Stamp : 2005-08-11 17:44:52

--------------------------------------------------
This version works. Thanks:

220 172.24.3.241 FTP server ready
AUTH TLS
234 AUTH TLS successful
Connected. Exchanging encryption keys...
Session Cipher: 128 bit RC4
TLS encrypted session established.
PBSZ 0
200 PBSZ 0 successful
USER polivia
331 Password required for polivia.
PASS (hidden)
230 User polivia logged in.
SYST
215 UNIX Type: L8
FEAT
211-Features:
MDTM
REST STREAM
SIZE
AUTH TLS
PBSZ
PROT
211 End
PWD
257 "/prod/polivia" is current directory.
PROT P
200 Protection set to Private
CCC
200 Clearing control channel protection

#8 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 11 August 2005 - 08:50 PM

Does the CCC work as well?

Regards,
-Mat

#9 polivia

polivia
  • Members
  • 6 posts

Posted 11 August 2005 - 09:01 PM

Yes. The Firewall recognized the FTP session and flipped IP addresses in the PORT command as was needed.

#10 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 11 August 2005 - 09:16 PM

Ah good to hear :-) Do you know what FTP server software is running on the remote server?

Thanks
-Mat

#11 polivia

polivia
  • Members
  • 6 posts

Posted 11 August 2005 - 09:22 PM

proftpd

#12 STVM

STVM
  • Members
  • 2 posts

Posted 08 February 2006 - 11:11 AM

Hi,
I installed the lastest version of SmartFTP 2.0.993 and performed the same test done in these previous messages.
ProFTPD is the last 1.3.0rc3 released.
It perfectly works
- AUTH_TLS is send
- The handskake is done and the login password are sent encrypted.
- Then a PROT P is sent
- And to the CCC command.

But, after that, SmartFTP send a TYPE A command, Not in cleartext, still encryted !!

As per RFC 4217 ftp://ftp.rfc-editor.org/in-notes/rfc4217.txt

#13 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 08 February 2006 - 04:55 PM

Please post the complete log.

Thanks
-Mat

#14 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 24 February 2006 - 07:36 PM

Regarding CCC and proftpd. It turned out to be a bug in the ProFTPD software. See the following link for further details (including a patch):
http://bugs.proftpd....bug.cgi?id=2753

Regards,
-Mat
SmartFTP

#15 STVM

STVM
  • Members
  • 2 posts

Posted 11 May 2006 - 10:24 AM

Hi,
I tried again with proftpd 1.3 and smartFTP 2.0.996 and the same problem occurs.
Anyway it works fine with WS_FTP.
Please find here below the smartFTP logs.

-------------------------------
[11:51:20] SmartFTP v2.0.996.23
[11:51:20] Resolving host name "XXX"
[11:51:20] Connecting to XXX Port: XXX
[11:51:20] Connected to XXX
[11:51:20] 220-
[11:51:20] 220-*** Private FTP server
[11:51:20] 220-***
[11:51:20] 220-*** Welcome XXX, local time is Thu May 11 11:46:12 2006
[11:51:20] 220-***
[11:51:20] 220-*** All transfers are logged...
[11:51:20] 220-
[11:51:20] 220 XXX FTP server ready
[11:51:20] AUTH TLS
[11:51:20] 234 AUTH TLS successful
[11:51:20] Connected. Exchanging encryption keys...
[11:51:20] Session Cipher: 128 bit RC4
[11:51:20] TLS encrypted session established.
[11:51:20] PBSZ 0
[11:51:21] 200 PBSZ 0 successful
[11:51:21] USER foobar
[11:51:21] 331 Password required for foobar
[11:51:21] PASS (hidden)
[11:51:21] 230 User foobar logged in.
[11:51:21] SYST
[11:51:21] 215 UNIX Type: L8a
[11:51:21] FEAT
[11:51:21] 211-Features:
[11:51:21] 211-MDTM
[11:51:21] 211-REST STREAM
[11:51:21] 211-SIZE
[11:51:21] 211-AUTH TLS
[11:51:21] 211-PBSZ
[11:51:21] 211-PROT
[11:51:21] 211 End
[11:51:21] PWD
[11:51:21] 257 "/" is current directory.
[11:51:21] PROT P
[11:51:21] 200 Protection set to Private
[11:51:21] CCC
[11:51:21] 200 Clearing control channel protection
[11:51:21] TYPE A
[11:51:21] 500  not understood
[11:52:12] NOOP
[11:52:12] 200 NOOP command successful
[11:52:15] TYPE A
[11:52:15] 200 Type set to A
[11:52:15] PASV
[11:52:15] 227 Entering Passive Mode (XXX).
[11:52:15] Opening data connection to XXX Port: XXX
[11:52:15] LIST -aL
[11:52:15] Connected. Exchanging encryption keys...
[11:52:15] 150 Opening ASCII mode data connection for file list
[11:52:15] Session Cipher: 128 bit RC4
[11:52:15] TLS encrypted session established.
[11:52:15] 197 bytes transferred. (754 octets/s) (261 ms)
[11:52:15] 226 Transfer complete.
[11:53:05] NOOP
[11:53:05] 200 NOOP command successful

#16 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 11 May 2006 - 12:15 PM

The CCC implementation in SmartFTP is correct. If it doesn't work with proftpd it's a problem with the FTP server. I personally submitted the patch for proftpd to T.J Sanders. It was committed to the CVS but I don't know what he changed in the meanwhile.

Regards,
SmartFTP

#17 viulian

viulian
  • Members
  • 2 posts

Posted 15 May 2006 - 03:04 PM

I also have some issues with CCC command using SmartFTP v2.0.996

I have tested it against WU_FTP Server 5.0.5.

To me it seems that SmartFTP does not go back to plain text mode after it receives the 200 answer from the server that the CCC was handled correctly.

I mean the RFC 4217 says that a server which receives the CCC command should:

o Send a 200 reply.

o Shutdown the TLS session on the socket and leave it open.

o Continue the control connection in plaintext, expecting the
next command from the client to be in plaintext.

At this point SmartFTP locks and is not able to exchange data with the server. I have written an FTP server myself and I modified it to send some plain text back to the SmartFTP after the 200 reply and after the TLS session was dropped.

Here are the logs:

[17:55:35] SmartFTP v2.0.996.22
[17:55:35] Resolving host name "localhost"
[17:55:35] Connecting to 127.0.0.1 Port: 21
[17:55:35] Connected to localhost.
[17:55:35] 220 Enter your username and password.
[17:55:35] AUTH TLS
[17:55:35] 234 AUTH OK
[17:55:35] Connected. Exchanging encryption keys...
[17:55:36] Session Cipher: 168 bit 3DES
[17:55:36] TLS encrypted session established.
[17:55:36] PBSZ 0
[17:55:36] 234 PBSZ OK.
[17:55:36] USER test
[17:55:36] 331 Password required for test.
[17:55:36] PASS (hidden)
[17:55:36] 230 User test logged in.
[17:55:36] SYST
[17:55:36] 215 UNIX
[17:55:36] FEAT
[17:55:37] 211 Extensions supported:
[17:55:37] TYPE I
[17:55:37] AUTH TLS
[17:55:37] AUTH SSL
[17:55:37] PBSZ
[17:55:37] PROT
[17:55:37] 211-End
[17:55:37] 200 Type set to I
[17:55:37] REST 0
[17:55:37] 350 Restarting at 0
[17:55:37] PWD
[17:55:37] 257 "/" is current directory.
[17:55:37] PROT P
[17:55:37] 234 PROT OK.
[17:55:37] CCC
[17:55:37] 200 CCC OK.

<-- the 200 CCC OK. is sent using the secure connection - as it should - and then the TLS layer is stopped; communication now should proceed in plain text. I've modified the server so its now sending a plain text message back to client using the plain text connection - but SmartFTP gets an SSL internal error, which means that it did not shut down its TLS/SSL layer. -->

[17:55:37] SSL/TLS internal error (Error = 0x104f8480).
[17:55:37] The token supplied to the function is invalid
[17:55:37] The token supplied to the function is invalid
[17:55:37] Client closed the connection.

If I take of the plain text message which triggers the internal error, SmartFTP freezes and does not communicate with the server anymore (WU-FTP Server 5.0.5) nor it sends some other command to the server.

Thanks

#18 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 15 May 2006 - 03:26 PM

SmartFTP's CCC implementation is correct. As seen numerous times in the past if there is a problem, it's with the server software.
You don't seem to close the SSL/TLS channel correctly.

Regards,
SmartFTP

#19 viulian

viulian
  • Members
  • 2 posts

Posted 16 May 2006 - 09:03 AM

Thanks for the answer, indeed you are right.
I did not shut down the TSL session, I was just writting on the underlying plain text socket.

SmartFTP is sweet :unsure: