Hello Kevin, As you already said we are following the RFC here and -although I admit that makes little sense in these days- Sai is right that it is quite common to have only the control channel encrypted: I even saw a client (gFtp maybe?) that didn't support SSL for the data channel. And there are some servers with the same limitation.
Sai's suggestions makes sense to me but It's possible to argue (let's wait for Niklas's opinion here) that having an option to force SSL mode would add little value to most users and "core" code would become a little more bloated. Right now you can get the DataChannel from the Session object in any FTPLet and ask if isSecure() (something like that, Im on holidays using a public computer :-) ) so you can implement a onBeforeCommand metod for PORT and PASSIVE in your FTPLet that let you continue only if your channel is secured. Currently I'm doing this myself, but just intercepting the STOR/STOU and RETR commands. Other people is doing the very same thing, so maybe the could send you an example. If i were you I wouldn't wait for an update only for this, although we of course will think about implementing this option. 2008/12/17 Sai Pullabhotla <sai.pullabho...@jmethods.com> > 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 <kevin.cona...@gmail.com> > 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 <kevin.cona...@gmail.com > >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 > >> > > >
