• From: Texas
  • Registered: 2020-08-17
  • Posts: 63

Topic: FTPS data port failure.

Hello,
I am looking for some assistance with an FTPS client app I am writing.

I am having a problem, which I cannot determine if this is a client or server issue.  But here are a few key points:

- Our test server running an MS FTPS service can be connected to with the FileZilla app. 

- When I connect with a client app I am writing, the control port connects fine and communicates,

- The handshake times out only on the passive connection handshake.
    I can see it is not the TCP/IP connect call that is timing out.
    It is in fact the handshake:  "result = wolfSSL_connect(m_dataSsl);" call that times out.

- I can use both FileZilla and the client app I'm developing to connect to a customer's server.

Therefore it would be something about this test server...  And yet, the FileZilla client app connects fine.

This also tells me it is not a firewall issue, And I have to assume it's something in the way WolfSSL lib is sending the handshake.

I have attached a WireShark log.  Lines 4 and 5 are the handshake for the control connection (port 990)
Line 37 is the client sending the hello for the passive data connection, however the server never responds.

Can anyone give me a clue to figure out why the server is happy with the handshake on the control port (port 990), but doesn't like the handshake on the passive data port (port range 20001 to 21000) ?

I have already confirmed that session resumption is disabled on our server.
Any advice is appreciated.

-Scott

Post's attachments

FTPS_Wolf_Library_VPN.pcapng 6.8 kb, 5 downloads since 2020-10-27 

You don't have the permssions to download the attachments of this post.
-Scott
<Code shown is not to scale>

Share

  • john
  • Moderator
  • Offline
  • From: Seattle, WA
  • Registered: 2011-11-14
  • Posts: 148

Re: FTPS data port failure.

Which version of wolfSSL are you using and how are you configuring it?

Your PCAP file isn't showing much with the passive connection. The client sends a hello message and the server is reseting both connections two minutes later-ish. Can you attach a successful handshake with your other client?

john's Website

Share

  • From: Texas
  • Registered: 2020-08-17
  • Posts: 63

Re: FTPS data port failure.

John,
One reason there isn't much to show is because there isn't anything happening.
The data channel socket read times out.  Then, when the app exits, the OS naturally resets the connections.

A proper connection handshake does occur on port 990, which is the control port.  You can see that on line #4.

I am not sure why the same context can connect to the control channel on port 990, but fails on the data channel, which is the port assigned by the server.  They are both the same IIS FTP server.

(Right now, my VPN is down. I'll get a FileZilla capture when connecting this server when it's back)

-Scott
<Code shown is not to scale>

Share

4 Reply by Scotty2541 (edited by Scotty2541 2020-10-30 12:25:50)

  • From: Texas
  • Registered: 2020-08-17
  • Posts: 63

Re: FTPS data port failure.

Now that the server is back up, here is the same communication using FileZilla that SUCCCEEDS in connecting to the server, while the WolfSSL "client hello" is unanswered.

In my original capture, is it because the cipher is not acceptable, that the server never answers?
If so, which cipher worked in FileZilla?  And how do I enable that in WolfSSL?

I've done a lot of low level development in TCP/IP (and UDP, and ICMP), but know almost nothing about the secure layer protocol travelling on the TCP channel.

Post's attachments

FTPS_FileZilla_VPN.pcapng 13.68 kb, 1 downloads since 2020-10-30 

You don't have the permssions to download the attachments of this post.
-Scott
<Code shown is not to scale>

Share

  • john
  • Moderator
  • Offline
  • From: Seattle, WA
  • Registered: 2011-11-14
  • Posts: 148

Re: FTPS data port failure.

Thank you.

I don't see any reason for the server to not respond to the client in the Wireshark logs. The client sends pretty much the same hello message in both connections. As far as I can see, just the random is different, which is expected. Neither are trying to resume the session. Same cipher suites requested.

The server picked the same cipher for FireZilla as it used on the first wolfSSL connection (ECDSA-RSA-AES256-SHA384), so the request was acceptable. The server would send an alert if there wasn't a suite match.

Really, TLS is just a decorator on your application's data. We try to keep the library transport agnostic for portability because many TCP/IP library APIs are radically different than the BSD style.

Does the server report any problems in its logs?

john's Website

Share

  • From: Texas
  • Registered: 2020-08-17
  • Posts: 63

Re: FTPS data port failure.

Thanks John,

Nope, I don't have access to the server logs.  The 'new guy' is controlling that, and I can't get access. 
I asked, and he was just looking in the IIS logs.

I don't know anything about MS FTPS server (if it's part of IIS, how it's installed, where it's configured...) so I couldn't help him by suggesting where to look.

He finally ripped it out, and installed the FileZilla server, and now it's functioning, so we are beyond that point for now. (until a customer tries to use that server for their installation)

Also, John, I have another question posted which I haven't gotten any help with.

How to control the protocols (and along the same line, how to control the ciphers... 'best practice' is to not use all 34 of the NIST ones, but reduce them to perhaps 10 or so)

https://www.wolfssl.com/forums/topic162 … erver.html

-Scott
<Code shown is not to scale>

Share