FluentFTP: 39.0.1 - Authentication failed because the remote party sent a TLS alert: 'ProtocolVersion'.

Got a log? Certificate validation is not accepting the certificate of the server. But a log would help.

Following code is missing in my function:

.Config.ValidateAnyCertificate = True

Now it works fine

@MyKeySoftMK buddy… Computer OS: Windows 10 / Visual Studio 2022 This is what you filled in.

Maybe I should have been more clear, this place is to fill in the details about the computer that is RUNNING FluentFTP. Even I had no idea you were on Win2012.

My developer machine is Windows 10 - and on this machine is it not working. So my information to you, that I use Windows 10 is right. In the beginning i didn´t know that it is important, that I will it use on Window 2012. I didn´t understand the parts that you use to connect via TLS1.3. But in the meantime i investigate and understand how all works together.

Sorry for this missunderstanding

@JosHuybrighs I have testet the SSH.NET - but they didn´t work. Only FTPS is allowed

@robinrodricks I find this actual project in github https://github.com/whSwitching/TLSHandler - is it possible to implement it in your FluentFTP Project? So i can imagine that you are not OS depend was TLS 1.3

@robinrodricks I did some further TLS1.3 tests against my Synology FTP server, added the master GitHub version of the FluentFTP project to my Visual Studio solution, and observed the following:

• TLS session negotiation (Client Hello, Server Hello, Keys and Certificate exchange, …) is always successfull.
• When m_stream.ActivateEncryption returns, there is still 86 bytes of unread data in m_stream.
• The next Execute("USER " + userName) then fails with ‘Stale Data’.

I took a look at the stream data of the session negotation using Wireshark, and see there that the FTP server responds with 4 application data records, immediately followed by 1 other application data record. I am not sure, but what I understand from TLS 1.3 is that the first 4 records are used for the session negotiation. I debugged the code for checking stale data and what I see is that the unread data corresponds with the 5th application data record as I see it in Wireshark.

When I configure _ftpClient.StaleDataCheck = false, the connection is successfull and further data transfer (list folders, etc.) is OK. So it looks like the data is required and I assume it will, after the session activation, be consumed by sslstream (sChannel). So, my question: is the check for ‘Stale Data’ correct in FluentFTP when using TLS 1.3? The reason why I ask is because I saw this code in ConnectModule.cs:

#if NET50_OR_LATER
			if (protocol == SysSslProtocols.Tls13) {
				client.StaleDataCheck = false;
			}
			else {
				client.StaleDataCheck = true;
			}
#endif

I am using .NET6

Here is my application Configuration

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <RootNamespace>MYKEY.FxCore.FluentFtp</RootNamespace>
    <TargetFramework>net6.0-windows</TargetFramework>
    <Platforms>AnyCPU;x64;x86</Platforms>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\FluentFTP\FluentFTP.csproj" />
  </ItemGroup>

</Project>

The exexption will come up in \Streams\FtpSocketStream.cs in line 1128:

m_sslStream.AuthenticateAsClientAsync(targethost, clientCerts, sslProtocols, Client.ValidateCertificateRevocation).Wait();

Win32Exception: Die angeforderte Funktion wird nicht unterstützt.

Die angeforderte Funktion wird nicht unterstützt.

And they come from DirectCast(ex, FluentFTP.FtpInvalidCertificateException).InnerException.InnerException.Message

I have a similar problem with the FTPS server on my Synology NAS after I updated the NAS to DSM 7.0. I don’t know which FTP deamon is being used there, but it supports TLS1.3 and TLS1.2. Same error in the log when I let FluentFTP negotiate TLS:

Status: There is stale data on the socket, maybe our connection timed out or you did not call GetReply(). Re-connecting...

Important: FluentFTP is then not reacting correctly because it seems to invoke connect() itself in a loop. There is no way to get out of this loop except by counting the attempts in the callback for the host key and then not accepting the key.

1. I can get rid of the error (and connect successfully) by setting the following: _ftpClient.StaleDataCheck = false; That works but doesn’t give me a comfortable feeling. I also don’t know whether the connection is now TLS1.3. I can’t see anything in FluentFTP that informs me about the negotiated protocol. But maybe I overlooked something.

2. I can also get rid of the error by forcing TLS1.2, but that is not what people want to do.

I can only again stress the importance of having full TLS1.3 support in FluentFTP. Is it still true that this is something that is not correct in .NET? That seems so strange. Can someone point me to where it is stated that there is an issue in .NET?

I am using FluentFTP 39.2.1.

Sorry - i cann´t give you a reply now. Our customers FTP-Server is down till Tuesday. On Wednesday i can try again. Then I will send you the result

Thanks for your work. Here is the log of your new BETA1-Version

_ AutoConnect()

AutoDetect(True, False)

Connect() Status: Connecting to x.x.x.x:21 Response: 220 NASFTPD Turbo station 1.3.6 Server (ProFTPD) [::ffff:10.1.10.6] Status: Detected FTP server: ProFTPD Command: AUTH TLS Response: 234 AUTH TLS successful Status: There is stale data on the socket, maybe our connection timed out or you did not call GetReply(). Re-connecting… Status: Disposing FtpSocketStream… Status: Not sending QUIT because the connection has already been closed. Status: Disposing FtpSocketStream…

Connect() Status: Connecting to x.x.x.x:990 Status: Disposing FtpSocketStream…_