polivia
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/internet-drafts/dra ... 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
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/internet-drafts/dra ... 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
Do you know what FTP server software is running on the remote server?