Closed cluetjen closed 5 years ago
This is probably the same problem as #311. The solution suggested there, to disable TLS session resumption on the server side, is not really an option because it would make data connections hijackable by an attacker. The only secure way to do passive FTPS is using TLS session resumption. ProFTPD and VSFTPD default to using it, too.
TLS session resumption? How hard is that to implement?
I think you should try to get in contact with the Microsoft team. I'm not the TLS specialist but it seems that it's not possible because the underlaying SslStream does not expose an api that would allow it.
Any updates on this issue? Is this a problem with SslStream in .NET Core that this library can't workaround? Or is there something else we can try? We're currently being hit by this issue after moving our code from Windows to Linux.
Is this a problem with SslStream in .NET Core that this library can't workaround?
It seems to be an SslStream issue. There seems to be simply no api available that allows to reuse an existing session and on windows this is done "magically". (s.a. https://github.com/dotnet/corefx/issues/33506)
If you can suggest a fix it's possible. We can't fix something impossible.
On Wed, Feb 27, 2019, 9:09 PM Christoph Lütjen <notifications@github.com wrote:
It seems to be an SslStream issue. There seems to be simply no api available that allows to reuse an existing session and on windows this is done "magically". (s.a. dotnet/corefx#33506 https://github.com/dotnet/corefx/issues/33506)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robinrodricks/FluentFTP/issues/347#issuecomment-467910896, or mute the thread https://github.com/notifications/unsubscribe-auth/AGe6Kt04hrqU9ennu9NDMkZuaW5u5_5kks5vRqakgaJpZM4Yeoyx .
I'm closing this. If there is a way to solve this, I'd appreciate the know how. We can re-open this thread once a solution emerges.
Is this now broken on all platforms @robinrodricks with the security updates or is this still only problem on Linux?
Can confirm this has spread to Windows world too. Since we applied latest windows updates, we are no longer able to upload using TLS, Explicit . Same error about reusing connection.
Disabling Filezilla "reuse tls session" is not an option for us.
hoping to see fixes soon.
Is this now broken on all platforms @robinrodricks with the security updates or is this still only problem on Linux?
I am on Windows 11 and still have the same problem. .NET team claims it's Windows/Linux issues but at this phase I think it's .NET issue. I understand that FluentFTP team probably can do nothing about this unless they implement SSL on their own.
@robinrodricks,
I'm closing this. If there is a way to solve this, I'd appreciate the know how. We can re-open this thread once a solution emerges.
The FTPS-Connection-using-GnuTLS seem to be the official fix now, isn't it?
@i3v
The FTPS-Connection-using-GnuTLS seem to be the official fix now, isn't it?
No. The "official" fix is for Microsoft to fix this. Win 11 is therefore the fix, in the end.
FluentFTP.GnuTLS is yet another attempt to mitigate the problem (for those find this acceptable) by providing a TSL Session Resume capable stream.
Others will need to accept that this is unfixable without changing the base premises.
It's not FluentFTP failing to correctly reuse the TLS session, it is the underlying MS SslStream.
MS fixed it but "requests" you to migrate to WIN 11 / .NET 8 (unsure) to enjoy the fix.
A previous user said:
I am on Windows 11 and still have the same problem.
Need more proof of this. Default protocol settings disable TLS 1.3, thus to really succeed you need to change the default to include TLS 1.3, we disabled it to avoid the endless issues caused by the abortive attempts to use TLS 1.3 (with session resume failure).
@FanDjango ,
Win 11 is therefore the fix, in the end.
Actually, I'm currently more interested in Android, PhilippC/keepass2android/issues/1617 in particular.
The FluentFTP.GnuTLS do have some known limitations, but it should work on any OS, regardless of that Microsoft fix, shouldn't it? (Well... OK, I do agree it's probably more a workaround than the real fix.)
MS fixed it but "requests" you to migrate to WIN 11 / .NET 8 (unsure) to enjoy the fix.
AFAIU from dotnet/runtime/issues/22977 and dotnet/runtime/pull/64369, they did something in 7.0 (I'm really not sure what exactly). This blog post also advertises "TLS Resume" getting fixed for Linux in dotNET 7.0. AFAIU, they say that they made the necessary changes for it to work automatically on Linux, just like it works on Windows (note that Windows 11 is not mentioned, so I'd assume they mean any Windows).
I'm really not an expert in this, but from dotnet/runtime/issues/85113 + dotnet/runtime/issues/84136 it looks like:
So... They say it should just work with dotNET7.0 , even without FluentFTP.GnuTLS... Interesting. Am I missing something, is there any evidence that Windows 11 fixes this?
@i3v
Of course things might have progressed since we introduced FluentFTP.GnuTLS as a possible alternative for some use cases.
To be honest, I myself have not been following the developments, as things concerning TLS 1.3 and session resume have quitened down somewhat, so I am not totally up-to-date on this.
FTP OS: Windows 10
FTP Server: FileZilla Server Windows 10
Computer OS: Ubuntu 16.04 (WSL Win 10), Ubuntu 18.04 native
When FluentFTP tries to create a data connection to an FTPS server that requires that the data connection ssl session equals the control session this connection will fail becaus it's a different session.
Test code used
Test result is:
Logs :
FileZilla server logs:
Steps to reproduce:
For completeness...