Data connection closed - FTP with SSL and Self-Signed Certificate

I have tried to establish a SSL-Connection with WINSCP to a z/VM Mainframe-System.
Winscp Level is: WinSCP Version 5.11.3 (Build 7995) (OS 6.1.7601 Service Pack 1
Windows Client is: Windows 7 Enterprise
z/VM-Level is: z/VM Version 6 Release 4.0, service level 0000 (64-bit)
Connect with a Unsecured Connection runs without Problems with Standard-Port 21 21.
SSL Connection goes over Ports 990/991 in Passive Mode (Ports 980 to 989).
In the attachment is the Winscp.log-output.
Can anybody check and solve the reason ?

Can you retrieve the listing using any other FTP client over implicit FTPS?

Did you try explicit FTPS?

I have tried to make a implicit connection with Filezilla. The connection opens, but I couldn´t get the Listing. Same problem with SSL and unsecured with Filezilla. I have not tested with a explicit connection.

That means the server firewall or some NAT on the way between your and the server is misconfigured.
Read this article:
https://winscp.net/eng/docs/ftp_modes

Unsecured Access zu z/VM 64. has the same Problem when the FTP Configuration on z/VM has Listformat VM. LISTFORMAT UNIX ASCII has no problems.
Attached the Logfiles and the Screenshots.

Attachment

Attachment

Attachment

hjglaser wrote:

Unsecured Access zu z/VM 64. has the same Problem when the FTP Configuration on z/VM has Listformat VM. LISTFORMAT UNIX ASCII has no problems.
Attached the Logfiles and the Screenshots.

Sorry, but I do not understand your new posts. Do you believe they invalidate my previous answer? Or why did you post them?

I have made this test, because I believe, that z/VM 6.4 is very new and I thought that it can be that it is not a problem of the secured connection. The secured connection has a normal session, so that the Self-Signed Certificate is accepted.
It is not a problem of a secured or unsecured session. It is a general problem. We should first solve the problem of the unsecured session with LISTFORMAT VM and then we can test with the secured session.

I have established the connection with the Client-Software Coreftp. It works with Listformat VM and Listformat UNIX ASCII without problems. It seems that WINSCP has problems with the Listformat VM on z/VM 6.4

I never wrote that the problem is with secured connection.

Please attach a complete and verbose log file from Core FTP.

I have written a post of the WINSCP-Problem on [email protected] and got the following answer from Alan Altmark
Senior Managing z/VM and Linux Consultant,IBM Systems Lab Services,IBM Z Delivery Practice:
First answer:
>> All of this because RFC 959 failed to define a format for the textual
>> responses present in most of the commands. Later functionality added
to
>> FTP typically defined the textual responses for the new functions, but
>> there's nothing to be done at this point unless a new RFC that adds a
>> "standardized textual output" feature to the protocol is brought
forward.
>>
>
> FSVO "failed". FTP was not designed as a programming interface. The
> design assumed that the (human) user would be conversant with tne format
> conventions of the remote system and able to deal with them.

Weak and solvable then. Still weak and still not solved today. Note that
EPSV/EPRT (20 years old) have clearly defined responses, both for humans
and programs.

> In effect, Filezilla and its kin are employing AI with some hints from
> the user. How does the NLST command deal with a filename containing a
> newline?

Path names are all defined as "char *", and as such are delimited by
newline, so you're going to have a problem creating a file with newline in
its name. But if such a thing were to exist, I would expect all sorts of
UIs to misbehave or simply fail under such a condition. Responses to NLST
and LIST are textual, with CRLF (or just LF) acting as the delimiter.


Second answer:
> On various systems I'm familiar with, "char *" is delimited by NUL, not
newline.

Of course you are right.

> No problem on Linux:
>
> 522 $ ls -ln
> total 0
> -rw-r--r-- 1 1000 1000 0 Feb 23 10:34 foo?bar
> 523 $ ls | od -tx1
> 0000000 66 6f 6f 0a 62 61 72 0a
> 0000010

Here's what ftpd does:
fprintf(dout, "%s%s\n", dirname, type == TYPE_A ? "\r" : "");

So one wonders if fprintf() will convert non-displayable chars to "?".

Attached the screenshot of core-ftp with unsecured connect to VMA2

Anonymous wrote:

Attached the log of core-ftp with unsecured connect to VMA2

Attached the Screenshot of Core-FTP

Thanks for the Core FTP log. Though it's not comparable, as it's not using TLS/SSL encryption.

Can you retrieve directory listing using Core FTP with enabled encryption?

I´m not at customer-site this week.
I send the log next week.

Attached you find the log of Winscp (Secured Connection)

Attached the log of Coreftp (secure connection)

I can see that you have enabled "UNIX list format" on the server:

< 215 VM is the operating system of this server. UNIX list format is active.

But you have also enabled "Support for listing of hidden files" option in WinSCP, what breaks it, even before WinSCP gets to retrieving the listing:

. 2018-03-12 13:15:44.599 FTP: Passive: Yes [Force IP: Off]; MLSD: Off [List all: On]; HOST: Off
...
> 2018-03-12 13:15:55.361 LIST -a
. 2018-03-12 13:15:55.361 Connecting to 10.130.130.160:980 ...
< 2018-03-12 13:15:55.361 550 '-a' not found