Good day,

My position here is the very same as that of Sai.
Kevin, just to be sure we fully understand your problem: what are those ftp
clients that use SSL for the data channel without issuing a PROT command?

As far as I know most FTP clients won't use SSL for the data channel unless
"PROT P" command is sent to the server. Is my understanding correct? I mean
for implicit mode, I hope we all agree that in explicit mode PROT P must be
executed.
Anyone has a list of clients that won't send PROT P but still will try to
use SSL ?

To my mind, if we added a "forceSSL" option most users would be confused
about it and would fail to acknowledge that the client is probably going to
use plain text if  PROT P wasn't sent  and thus the connection will fail
when "forceSSL"   is being used.




2008/12/22 Kevin Conaway <[email protected]>

> I have created an issue in Jira and attached a patch:
>
> https://issues.apache.org/jira/browse/FTPSERVER-247
>
> On Wed, Dec 17, 2008 at 5:32 PM, Kevin Conaway <[email protected]
> >wrote:
>
> > Fair enough.
> >
> > I could add a new parameter called "forceSsl" to the
> DataConnectionConfig.
> > The IoDataConnectionFactory would then use SSL for the data channel if
> > forceSsl is true.  Does that sound appropriate?
> >
> >
> > On Wed, Dec 17, 2008 at 4:43 PM, Sai Pullabhotla <
> > [email protected]> wrote:
> >
> >> > Is that even necessary?  The DataConnectionConfig already has an
> >> > SslConfiguration property.  If that property is set, doesn't that
> imply
> >> that
> >> > the data channel should use SSL?
> >>
> >> The SSL Configuration for the data connection tells the server that if
> >> a Client wants to use a secure channel, use the certificates and
> >> protocols specified in the SSL configuration. But, if the client does
> >> not or cannot do a secure data connection, the server should fall back
> >> to a plain data connection unless otherwise instructed (with the new
> >> parameter I was talking about).
> >>
> >> To further explain my reasoning, let us say I'm a web hosting service
> >> that give out an FTP account to all the members. For member A, the
> >> data is not sensitive, so he does not want to use secure data channel
> >> but may want to use SSL on the control connection so a hacker wont be
> >> able to steal the password. At the same time, member B transfers very
> >> sensitive information to/from the server and he wants to secure the
> >> data transfers by using a client software that is capable of doing
> >> this.
> >>
> >> Let me know what you think.
> >>
> >> Sai Pullabhotla
> >> Phone: (402) 408-5753
> >> Fax: (402) 408-6861
> >> www.jMethods.com
> >>
> >>
> >>
> >>
> >> On Wed, Dec 17, 2008 at 2:19 PM, Kevin Conaway <[email protected]
> >
> >> wrote:
> >> > Hi Sai,
> >> >
> >> >>> I don't think it is a good idea to change the default,
> >> >>> but it would be nice to add a new option to the dataConnection to
> >> >>> force SSL.
> >> >
> >> > Is that even necessary?  The DataConnectionConfig already has an
> >> > SslConfiguration property.  If that property is set, doesn't that
> imply
> >> that
> >> > the data channel should use SSL?
> >> >
> >> > On Wed, Dec 17, 2008 at 2:32 PM, Sai Pullabhotla <
> >> > [email protected]> wrote:
> >> >
> >> >> There are cases where a client/server just want a secure channel on
> >> >> the control connection (encrypt user name and password), but not the
> >> >> data itself. I don't think it is a good idea to change the default,
> >> >> but it would be nice to add a new option to the dataConnection to
> >> >> force SSL.
> >> >>
> >> >> Sai Pullabhotla
> >> >> Phone: (402) 408-5753
> >> >> Fax: (402) 408-6861
> >> >> www.jMethods.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Dec 17, 2008 at 1:20 PM, Kevin Conaway <
> >> [email protected]>
> >> >> wrote:
> >> >> > I apologize for replying to myself but I have some more thoughts.
> >> >> >
> >> >> > To me, the "implied" part of "implicit SSL" means that at the
> >> application
> >> >> > level, the user isn't aware that the FTP session is being conducted
> >> over
> >> >> > SSL.  Having to issue a PROT command to set the data protection
> level
> >> >> > violates the spirit of that assumption.
> >> >> >
> >> >> > Perhaps this is just my limited imagination, but I'm having a hard
> >> time
> >> >> > envisioning a scenario with implicit SSL where you would always
> want
> >> the
> >> >> > control channel to be encrypted but not the data channel.  Isn't
> that
> >> >> what
> >> >> > explicit FTPS is for?
> >> >> >
> >> >> > I have a patch ready that will force the data channel to "secure"
> >> mode if
> >> >> > the Listener is in "implicit" mode but I'm not sure of the
> >> implications
> >> >> of
> >> >> > making that switch.  Would it be permissible to at least have this
> >> >> available
> >> >> > as a configuration option?
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > On Tue, Dec 16, 2008 at 4:46 PM, Kevin Conaway <
> >> [email protected]
> >> >> >wrote:
> >> >> >
> >> >> >> Although the definition of "FTP with implicit SSL" varies
> depending
> >> on
> >> >> who
> >> >> >> you ask, its my understanding that it means that the entire FTP
> >> session
> >> >> is
> >> >> >> conducted over TLS/SSL.
> >> >> >>
> >> >> >> If thats true, shouldn't the data channel default to the "P" or
> >> private
> >> >> >> setting?  As of now, it defaults to clear (which is the specified
> >> >> behavior
> >> >> >> in RFC 2228).
> >> >> >>
> >> >> >> I have FTP clients that are connecting over implicit SSL without
> >> issuing
> >> >> >> the PROT command.  When they go to transfer a file, FtpServer sets
> >> up a
> >> >> >> plain socket for the data channel instead of an SSL one and the
> >> transfer
> >> >> >> never completes.
> >> >> >>
> >> >> >> Would it be appropriate for the ServerDataConnectionFactory to
> have
> >> the
> >> >> >> "secure" property set to true by default if the session is using
> >> >> implicit
> >> >> >> SSL?
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> Kevin Conaway
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
> >
>

Reply via email to