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.
Related
Is it safe to have a .NET6 application which references a .NET Core 3.1 NuGet library?
I tested this case using a simple console application. Everything looks good and there are no errors/warning. However, I haven't found any specific information so prefer to make sure.
This is important, as one of my providers offers only a .NET Core 3.1 NuGet package. Knowing the company it'll take them a year or so to prepare a .NET6 / .NETStandard version.
There is a good chance that your .NET Core 3.1 library will run without any compatibility problems as part of your .NET 6 application.
Quoting the .NET fundamentals article Changes that affect compatibility (emphasis mine):
Throughout its history, .NET has attempted to maintain a high level of
compatibility from version to version and across implementations of
.NET. …
Along with compatibility across .NET implementations, developers
expect a high level of compatibility across versions of a given
implementation of .NET. In particular, code written for an earlier
version of .NET Core should run seamlessly on .NET 5 or a later
version. In fact, many developers expect that the new APIs found in
newly released versions of .NET should also be compatible with the
pre-release versions in which those APIs were introduced.
However, compatibility is not guaranteed. The article goes on to say:
This article outlines changes that affect compatibility and the
way in which the .NET team evaluates each type of change.
Understanding how the .NET team approaches possible breaking
changes is particularly helpful for developers who open pull
requests that modify the behavior of existing .NET APIs.
Furthermore, in an answer to the question Clarification on backwards compatibility of .NET Core, a member of the .NET runtime team says:
We do not guarantee 100% compatibility between major versions. This is true for both ASP.NET Core and the runtime itself. We
intentionally make breaking changes where we believe that they are
necessary to move the platform forward and the cost of the .NET
ecosystem adjusting to them is low enough.
Breaking changes that could potentially affect the compatibility of your .NET Core 3.1 library are those that are documented for .NET 5 and .NET 6.
But, if you are not experiencing any problems with your .NET Core 3.1 library, it would appear that none of the documented compatibility problems apply.
Ultimately, of course, you'll have a higher degree of confidence in the library when your vendor provides one that has been updated for .NET 6.
Finally, with the introduction of .NET 5, there became a lesser need for .NET Standard:
.NET Standard is a formal specification of .NET APIs that are
available on multiple .NET implementations. The motivation behind .NET
Standard was to establish greater uniformity in the .NET ecosystem.
.NET 5 and later versions adopt a different approach to establishing uniformity that eliminates the need for .NET Standard in most
scenarios. However, if you want to share code between .NET Framework
and any other .NET implementation, such as .NET Core, your library
should target .NET Standard 2.0. No new versions of .NET Standard will
be released, but .NET 5, .NET 6, and all future versions will continue
to support .NET Standard 2.1 and earlier.
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?
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.
This is a second attempt with better wording of the problem I'm facing.
I have a simple requirement to implement an application that will allow web applications and standalone services that will be claims-aware (using ADFS). Note that I am talking about windows services in addition to web applications.
Which enabling interoperable technologies should a developer pick?
For the life of me, I can't find a resource that says: to build a claims-aware application using the latest upcoming frameworks, install these packages.
From a framework point of view, I am talking about the following:
Microsoft.IdentityModel
Microsoft.Owin
System.IdentityModel
Microsoft.Asp.Net.Identity
Which should I be using? Alpha / Beta packages are fine.
Thank you,
Richard
in .net 4.5 IdentityModel is now part of the core libraries (so it no longer called Microsoft.IdentityModel).
So for your system you would need the following:
System.IdentityModel for the FederationAuthenticationModule (which intercepts and verifies your SAML token submission) and for the SessionAuthenticationModule (which serializes/deserializes your claims.)
To create the claims that you will send between your applciations you would use:
System.Security.Claims
as I mentioned these are both in .net 4.5.
Microsoft.IdentityModel is the one you are looking for.
Microsoft.IdentityModel.Claims for IClaimsIdentity interface.
Microsoft.IdentityModel.Web for WSFederationAuthenticationModule.
Yup - System.IdentityModel is the way to go.
Refer: What's New in Windows Identity Foundation 4.5.
If you are wondering what the difference between WIF 3.5 and 4.5 is, refer:
Guidelines for Migrating an Application Built Using WIF 3.5 to WIF 4.5
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...