[Info-vax] FTP/SSL from OpenVMS (client) to Unix Filezilla (server) failure

[Stephen Hoffman]

On 2012-08-07 12:37:13 +0000, Dirk Munk said:

> gopalakrishnan wrote:
>> Hi Ken
>> 
>> I submitted a reply to Hoff's message and repeated when I did not find 
>> my reply here. And still it is not here (I did not get the usual 
>> response "message will be reviewd and posted" in those two instances). 
>> Hope this gets loaded.

You're apparently not using usenet, you're probably using one of those 
sites that re-hosts usenet content.
Try accessing this usenet newsgroup directly.
You can get a free usenet news account at eternal-september.org, and 
news readers are available for all platforms.

>> 
>> The server truly is FTP over SSL service (the very first line in the 
>> SP's documentation). They use "SFTP" to describe the service as being 
>> "secure". The service uses port 22 which is not FTP/SSL standard port 
>> but SFTP's. Even the server is named "sftp.xxxx.co.nz"
>> 
>> Moreover I can connect to the sevice, view folders and download files 
>> using a Windows FilZilla client connecting to "FTPES://sftp.xxx.co.nz", 
>> port 22 (and user-id / password)
>> 
>> I have tried SFTP and it does not work

"Does not work"?   Please explain that.  And please see 
<http://www.mikeash.com/getting_answers.html> for some background on 
this topic.

>> 
>> My infrastructure team is now investigating if this has anything to do 
>> with our firewall/isa configuration

That would be typical, but that also implies that the FileZilla test 
wasn't the same network path as the OpenVMS test.

>> 
>> Regards -tk
>> 
>> 
>> --http://compgroups.net/comp.os.vms/ftp-ssl-from-openvms-client-to-unix-filezilla-ser/1519815 
>> 


If that's the service you're using to access the comp.os.vms newsgroup, 
please use usenet news directly.


> With the windows version you are using explicit FTPS, or FTPES, and 
> that may point to the problem. From Wikipedia:
> 
> Explicit
> 
> In explicit mode (also known as FTPES), an FTPS client must "explicitly 
> request" security from an FTPS server and then step-up to a mutually 
> agreed encryption method. If a client does not request security, the 
> FTPS server can either allow the client to continue in unsecure mode or 
> refuse/limit the connection.
> 
> The mechanism for negotiating authentication and security with FTP was 
> added under RFC 2228, which included the new FTP command AUTH. While 
> this RFC does not explicitly define any required security mechanisms, 
> e.g. SSL or TLS, it does require the FTPS client to challenge the FTPS 
> server with a mutually known mechanism. If the FTPS client challenges 
> the FTPS server with an unknown security mechanism, the FTPS server 
> will respond to the AUTH command with error code 504 (not supported). 
> Clients may determine which mechanisms are supported by querying the 
> FTPS server with the FEAT command, although servers are not necessarily 
> required to be honest in disclosing what levels of security they 
> support. Common methods of invoking FTPS security included AUTH TLS and 
> AUTH SSL.
> 
> In the later RFC 4217, FTPS compliance required that clients always 
> negotiate using the AUTH TLS method. The RFC also recommended FTPS 
> servers to accept the draft mechanism AUTH TLS-C.
> 
> 
> Th use of port 22 is wrong. For FTPS the normal port numbers are 989 
> and 990. However some implications use the standard FTP port 21 for FTP 
> and FTPS.
> 
> SFTP uses port 22, but as you know SFTP is something very different 
> from FTP or FTPS.


ftp is a pile of steaming stench, with a side-helping of skunk-stink.

ftp over ssl (aka ftps) is, well, a bandaid atop a steaming pile of 
stench.  ftp/ftps on the wrong ports is worse; emphasis on ports.  The 
steaming pile of stench that is ftp/ftps is inherently incompatible 
with modern networks, and with firewalls.  In particular, ftp/ftps 
opens a second port up in the empheral range, which then usually gets 
blocked by an intervening firewall, or means expensive 
protocol-sniffing firewalls.  (And protocl sniffing is tougher with 
ftps, for obvious reasons.)

The vastly better protocol here is sftp, which shares three or four 
letters with those other protocols and a basic purpose, but is 
otherwise quite different.  sftp is expressly designed to operate 
(securely) in modern networks.  Unlike the steaming pile of ftp/ftps 
stench.

Put another way, move to sftp where you can.

If you can't use sftp, then you could shovel the bits over to the 
Windows PC box and use FileZilla to transfer the files.  (I'm here 
presuming that your FileZilla test is using the same network path as 
the OpenVMS system that you're testing with.  If it's not, then 
firewalls are back in play, and we can once again enjoy the wafting 
stench of ftp and ftps.)

Various versions of cURL can be used to access ftps servers, too, and 
there's a cURL port for OpenVMS.  (Whether that port does ssl and thus 
ftps, I don't know.)  And there are probably some Java ftps clients 
around.

Or use a VPN, which would reduce the exposure of ftp and ftps to the 
vagaries of the intervening network firewalls.

Now the other wildcard here might be the use of "secure ftp", which is 
tunneling ftp (gag) through ssh.  That would normally use port 22, 
because it's using ssh.  Though the use of ftpes via Filezilla would 
tend to belie that use, though.

In general, if there's a support contract in place with HP, call the HP 
support center and have them sort this out.  There have been some bugs 
in recent versions of the TCP/IP Services for OpenVMS package, and this 
might be another one.

And yes, you could reasonably infer I'm not fond of ftp.



-- 
Pure Personal Opinion | HoffmanLabs LLC