Bug #46851 for Net-FTPSSL: Arbitary port numbers

Thu Jun 11 05:52:58 2009 DUMB [...] cpan.org - Ticket created

Subject:

Arbitary port numbers

If you are connecting using an encryption type of IMP_CRYPT, then you can't change the port number from the default of 990. The constructor states: my $port = ($encrypt_mode eq IMP_CRYPT) ? 990 : ($arg->{Port} || 21); As a fix i've changed it to: my $port = 21; #default plain text port if ($arg->{Port}) { #use user defined port $port = $arg->{Port} } elsif ($encrypt_mode eq IMP_CRYPT) { #use default secure port $port = 990; } This would mean that the if the user specifies a custom port it overrides the two default values. Thanks

Thu Jun 11 11:09:00 2009 CLEACH [...] cpan.org - Correspondence added

Hi, This 990 port enforcement is by design. The IANA specification for FTP over SSL/TLS explicitly states that Implicit FTPS only uses port 990. If any other port is being used you are using Explicit FTPS. So my code assumes if you went to the trouble of overriding the default of EXP_CRYPT and asked for IMP_CRYPT, you must want port 990, since this is the only port that supports this protocal. My other choices were to just call die if there was a mismatch or correct back to EXP_CRYPT. Rereading the man page, I see that it does imply you could override the default port for IMP_CRYPT, but that was never the intention. So I've fixed the docs to say so for the next release. If you think I'm mistaken, please give me the details on the FTP server and a small example using ports you are trying to talk to with IMP_CRYPT using your patch. Also use Debug => 1 to generate a trace and send me what's written to STDERR as an attachement so that I can see your patch in action. Since I don't have a FTP server that supports IMP_CRYPT over a non-990 port. Just as an FYI, a more compact solution would have been. my $port = $arg->{Port} || (($encrypt_mode eq IMP_CRYPT) ? 990 : 21); Please provide the requested information & I'll reconsider putting this fix into the next release. Curtis

Thu Jun 11 11:09:01 2009 The RT System itself - Status changed from 'new' to 'open'

Thu Jun 25 22:23:31 2009 CLEACH [...] cpan.org - Correspondence added

Rejected due to lack of an example where IMP_CRYPT actually works on any other port besides port 990. There has been no reply for the last 2 weeks for a request for sample code & trace. The next update will include docs stating that IMP_CRYPT only uses port 990.

Thu Jun 25 22:23:33 2009 CLEACH [...] cpan.org - Status changed from 'open' to 'rejected'

Wed Jul 15 12:25:33 2009 CLEACH [...] cpan.org - Correspondence added

Found a case where a server does allow us to change the IMP_CRYPT port from 990 to something else. So will include this fix as part of v0.11.

Wed Jul 15 12:25:35 2009 The RT System itself - Status changed from 'rejected' to 'open'

Thu Jul 16 15:36:11 2009 DUMB [...] cpan.org - Correspondence added

On Wed Jul 15 12:25:33 2009, CLEACH wrote: Show quoted text

> Found a case where a server does allow us to change the IMP_CRYPT port > from 990 to something else. So will include this fix as part of v0.11.

I'm using the module in a security testing framework, although we have not seen a FTPS server running on a port other than 990, it could happen as we have found with other protocols clients change the ports to *hide* services. The framework that the module is used in needs to be able to support protocols on non standard ports even if non RFC. I'm happy to continue to apply my patch if this request is non standard. Thanks for your time in this matter.

Mon Jul 20 17:36:01 2009 CLEACH [...] cpan.org - Correspondence added

This change is now in v0.11. Thank you for your patience. Curtis

Mon Jul 20 17:36:04 2009 CLEACH [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Jul 20 17:36:39 2009 CLEACH [...] cpan.org - Fixed in 0.11 added