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://web.archive.org/web/20210927002032/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.
- Does it handle it correctly on initial connect?
- Does it handle it correctly on a reconnect?
- 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.
