camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: camel-ftp and ftps secure data channel
Date Tue, 15 Jun 2010 13:53:35 GMT
Thanks Claus!

Will test shortly (probably tomorrow),

/Bengt

2010/6/15 Claus Ibsen <claus.ibsen@gmail.com>

> On Tue, Jun 15, 2010 at 12:57 PM, Bengt Rodehav <bengt@rodehav.com> wrote:
> > Claus,
> >
> > Just realised that I can stop both PSBZ and PROT to be sent by
> > specifying useSecureDataChannel=false. This means that it is possible to
> > tweak this every possible way. The only issue then would be the name of
> this
> > option. E g it's a bit illogical to specify:
> >
> > useSecureDataChannel=false
> > execProt=P
> >
> > as well as:
> >
> > useSecureDataChannel=true
> > execProt=C
> >
> > What the option "useSecureDataChannel" really does is setting default
> values
> > for execProt and execPbsz - maybe this should be reflected in the name.
> What
> > about renaming this option to "disableSecureDataChannelDefaults" (maybe a
> > bit long...). The meaning of its value would be the inverse of
> > "useSecureDataChannel" and its default value would be false.
> >
>
> Hi
>
> I have renamed that option. Yeah finding a good name for options is
> often harder than you would think.
> Fell free to test the latest source code on your systems.
>
>
> >
> > /Bengt
> >
> > 2010/6/15 Bengt Rodehav <bengt@rodehav.com>
> >
> >> Claus,
> >>
> >> I've tested your new version and it works very good. However, I did not
> >> find a way to specify that the PSBZ command should not be sent at all. I
> >> have a feeling that one does not want to send it when explicitly
> specifying
> >> PROT C. I'm not sure but maybe we need a way of specifying the the PSBZ
> /
> >> PROT command should not be sent. Perhaps some reserved value like "-1"
> for
> >> execPbsz and "none" for execProt.
> >>
> >> One other question/suggestion. The default port for ftps in camel-ftp is
> >> 2222. I don't quite understand why. Both Filizilla and Serv-U use port
> 21
> >> (the normal ftp port) for explicit ftps and port 990 for implicit ftps.
> I
> >> have a feeling that this is standard practice. Would be nice if
> camel-ftp
> >> defaulted to that.
> >>
> >> Did you know anything about the exception I mentioned? (Unconnected
> >> sockets not implemented...)
> >>
> >>
> >> Best regards,
> >>
> >> /Bengt
> >>
> >>
> >> 2010/6/15 Claus Ibsen <claus.ibsen@gmail.com>
> >>
> >> Hi Bengt
> >>>
> >>> I have just committed a change on trunk. Can you test it on your
> system?
> >>> It now defaults have useSecureDataChannel as true. And that P and 0 is
> >>> used if not explicit configured.
> >>>
> >>>
> >>>
> >>> On Tue, Jun 15, 2010 at 8:35 AM, Bengt Rodehav <bengt@rodehav.com>
> wrote:
> >>> > Claus,
> >>> >
> >>> > I decided to create a new thred of conversation instead of reusing
> >>> > "camel-ftp problems with ftps implicit mode". The modifications you
> did
> >>> in
> >>> > camel-ftp required me to upgrade to trunk (2.4-SNAPSHOT) which gave
> me a
> >>> lot
> >>> > of problems due to the changs in Camel's OSGi support. Willem has
> helped
> >>> me
> >>> > to sort them out and I've now gone back to the original ftps secure
> data
> >>> > channel subject.
> >>> >
> >>> > NOTE, if you've read my last post in the thread "camel-ftp problems
> with
> >>> > ftps implicit mode" I had missed the first line of the exception
> >>> stacktrace
> >>> > which I have corrected in this mail.
> >>> >
> >>> > I've now tested your ftps enhancement against Filezilla and Serv-U
> and
> >>> it
> >>> > works. However, I noticed the following:
> >>> >
> >>> > If option "execPbsz" is not set then the PBSZ command is not sent at
> >>> all.
> >>> > The documentation says that default value is "0" which indicates that
> >>> PBSZ
> >>> > is always sent. I think the behaviour is correct but the
> documentation
> >>> > should change and specify that "null" is the default value for
> >>> "execPbsz".
> >>> >
> >>> > About the configuration, I still think that the configuration is a
> bit
> >>> > illogical. First of all, PBSZ and PROT commands are valid even though
> a
> >>> > secure data channel is not used. It might even be valid for purt ftp
> >>> (not
> >>> > ftps) as well - I'm not sure. Therefore, the execProt and execPbsz
> >>> options
> >>> > should take effect regardless of the value of the
> useSecureDataChannel
> >>> > option.
> >>> >
> >>> > Furthermore, I think the normal case should be default and require
> very
> >>> > little configuration. I therefore suggest the following:
> >>> >
> >>> > a) useSecureDataChannel should be true by default. This is due to two
> >>> > reasons:
> >>> >  1. If ftp severs have requirements in this area, they tend to be
> >>> > restrictive. Serv-U, for example require PROT P (secure data
> channel).
> >>> Clear
> >>> > text is allowed if one explicitly sends PROT C but not if no PROT
> >>> command is
> >>> > sent at all.
> >>> >  2. I think that if the default is clear text then many developers
> will
> >>> > send unencrypted content by mistake. I think that if you choose to
> use
> >>> ftps,
> >>> > most developers assume that the data is encrypted. That's what I did
> >>> anyway.
> >>> >
> >>> > b) If useSecureDataChannel is true, then this implies execPbsz=0 and
> >>> > execProt=P without having to configure it explicitly.
> >>> >
> >>> > c) execPbsz and execProt options shall always take effect and shall
> >>> override
> >>> > the values implied by setting useSecureDataChannel to true. Normally
> one
> >>> > would not have to configure these options at all.
> >>> >
> >>> > One can argue that if we make PBSZ 0 and PROT P the default, then we
> >>> could
> >>> > skip the useSecureDataChannel and only have the execProt and execPbsz
> >>> > options. This would actually be OK since overriding the PBSZ 0 / PROT
> P
> >>> > options is an active decision by a developer who presumably knows
> what
> >>> s/he
> >>> > is doing. This is OK with me but then it should also be possible to
> >>> disable
> >>> > sending of the PBSZ and PROT commands by explicitly setting those
> >>> options to
> >>> > the empty string.
> >>> >
> >>> > Maybe I'm writing too much in this thread now but I also found
> another
> >>> > problem: If something goes wrong, e g file already exists (Filezilla
> >>> doesn't
> >>> > permit overwrite) then I get the following exception on subsequent
> >>> attempts.
> >>> > I have to manually restart the route to get it to work.
> >>> >
> >>> > org.apache.camel.component.file.GenericFileOperationFailedException:
> >>> File
> >>> > operation failed: null Unconnected sockets not implemented. Code: 221
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:107)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.FtpsOperations.connect(FtpsOperations.java:40)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.connectIfNecessary(RemoteFileProducer.java:170)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.preWriteCheck(RemoteFileProducer.java:123)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:75)[65:org.apache.camel.camel-core:2.4.0.SNAPSHOT]
> >>> > at
> >>> >
> >>>
> org.apache.camel.component.file.remote.RemoteFileProducer.process(RemoteFileProducer.java:49)[76:org.apache.camel.camel-ftp:2.4.0.SNAPSHOT]
> >>> > ...
> >>> >
> >>> > I get the above exception regardless of the value of the "disconnect"
> >>> optin
> >>> > in camel-ftp.
> >>> >
> >>> >
> >>> > Best regards,
> >>> >
> >>> > /Bengt
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Claus Ibsen
> >>> Apache Camel Committer
> >>>
> >>> Author of Camel in Action: http://www.manning.com/ibsen/
> >>> Open Source Integration: http://fusesource.com
> >>> Blog: http://davsclaus.blogspot.com/
> >>> Twitter: http://twitter.com/davsclaus
> >>>
> >>
> >>
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message