Can't connect to Windows Server 2012 (IIS 8) FTP when using

[botg]

Yes, please send me a pm with the necessary login credentials.

[botg]

Thanks. This definitely is a server problem, I managed to reproduce it using FileZilla and both the GnuTLS and OpenSSL command-line clients.

At the end of a TLS session, the party wishing to close the connection must send a closure alert over the encrypted channel. This is needed to distinguish between an orderly end of the session and an attacker dropping connections.

Your server fails to handle this closure alert, as clients I've been using GnuTLS (tested versions 2.8.6, 2.8.12, 3.0.0, 3.1.0, 3.1.13, 3.2.0, unreleased master) and OpenSSL 1.0.1c. Upon seeing the closure alert, it fails the transfer with "550 The supplied message is incomplete. The signature was not verified." and deletes the complete file.

Worse, if the client is killed, your server doesn't even recognize this and says the transfer has been successful. It's as if the server is actively trying to be insecure.

There is nothing here I can do, this definitely is a server problem. If you can prove [*] me otherwise, I'll send you 100 EUR for your trouble.


[*] The proof involves writing two patches, one for OpenSSL, one for GnuTLS

[eXpress]

Thank's for the info.

Does Microsoft know about this behaviour or does anyone know a server side workaround?

[j.maletzky]

@Site Admin

This definitely is a server problem, I managed to reproduce it using FileZilla and both the GnuTLS and OpenSSL command-line clients.

Thanks for your efforts.

There a two questions:

1. If you know wthat's happening, why don't you help your users and provide a workaround in Filezilla?
2. Can you explain, why this is not happening, when disabling TLS 1.2 on the server AND change cipher suite priority to
TLS_RSA_WITH_RC4_128_SHA on top of the list of the server? Looks like there are some more problems.

PS: Documentation for TLS configuration of Windows
http://blogs.msdn.com/b/kaushal/archive ... l-tls.aspx
http://www.burbageitsolutions.com/blog/ ... r-200.html
https://www.nartac.com/Products/IISCrypto/

Thanks in advance
Joerg

[botg]

1. If you know wthat's happening, why don't you help your users and provide a workaround in Filezilla?

Not ending the session with a closure alert is not only a security vulnerability, there are servers which require the connection to be properly closed.

2. Can you explain, why this is not happening, when disabling TLS 1.2 on the server AND change cipher suite priority to
TLS_RSA_WITH_RC4_128_SHA on top of the list of the server? Looks like there are some more problems.

No, I don't have access to the IIS sources.

[j.maletzky]

Not ending the session with a closure alert is not only a security vulnerability, there are servers which require the connection to be properly closed.

Agreed.

I think the best solution is to give your users a choice. Don't force your users to work with TLS 1.1 or 1.2.
These protocols seem not so well understood like TLS 1.0.

Let Filezilla use TLS 1.0 as default protocol and if users want to use TLS 1.1 or TLS 1.2,
give them a way to choose it per Filezilla settings.

That would be really helpful for your users.

Greetings
Joerg

[rossh]

Not ending the session with a closure alert is not only a security vulnerability, there are servers which require the connection to be properly closed.

Agreed.

I think the best solution is to give your users a choice. Don't force your users to work with TLS 1.1 or 1.2.
These protocols seem not so well understood like TLS 1.0.

Let Filezilla use TLS 1.0 as default protocol and if users want to use TLS 1.1 or TLS 1.2,
give them a way to choose it per Filezilla settings.

That would be really helpful for your users.

Greetings
Joerg

Yes, I agree 100%.

[gbaotic]

Not ending the session with a closure alert is not only a security vulnerability, there are servers which require the connection to be properly closed.

Agreed.

I think the best solution is to give your users a choice. Don't force your users to work with TLS 1.1 or 1.2.
These protocols seem not so well understood like TLS 1.0.

Let Filezilla use TLS 1.0 as default protocol and if users want to use TLS 1.1 or TLS 1.2,
give them a way to choose it per Filezilla settings.

That would be really helpful for your users.

Greetings
Joerg

Yes, I agree 100%.

As j.maletzky and rossh have said, please find a way for us IIS 8 users to use FTPES with FileZilla.
This bug effectively renders FileZilla unusable for us, even though the problem may be or is on Microsoft's side.
I can't picture myself using any other FTP client, and would really love if you would provide a workaround to this issue.

[Ferroto]

As FileZilla is still unusable for me due to this bug I also would appreciate a workaround very much.

I don't have the technical insight to be able to tell if this really is a big bug in the IIS 8 FTP server or if it is more likely that there are some more/other problems in the FileZilla Client that lead to this behavior with IIS 8 (I'm concerning this as FileZilla is currently the only client I know that fails with IIS 8 and TLS which I find a little strange)...

But from what I understand in this thread a workaround would very well be possible but would endanger compatibility to other servers and would not be ideal for the security as well as connection loss management.

So why not simply adding a check box somewhere in the advanced Site Manager settings of a site "This site runs IIS 8 with TLS" which would prevent FileZilla sending this closure message which should cause this.

As said before, just for the sake of usability I would very much appreciate something like that.

[pdxgirl503]

I'll throw my hat in the ring here. I am experiencing this issue, as our company uses Microsoft Azure extensively for hosting our applications, which, as a cloud platform, is fantastic. However, it does suffer from this issue. I was initially using FileZilla to upload our website, but after this fiasco I've switched to my old standby, WinSCP, and lo and behold it has this same issue (though a different error message). The forums on that end blame this on both WinSCP and GnuTLS.

I have no idea and frankly don't care who's fault it is, I just want it fixed. That being said, it does seem to point the finger at Microsoft not following standards... And with Azure, there are no changes that can be made as far as the FTP/FTPS is concerned. As much as I don't want to, I'm going to have to use non-encrypted FTP for now. I really don't want to keep installing FTP clients until I find one that works.

PDXGIRL503

[j.maletzky]

Heads up!

There is a solution for all IIS 8 FTPS users:

WinSCP 5.2.5
http://winscp.net/eng/download.php

In WinSCP 5.2.5 you can select the TLS version for a session.

Configure TLS 1.0 as "Maximum TLS/SSL Version" in the Advanced site Settings dialag
of a session and everything works fine.

Useful workaround!!!

Would be nice, if the Filezilla programmers would give their users the same choice too.

Greetings
Joerg

[pdxgirl503]

Awesome, thanks! I thought I was using the latest version.

Would also be nice if Microsoft had the latest TLS version on their flagship Azure product (which I otherwise love as a platform).

PDXGIRL503

[manonthemoon]

Any update on this? I am getting this now, months after the other user. Might FileZilla offer support for the SHA1 signature algorithm? Uploads work fine on Core FTP but my users have FileZilla.

[botg]

This is a bug in IIS, only Microsoft can resolve this by fixing IIS.

[manonthemoon]

That doesn't make sense to me, sorry. Perhaps you are correct, but again, it works just fine in Core FTP. Even if a bug exists within IIS, can't you communicate with the server in the same manner as Core FTP has done? Why does it work fine with their software (if you know)? You could even make an entry in the list of server choices (instead of auto-detect) labeled "Windows 2012".