What's the version AWS SDK that supports TLS v1.2? - tls1.2

We're using AWS SDK .NET for getting files from AWS S3 storage. When the application was implemented a few years ago, the AWS was only supporting TLS 1.0. Now hopefully it's supporting TLS 1.2. I'd like to know which version and where I can download the library/packages. What's the minimum requirements for the .NET Framework? We're using the AmazonS3Client to handle the underlining connection to the S3 storage account.

Found the correct version that will be supporting the TLS 1.2.
https://aws.amazon.com/blogs/developer/upgrade-aws-sdk-for-net-for-latest-tls-protocols/

Related

Upgrading from Azure Storage SDK v6.0.0.0 to v12.4.2 for .NET Framework

I have a service that is referring to Azure SDK 3.0 in turn using Microsoft.WindowsAzure.Storage.dll of version 6.0.0.0. The service is built on .NET Framework and now when I want to to upgrade the Azure Storage SDK(Blobs, Common and Queues) to version 12.4.2, the library is published in .NET Standard
Per my understanding, I can't refer a .NET Standard library in a .NET Framework Library. I searched all over the internet but I couldn't find any way other than migrating my whole service to .NET Core.NET Standard.
Is there any other way to upgrade the latest version of Azure Storage SDKs?
Is there any other way to upgrade the latest version of Azure Storage SDKs?
Direct upgrade from version 6 to 12 is not possible as SDK version 12 is actually quite different than older versions (9 or below).
Firstly, now the SDK is split in many SDKs and there are different SDKs for each service (Blobs, Files and Queues). Thus you would need to reference different Nuget packages in your source code.
Secondly, there have been many breaking changes in the SDKs thus simply referencing the Nuget packages for version 12 is just not sufficient. You will need to rewrite the code unfortunately.

Does .Net Framework 4.8 support SNI?

I'm making an HTTPS call over TLS 1.2 with client certificates to another company using .Net Framework 4.8 and the handshake fails after the client certificate is sent. Their company support claims .Net framework does not support SNI using this page as reference https://www.ssls.com/knowledgebase/what-is-sni-technology/. However my network capture indicates it does, since it includes the "server_name" extension in the client hello..Net framework call with SNI extension The same call can be made successfully using python so there is evidence they are correct, but I can't find any definitive answer online regarding .Net Framework. How can we determine if the issue is their network or lack of support in our framework?
Edit: This website indicates there is support since 4.5 https://developer.awhere.com/api/server-name-indication-sni-support-requirements
.NET Framework don't care about SNI support, because .NET has no knowledge of it. Network operations in .NET Framewrok are built around a network stack and low-level API provided by operating system. If you were able to install .NET 4.8, then you are running your app on a modern client that certainly supports SNI. This means that the issue is elsewhere, but not in .NET Framework.
I can't find any definitive answer online regarding .Net Framework
and you won't find for reasons explained above.
The simple answer is no, it does NOT, not in NetStandard 2.0 either.
But it does with netcore-5+.
Prior to that, while it supported client connections, it did not support customized selecting of the TLS-certificate based on SNI prior to netcore-5.
You could do it prior to that with the StreamsExtended library, though.
However, that's not part of the official .NET Framework, but a 3rd party library.
So no, the full .NET framework does not support that at all.

How do I determine whether I need to upgrade the dot net framework given change to TLS version?

MYOB has advised that as of 30th September 2018 the MYOB API will no longer accept connections using TLS1.0
I have a Winforms application which connects to MYOB Accountright via the API using the SDK
I am wondering if there are any specific changes that I need to make to an application that I released 2 years ago.
I asked on the developer forum and was told that if my code uses TLS1.0 I need to change it.
From this question about determining the dot net framework I am thinking that I need to check the framework MYOB.AccountRight.SDK.dll uses.
Looking in my project I see that it is v4.0.30319
I opened MYOB.AccountRight.SDK.dll in notepad and saw NETFramework,Version=v4.5
From Stan Tarnovskly's blog I see
.NET 4.5. TLS 1.2 is supported, but it’s not a default protocol. You
need to opt-in to use it. The following code will make TLS 1.2
default, make sure to execute it before making a connection to secured
resource: ServicePointManager.SecurityProtocol =
SecurityProtocolType.Tls12
You don't want to be using TLS 1.0 or 1.1 these days.
This doc has some best practices and also several references to the upgrade path you should be looking at: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
We recommend that you:
Target .NET Framework 4.7 or later versions on your apps.
Target .NET
Framework 4.7.1 or later versions on your WCF apps.
Do not specify
the TLS version. Configure your code to let the OS decide on the TLS
version.
Perform a thorough code audit to verify you're not
specifying a TLS or SSL version.

SignalR support in .NET 4

Does SignalR support .NET 4.0. Or is it support only from .NET 4.5 upwards. Is there any link which provides with minimum requirements for SignalR.
This is not the case any more, and the 2.x releases require .NET 4.5.
https://github.com/SignalR/SignalR/issues/1723
The last .NET 4.0 support for SignalR is version 1.2.2. Version 2 only works with .NET 4.5
Open the NuGet Package Manager Console and type:
Install-Package Microsoft.AspNet.SignalR.Client -Version 1.2.2
Install-Package Microsoft.AspNet.SignalR -Version 1.2.2
This will install the SignalR (Client and Server) in your selected project (web project) automatically.
Yes .NET 4.0 supports SignalR. The minimum requirements:
*Visual Studio 2010 SP1
*Since template installer is not available in VS2010 you need to install SignalR NuGet package
One thing to watch here is client/server .Net versions.
Most people know (but it's worth repeating) signalR can be hosted on Windows 2008R2 upwards. Windows 2008R2 has IIS7 and thus when hosted on IIS7 signalR cannot use WebSockets (as the old Windows http stack has no support for WebSockets). So that's ServerSentEvents or LongPolling. Not great for performance.
Windows 2012 upwards (and thus at least IIS8) offers support for WebSockets, which gets the amaziong C10K perf we're all after.
Now the interesting bit.
.NET clients.
If you only care about the browser skip this bit.
Any .Net clients that connect to a signalR back-end MUST use
Windows8 upwards to use WebSockets The Microsoft networking stack (for
.Net) in Windows7 does not contain WebSockets.
So don't use signalR with WebSockets if your client is Windows7.
OR... like us you'll need to use a custom WebSocket stack coupled with WebClient to handle the http handshake.
Hopefully this will help someone else!
You can download entire web stack from codeplex and SignalR from github and compile it under .net4.0
There is one sample project at http://www.bluelemoncode.com/2013/02/default.aspx
It is good SignalR sample and working vs 2010 sp1 and .net framework 4.0. working properly.
http://www.bluelemoncode.com/file.axd?file=2013%2f3%2fSignalR_OneOneChat.zip
The minimum requirements for SignalR is described here,
Which means your client can be WinForm/WPF application running on Windows XP.

Which version of Mongodb should I use?

I'm using Meteor on my ubuntu 10.04 server, and I'm wondering which version of Mongodb I should use?
I do not see it in the documentation.
Meteor ships with MongoDB 2.2. But you should be able to connect to any version of MongoDB that version 1.1.5 of the JavaScript MongoDB driver supports.
The driver's docs don't tell us what versions it supports. But Mongo's wire protocol has been fairly stable, so I'd expect older versions of MongoDB to work well. Reports appreciated.

Resources