1

I buit a c# application that uploads some values to a website like that:

NameValueCollection parameters = new NameValueCollection();
parameters.Add("variable", "value");

Client = new System.Net.WebClient();
byte[] result = Client.UploadValues("https://my.domain/script.php", "POST", parameters);

It worked, but now I get this exception:

The request was aborted: Could not create SSL/TLS secure channel.

I tried on another website and I don't have the error (also on google.com), then it seems to be the server, but maybe there's also a solution on the client side ?

EDIT: The client is using .net Framework 4.7.2, and is on windows (10 for me)

Entretoize
  • 2,124
  • 3
  • 23
  • 44
  • Which version of .NET are you using, and which version of Windows? It could be that the website that your code doesn't work with is using a TLS version that your program can't use. – Andrew Morton Mar 21 '23 at 17:18
  • Your question is almost a duplicate of [this one](https://stackoverflow.com/q/70083338/1178314), which has only a corner case answer. There is also this quite [old question](https://stackoverflow.com/q/2859790/1178314), with many answers, but most of them are obsolete and no more recommended as [stated here](https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls). – Frédéric Mar 21 '23 at 22:38

1 Answers1

0

Assuming you have checked the Web server certificate is valid, it seems likely you are in a case the client and the server haven't found a common ground to talk to each other. This means, they do not have any TLS (or SSL if one of them is very obsolete) version support in common, or if they have some, they do not have any ciphers suites in common.

If the Web server is public, you can use some online service like SSL Labs to get insights about which TLS versions and ciphers suites it supports. Up-to-date servers won't support anything lower than TLS 1.2. (With SSL Labs, do not stop at the summary which may tell "support TLS 1.3" without telling about other versions. The server may support other versions, see the "Protocols" section of the report for the full list.)

About what your client support, that is your job to determine what is it. Outdated .Net Framework clients won't support any better than TLS 1.1, or worst. Find out about your case in the .Net TLS best practices documentation. For ciphers suites, if your client runs under Windows, you can check the default list of supported suites for your version from the Windows Cipher Suites in TLS/SSL documentation. The list of supported suites can be altered through group policies.

The trouble can be the other way around : outdated server not supporting anything higher than TLS 1.1, and up-to-date .Net Framework or .Net Core client on an up-to-date OS, not supporting anything lower than TLS 1.2.

For security reasons, TLS 1.1 and lower have been disabled both on up-to-date clients and servers. The same happens to ciphers suites, many of them are no more supported on up-to-date clients and servers.

According to SSL Labs report, the Web site does support TLS 1.2 and 1.3, nothing less.

According to your edit, your application runs under .Net Framework 4.7+ and Windows 10. So, it should works by default, but your code, some dependencies or Windows settings, may have altered the default behavior.

Check the value of the static property System.Net.ServicePointManager.SecurityProtocol in your application. By example, check it right before querying the Web server.

If its value is something else than SecurityProtocolType.SystemDefault, especially if it downgrades the TLS version to TLS 1.1 or lower or SSL, find what changes it and fix it.

Or change it before your call, but that would be just a quick and dirty "hotfix".

Keep in mind that the trouble may be something else requiring more investigations, like ciphers suites. So, if everything looks right about ServicePointManager.SecurityProtocol, start investigating which ciphers suites your OS supports. By example, check if there is some hard-coded group policy restricting them a bit too much.

By the way, if you are using .Net Core or a not too old .Net Framework, the HttpClient class should be preferred over the WebClient class, as recommended by its documentation. (Until .Net 5, HttpClient was lacking synchronous methods for sending requests. So, if your code has to be synchronous and targets an older .Net than .Net 5, WebClient is then still a natural choice.)

Frédéric
  • 9,364
  • 3
  • 62
  • 112