2

Let me first say, I know XP is bad and dead.

That said, I was wandering if a software written using .NET could make TLS 1.0 connections that use the TLS_RSA_WITH_AES_128_CBC_SHA when running on Windows XP?

Or alternatively, Is there any secure protocol+cipher that can be used by a .NET app running on Windows XP to contact a web server over https and if so what need to be done to allow that?

Where do the ciphers come from when using a .NET app? Is it part of the .NET Framework? Or does the framework itself use the ciphers provided by the OS?

3

For TLS, the .NET framework utilises the underlying TLS API exposed by the operating system. It does not re-implement the TLS protocol in managed code.

The operating system's TLS stack pulls cipher support from the local cryptographic provider. In XP, this is CAPI (Cryptographic API) which does not support AES. In later versions of Windows the CAPI was replaced with CNG (Cryptography Next Generation) which does support AES.

Unfortunately there's nothing you can do about this if you want to use the native TLS provider or the native HTTP classes in the .NET Framework. You'll have to change over to a managed implementation which includes such features, though I'm not aware of any off-the-shelf product that would help you here.

1

Or alternatively, Is there any secure protocol+cipher that can be used by a .NET app running on Windows XP to contact a web server over https and if so what need to be done to allow that?

As I understand it the least bad option for the windows SSL/TLS stack on XP is tls_rsa_with_3des_ede_cbc_sha . 3DES is considered to have an effective strength of ~112 bits which is generally considered sufficient.

A bigger issue is that the CBC ciphersuites especially in older versions of tls are considered vulnerable in some applications (particulally applications like web browsers where an attacker can exert a lot of influence on the traffic). https://crypto.stackexchange.com/questions/1078/how-can-cipher-block-chaining-cbc-in-ssl-be-attacked https://crypto.stackexchange.com/questions/1078/how-can-cipher-block-chaining-cbc-in-ssl-be-attacked https://crypto.stackexchange.com/questions/27856/poodle-attack-on-tls-1-2

  • would it make sense to prefer to work with plain HTTP (knowing that the makes the communications with XP stations vulnerable) over installing a cipher suite that might compromise the server itself ? – epeleg Jun 2 '16 at 10:05
  • Note that the "112-bit effective strength" is due to a meet-in-the-middle attack which requires approximately 512PiB of RAM-speed storage as a tradeoff. – Polynomial Jun 2 '16 at 10:06
  • @epeleg TLS with 3DES-CBC is significantly better than no transport security at all. The use of a weaker cipher would not compromise the server itself; I'm not sure where you got that idea from. – Polynomial Jun 2 '16 at 10:07
  • I thought that there is a server side code to those cipher suite and that some of them are broken in this sense. it seems to also be implied from what Peter green wrote : "A bigger issue is that the CBC ciphersuites especially in older versions of tls are considered vulnerable in some applications". but maybe I miss understood... So I would like to clarify - the problem is not with having the cipher suite installed but with having clients that use it? (i.e. communications can be hacked and not the server itself?) – epeleg Jun 2 '16 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.