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?

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
1
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

Improve this answer
4
  • 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
    Commented Jun 2, 2016 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
    Commented Jun 2, 2016 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
    Commented Jun 2, 2016 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
    Commented Jun 2, 2016 at 11:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .