I'm creating an app that is downloading some content from a HTTPS-based website (and POSTs something back). The web server is using forced encryption (TLS 1.2 with modern ciphers), so all browsers before Firefox 30 can't open pages from it. At all.
The app is written in C# using .NET 4.6 HttpWebRequest and all is working okay. But I want to add support for older Windows XP machines that are still alive, where only .NET 4.0 is available. Also it will be prefect if the app will work even in Win2000 with .NET 2.0, but it's more like a inreal dream. :)
Is it possible to add support for HTTPS requests to modern servers in .NET 2.0/4.0 app? May be via OpenSSL, Mozilla NSS or something such...
Related
We want to use C# to develop an MQTT device client which publishes events to IoT Platform on Bluemix (IoTP). Also, we want to use SSL Client certificate and token to connect. We are referring https://github.com/ibm-watson-iot/iot-csharp/blob/master/docs/CACertificate.md, however, we heard that .NET 4.5 is the only supported version for now. Since we have some applications currently running on .NET 3.5 sp1, we prefer to use it rather than upgrading those applications to .NET 4.5.
We heard the reason of .NET 4.5 is because IoTP depends on TLS 1.2. If that is the case, is it possible to m2mqtt(v4.0 framwork3.5) by replacing network communication with wolfssl(c++) or something else? We confirmed we could use TLS 1.2 in this way, but it fails to connect to IoTP because SSL certificate request doesn’t come from IoTP.
In summary, is there a way to use .NET 3.5 sp1 connecting to IoTP with using SSL Client certificate and token? Any comments or suggestions must be appreciated. Thanks.
I am working on a ASP.Net WebForms application. We are using PayFort's Start API for the payment process. The application is running fine on our local machine (Windows 10) but it shows following error when we try to make payment using their API on our deployment server (Windows Server Web 2008).
The client and server cannot communicate, because they do not possess
a common algorithm.
The documentation on their webpage (PayFort Start and SSL/TLS) states that they use Tls1.2 for the communication. Their API already contains the code to use Tls1.2 as Security Protocol
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
We've built the application on .Net framework 4.5 since Tls1.2 only supported by .Net 4.5 or later. Needless to mention, our server has .Net Framework 4.5 installed in it.
We've also added the registry values for Tls1.1 and Tls1.2 in the windows registry
Using the SSL Labs tool, we've also confirmed that there are atleast two Cipher suites supported by both servers (our server and PayFort's API Server) (https://api.start.payfort.com)
Cipher suites supported by PayFort's API Server
(Green outlined are those which are common with our server)
Cipher Suites supported by our server
I've also used the Nartac IIS crypto software and it's showing the following info as Best Practices
I'm not sure if it has anything to do with the problem or not, but here are the details of the SSL certificate installed in our server
Can anyone please point out that what we are doing wrong and what should we do in order to communicate with the desired server and make payment from the application deployed on our server as we are doing perfectly on our local machine.
I'm with the Payfort Start team. We've got a page here that helps describe this issue in more detail. Essentially, your API client (the library you're using to make the HTTPS request) has to support TLS1.2. The Start API will reject any request that doesn't support TLS1.2 at a minimum.
It would appear that the WebRequest does support TLS 1.1 and 1.2, but you have to turn them on manually. You can refer to this answer for the fix.
To verify that your client supports TLS1.2, you can send a GET request from your application to https://www.howsmyssl.com/a/check and read the response.
In cURL:
> curl -X GET https://www.howsmyssl.com/a/check
Returns:
{
given_cipher_suites: [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
"TLS_ECDHE_RSA_WITH_RC4_128_SHA",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
"TLS_RSA_WITH_RC4_128_SHA",
"TLS_RSA_WITH_RC4_128_MD5",
"TLS_RSA_WITH_AES_128_CBC_SHA",
"TLS_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA"
],
ephemeral_keys_supported: true,
session_ticket_supported: true,
tls_compression_supported: false,
unknown_cipher_suite_supported: false,
beast_vuln: false,
able_to_detect_n_minus_one_splitting: false,
insecure_cipher_suites: {
"TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA": [
"uses keys smaller than 128 bits in its encryption"
]
},
tls_version: "TLS 1.2",
rating: "Bad"
}
Look out for the tls_version at the end.
The problem was the Operating system. We were using Windows Server 2008 and we didn't realize the application need OS's protocol to communicate with other server. Since we have .NET Framework 4.5 installed and we were also using the code ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; to force application to use Tls1.2 (according to the requirement), hence believed that everything should work fine, but obviously this wasn't going to happen.
tl;dr; We installed Windows Server 2012 on the machine and the application is running fine now (as it should)
I hope this can clarify your situation a bit and help:
1 Confirm that app is running under .net 4.5 (or higher).
TLS 1.2 is supported in 4.5+. To get actual version of .net framework you app is running under: https://msdn.microsoft.com/en-us/library/system.environment.version(v=vs.110).aspx
2 Enable TLS 1.2 in Windows Registry.
I just found this link to be useful with enabling TLS 1.2 The client and server cannot communicate, because they do not possess a common algorithm
There's been a lot of news lately about the HTTP/2 standard, very similar to Google's SPDY.
It seems like most modern browsers support much of the functionality the finalized HTTP/2 draft lays out (see here, for example).
But, from the viewpoint of server side coding using ASP.NET and IIS, it's difficult to find much information from Microsoft about how this standard will be used in the .NET framework, especially with ASP.NET (see here).
What options are available for incorporating the technologies available through HTTP/2, in a solution currently using .NET framework 4 or above?
Also, has anyone found any news from Microsoft about if the System.Net namespaces and classes will be updated?
Sorry for the basic question formats - I'm new to web development, and just want to make sure I stay on track of new and emerging technologies.
2016-07-21:
HTTP/2 requires Windows 10 or Windows Server 2016 on the server side. Those operating systems ship with IIS 10. So far IIS 10 has not been made available for installation on older operating systems. Given past behavior it is unlikely it ever will become available on downlevel operating systems.
With SSL enabled (which is a requirement of the HTTP/2 protocol), IISExpress on Windows 10 will begin interacting with the browser using the updated protocol.
(https://weblogs.asp.net/scottgu/released-today-visual-studio-2015-asp-net-4-6-asp-net-5-ef-7-previews)
Given that HTTP/2 does not change any of the HTTP semantics I do not expect applications to do anything special to make use of that. It should work with any .NET version and any framework. I have not tried it, though.
February 2015:
For now you need a proxy server in front of IIS. Or a CDN which does HTTP 2. I expect all major ones to very quickly support it given that all browsers already support it.
The Win10 version of IIS will support HTTP 2 according to currently available Microsoft information.
I'm pretty sure the network BCL classes will be updated eventually given how much steam is behind HTTP 2. All clients and servers seem to be willing to support it very quickly.
Does Azure support the use of WebSockets for .NET, if so how can a Websocket connection be initiated and handled?
Web Sockets are now supported in Azure Web Sites. To use them, go to the site Configuration page in the management portal and turn on Web Sockets.
At the moment this isn't possible. You'll only get websockets when Azure (Cloud Services or Web Sites) supports .NET 4.5 on Windows Server 2012 (IIS8), which isn't the case at the moment.
Today .NET 4.5 is only available in Web Sites with Windows Server 2008 R2 (IIS7).
Note: Technically you can use other solutions (as opposed to IIS) to get websockets in your Azure application (like Pokein, SuperSocket, ...)
As Sandrino says this is not possible unless you have win8/2012 with .net 4.5.
However, that´s if you are running SignalR (or WebSockets in 4.5 of course).
We have been using websockets on Azure for quite some time now, and it is working really well.
You can try it at http://live.xsockets.net or our really simple playground http://xfiddle.net
Regards
Uffe
I would like to build a winform business solution using SiganlR, but I am not able to install .net 4.0 on the client machine. It looks like SignalR has a mininum requirement of .net 4.0. What is the best way to use SignalR from a winform and .net 3.5. I would like to include the send/receive message functions in the client application.
I will be hosting SignalR on IIS on my intranet using .net 4.0 on the server side.
Would it be possible to create and API (in .net 3.5) similar to pubnub C#? Can anyone point me in the right direction.
If you're not too scared of compiling your own stuff I have created a .net 2.0 compatible client library for SignalR. It's available right off my fork (https://github.com/robink-teleopti/SignalR) of SignalR.
At the moment I have no intent of making a pull request as I don't want to add that extra burden to the original project.
I have one more modification on my fork that can be good to know about. When having clients belonging to more than 20 groups I automatically switch to using POST instead of GET and I have made minor modifications on the server side to handle that part.
I backported the v1.x and v2.x SignalR clients to NET35. Available as NuGet packages here: http://www.nuget.org/packages/Nivot.SignalR.Client.Net35/
One of the authors of the SignalR project had a goal of using TaskParallelLibrary (TPL) that shipped in .NET 4. So I doubt any of the C# code from that project will run on .NET 3.5. Why not host a TCP or named-pipes WCF endpoint on the server and use normal .NET client callbacks? This is relatively easy if server is Windows Server 2008 with WAS or AppFabric.
If an older server you could host WebBrowser control and use SignalR javascript client library to handle signaling.
In another 6 months I'd bet on a native .NET 3.5 client library, but as the maintainers are full time MS employees I doubt they will have time to get to supporting legacy versions any time soon.