WinSCP transfers fail with Windows Server IIS FTP+TLS

A security patch for Windows Server IIS earlier this year broke FTP+TLS file transfers with WinSCP. Connections and directory listings would work, but file transfers display the error:

"Copying files to remote side failed. The supplied message is incomplete. The signature was not verified."

Trying older and beta versions of WinSCP I have found two workarounds:

1) Use WinSCP version 4.3.3, this is the newest verion that still works.

2) Use WinSCP version 5.2.4 beta, with the new maximum TLS/SSL version setting set to 'TLS 1.0'. This also works.

It appears the Microsoft patch has broken compatibility with TLS 1.1 and TLS 1.2.

The Filezilla client also does not work any more (I tried it). I read that the GNU SSL library does not work with Windows Server IIS FTP+TLS any more either.

I was testing with Windows Server 2012 and IIS 8 with all Windows Update patches as at Oct 2013. I tested only FTP with explicit TLS.

Aaron.

I was testing this only to find that IIS does not support TLS 1.1 and TLS 1.2 by default. One has to enable this in registry (<invalid hyperlink removed by admin>). They probably know why they do not enable this by default...

Just a note for people who find their way here wondering why MS did this.

MS intentionally disabled TLS 1.1 and 1.2 by default because most browsers didn't have TLS 1.1 or 1.2 enabled, and they wouldn't fall back to TLS 1.0 right. Specifically, Firefox (<invalid hyperlink removed by admin>) didn't enable TLS 1.1 and 1.2 until at least version 24 (August 2013) and in version 23 even if you enabled it it would not fall back to TLS 1.0 from TLS 1.1 or higher. As I recall this wasn't unique behavior for Firefox, either.

Thanks for sharing the information.

Also see "FIX: "The supplied message is incomplete" error when you use an FTPS client to upload a file in Windows 8, Windows Server 2012, Windows 8.1, or Windows Server 2012 R2":
https://support.microsoft.com/en-us/topic/fix-the-supplied-message-is-incomplete-error-when-you-use-an-ftps-client-to-upload-a-file-in-windows-0da7e32a-509f-c2d5-7a44-2d1d34ef817a

This has been documented:
https://winscp.net/eng/docs/message_supplied_message_incomplete

First, thank you WinSCP for the excellent product, which is why I choose to post this information to your site instead.

Solved:

IIS FTP Explicit SSL TLS 1.2 Windows Server 2008, 2012, 2016 using WinSCP.

My biggest challenge was enabling SSL 1.2 for the server websites, but still have a fully functional FTP SSL Server.

550 The supplied message is incomplete. The signature was not verified.
This error can occur when connecting to an FTPS server and files are being uploaded or downloaded or a list of files is being retrieved.

Difficult to figure out, but is such a simple fix.

First of all, enabling TLS 1.2 for the web services required editing the registry. You can create a reg file from import using the below between the lines. Make sure you reboot the server after importing the reg changes.

----------------------------------------------------------------------------------------
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000

----------------------------------------------------------------------------------------

Next the article that I searched for high and low that finally solved my FTP Server issues with the 550 The supplied message is incomplete and error the signature was not verified.

Thanks to:

https://help.2brightsparks.com/support/solutions/articles/43000336175-550-the-supplied-message-is-incomplete-the-signature-was-not-verified-

It simply works, I don't see it as a bug in Windows Server as much as an undocumented TLS 1.2 step, I do see it as a configuration change that needs to occur that should have been better documented.

This issue must be fixed on the Windows computer that is running the FTPS server:

- Run the Group Policy Editor (gpedit.msc)

- Go to Local Computer Policy --> Administrative Templates --> Network --> SSL Configuration Settings

- Move TLS_RSA_WITH_RC4_128_SHA to the top of the priority list. How to modify this setting:

- Open a blank notepad document.

- Copy and paste the list of available suites into it.

- Arrange the suites in the correct order; remove any suites you don't want to use.

- Place a comma at the end of every suite name except the last. Make sure there are NO embedded spaces.

- Remove all the line breaks so that the cipher suite names are on a single, long line.

- Copy the cipher-suite line to the clipboard, and then paste it into the edit box. The maximum length is 1023 characters.


The above registry import takes care of this: - Enable TLS 1.1 and/or TLS 1.2 on servers running Windows 7 or Windows Server 2008 R2. Refer to Microsoft Knowledge Base Article 2588513 to use the automated Microsoft Fix it solution to enable or disable this workaround for TLS 1.1.


- Reboot Windows. This is important.


Verified the FTP Client can connect and transfer files:
WinSCP, New Site, File Protocol = FTP, Encryption = Explicit, Advanced Settings, Connection, FTP Passive Mode Must Be Checked, TLS/SSL, Minimum TLS/SSL = 1.2 and Maximum TLS/SSL Version = 1.2.

Note if your FTP Server is behind a firewall appliance, you must set the outside IP in the IIS, Sites, FTP Site, FTP Firewall Support

Thanks for sharing your solution.

In my testing, I have determined that Microsoft considers TLS_RSA_WITH_RC4_128_SHA a strictly SSL2, SSL3, TLS 1.0, and TLS 1.1 cipher suite.

RC4 is not enabled by default in Windows.

My concern here is that in order to use true TLS 1.2 WITH TLS_RSA_WITH_AES_128_CBC_SHA256, they are expecting the client to announce the correct encryption capabilities of TLS 1.2 in both inner and outer.

I suspect this an attempt to identify the correct range of the SSL Cipher Suites being offered in reply from the server to the client based on the server having to reply with a number no higher than what the client initially offered.

My major concern with WinSCP is that it is able to connect to IIS using TLS 1.2, but only using TLS_RSA_WITH_RC4_128_SHA. (connects, uploads, downloads)

TLS_RSA_WITH_RC4_128_SHA is not normally enabled by default for security reasons.

https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1709

TLS_RSA_WITH_RC4_128_SHA is sometimes manually added to the SSL Cipher Suite Order in Group Policy to enable it. However, this now enables a weaker non pci compliant cipher.

From RFC, what I have learned is this:
https://trac.ietf.org/trac/tls/ticket/25

A TLS 1.2 client who wishes to negotiate with such older
servers will send a normal TLS 1.2 ClientHello, containing
{ 3, 3 } (TLS 1.2) in ClientHello.client_version. If the
server does not support this version, it will respond with
ServerHello containing an older version number. If the
client agrees to use this version, the negotiation will
proceed as appropriate for the negotiated protocol.

Note: I believe the issue with WinSCP is that it may be sending {3, 0} in the ClientHello and that causes the server to respond with the lower RC4 cipher.

If a TLS server receives a ClientHello containing a version
number greater than the highest version supported by the
server, it MUST reply according to the highest version
supported by the server.

Whenever a client already knows the highest protocol known
to a server (for example, when resuming a session), it
SHOULD initiate the connection in that native protocol.

TLS clients that wish to negotiate with older servers MAY
send any value {03,XX} as the record layer version
number. Typical values would be {03,00}, the lowest version
number supported by the client, and the value of
ClientHello.client_version. No single value will guarantee
interoperability with all old servers, but this is a complex
topic beyond the scope of this document.


What I am thinking here is that WinSCP allows you to adjust the min and max TLS SSL versions.
However, does this properly affect the ClientHello.client_version {3,3} when both the min and max are set to TLS 1.2.

1. Does it handle it correctly on initial connect?
2. Does it handle it correctly on a reconnect?
3. Does it handle it correctly when uploading files to IIS?

Answer #1 = WinSCP only connects to FTPS when RC4 is enabled on server indicating {3,0} was negotiated.
Answer #2 = WinSCP only reconnects to FTPS with RC4 enabled indicating {3,0} was negotiated.
Answer #3 = WinSCP is unable to negotiate a connection to FTPS for file uploads unless RC4 is enabled on server, which indicates that it did not negotiate {3,3} for the reconnect / upload? Maybe the upload connect process is handled via another code function with old values?

#3 might also be caused by the data channel trying to open new communications in a lower RC4 cipher suite due to the client specifying {3,0} instead of {3,3} full TLS 1.2. Thus the connection fails because, RC4 is not enabled on the server by default or RC4 is disabled on the server.

Thanks for your post.
Can you a Wireshark capture of WinSCP showing how the connection fails? And an equivalent capture of another client that can connect?