IIS 2008R2, SSL cipher issues, dropped connections

[Ross]

On IIS 2008 R2, with an SSL connection, with PCI compliant ciphers only, a variety of broken and dropped errors occur.

Server set to PCI compliant ciphers only (RC4 128, 3xDES 168, AES 128, AES 256).

On v3.6.0.2: wont connect at initial start up; server drops the connection with this error: An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed. i.e. no matching Cipher.

Note on 3.6.0.2, if we allow the non PCI ciphers, it does connect, but, then fails on upload transfers, with "invalid transfer" message in the log (i don't know which cipher its selected).

On older 3.53; with the AES ciphers in the top of the list, it will connect, but fails the file upload transfer. With RC4 cipher as the first choice (beast ordering), it fails outright and never connects.

[Ross]

I should clarify. The Server is the 2008R2 with the MS FTP server, and the client is on Win 7. The issue is talking to the MS server, file zilla client has issues.

[Ross]

I have done some cipher checking on the server. As thought, FileZilla client and MS FTP server in PCI compliant mode, cannot find a common cipher to use. FileZilla client needs to expand its available ciphers. Please see this forum post with all the details:

​http://forum.filezilla-project.org/viewtopic.php?f=2&t=27898&p=108700#p108700

[Ross]

Further research shows the error is that FileZilla now only specifies itself as TLS v1.0 in the TLS Transport Layer Version field, but at the inner message Client Hello version is set to v1.2. That's a logic error, and not valid per the spec.

Interesting that Older v3.63 Filezilla, (which almost worked, except for file uploads), did not make the version conflict mistake. Older 3.63, and 3.62 set the TLS to v1.2 for both version definition places.

[Tim Kosse]

Further research shows the error is that FileZilla now only specifies itself as TLS v1.0 in the TLS Transport Layer Version field, but at the inner message Client Hello version is set to v1.2. That's a logic error, and not valid per the spec.

That's allowed and encouraged behavior according to the TLS specifications.

The actual problem is with the used certificate signature algorithm which has a security margin of less than 128 bit. Due to the widespread use of said algorithm, it has since been reenabled in FileZilla 3.7.0.2