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.
Related
I will try to keep this general, as I am seeking a general answer.
When I open the properties window of one of the references in my project in Visual Studio I see this runtime version: v4.0.30319
This reference is used in a project where the target framework is .NET Framework 4.7.1. And it works fine.
My project is communicating with a database, and I want to make sure that this communication will be utilizing the TLS version 1.2 protocol. As I understand it, this can be insured by having the project targeted against .NET 4.7 or above.
Here is my question: if I have a project with a reference, which have a target framework that is lower than .NET 4.7, will this ruin my goal of using a TLS protocol of version 1.2?
How can I make sure that my reference is up to snuff? The runtime version written above, is not suggesting that this reference has a .NET Framework of 4.7 or above, or does it?
The .NET (Standard) framework receives automatic updates via the Windows Update service. Does .NET Core Runtime have the same/similar functionality? If I install a .NET Core Runtime and .NET Core application on a server should I be the one taking care to apply the latest minor patch?
My question is primarily focused on potential security issues which are then remedied by subsequent minor version update.
On Windows, the currently supported versions of .NET 5, .NET Core 3.x and .NET Core 2.x can now receive automatic updates. See the .NET Blog post announcing this for more information.
It is in an opt-in service, so on a client OS you would need to enable Receive updates for other Microsoft products when you update Windows.
On server OS the updates are managed via Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM). See the section for IT administrators on the MS blog for detailed instructions.
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.
We have recently taken on support of a web application that was written many years ago and targeted v1.1 of the .net framework. It runs on Windows Server 2003/IIS 6 environment.
After looking at the configuration of the site in IIS the target framework is set to 2.0.
Given that extended support for .net 1.1 will cease in October of this year (http://support.microsoft.com/lifecycle/?p1=1249) I am trying to ascertain whether the site will still use any of the .net 1.1 framework assemblies given that the application is built and compiled in Visual Studio 2003.
I am assuming this is the case because although ASP.net 2 is set as the target framework
in IIS (and therefore the aspet_isapi.dll invoked is the .net 2 one etc) the assembly is a .net 1.1 assembly and will therefore still use the 1.1 framework. However, is this assumption actually true?
The website only has another year or so to live before being replaced by a new solution entirely so I would prefer not to upgrade it if possible and run the risks such changes bring with them.
However, we obviously can't run something on an unsupported version of the framework if any element of if that framework is actually being used.
Any thoughts would be appreciated.
Update:
It would seem that .net 1.1 is a core component of WS2k3 so you can't just uninstall it. I could have attempted to remove the ASP.net component but I don't think that would fully uninstall everything and given that the dev environment is shared I can't risk causing any issues right now.
However I have previously set everything up on my local machine (Windows 7/IIS 7), so I changed the application pool to point at .net 2 (it was already running in classic pipeline mode), uninstalled .net frameworks 1 and 1.1 and cleaned up the files left behind afterwards.
The result was that the site ran absolutely fine, which would suggest in an IIS 7 environment at least that I don't need to worry about upgrading given we are running under .net 2 within IIS.
It's not an ideal test as it isn't a mimick of our live environment. I'm going to post a question on MSDN and asp.net to see if any Microsoft folks can add anything more definitive. I will post back here with any updates.
Just because official support will end doesn't mean Microsoft will pull the plug and force an uninstall of .NET 1.1 via Windows Update. It only means that:
if a gaping hole in the framework's security is ever found, they'll not fix it;
There won't be redistributables for the next versions of Windows, and the next version of IIS won't run it.
So the application will still run in a year. If you leave the server alone, the application might run until the machine breaks of old age.
So my suggestion is relax, and focus more on the new solution.
I got the answer to this questions after reading this link (provided as an answer to this question on the ASP.net forums)
http://msdn.microsoft.com/en-us/library/ms994381.aspx
Under "Application Load Mechanisms and Possible Issues" it states:
By default, an application built using the .NET Framework will run using the version of the Framework it was built against if that version is installed on the computer
It then goes on to detail (for .net 1.1 and 2.0 at least) when a particular version of the framework is used.
Essentially, because our server has both 1.1 and 2.0 installed the application will still be using version 1.1. If 1.1 was not installed then it would run by default under 2.0, which explains why the web application still worked after I uninstalled .net 1.0 and 1.1 from my local machine.
Given that the live server is W2K3 and I can't remove .net 1.1, I will be rebuilding my application to target .net 4.0.
In Wikipedia a number of WS-I Basic Profile (BP) compliant frameworks are listed. However, it is not clear to which version of the BP the framework is compliant to. So my question is as follows:
Which frameworks/products (Java, .NET and others) are compliant to WS-I Basic Profile 2.0?
The answer of this question may be of interest in the selection of an enterprise web service standard. It seems as if most frameworks are compliant to BP 1.1, but the question is whether the IT environments are ready to be upgraded to BP 2.0 (including MTOM binary attachments, WS-Addressing, SOAP 1.2 and UDDI 3.
Studying one example framework, the IBM WebSphere Message Broker (WMB), more closely I found the following information:
the platform supports WS-I Basic Profile Version 1.1
the platform supports e.g. WS-Addressing and SOAP 1.2
by using the HTTP proxy servlet pattern you indirectly get the same support as given by the Java EE application server
However, I did not find any explicit statement detailing that the product supports WS-I Basic Profile Version 2.0. The same seems to be the case for many frameworks...