web.PostJson() TLS Version


Does anyone know how I might check the security version used by the web.PostJson() helper?
The PMS API is scheduled to require TLS v1.2 from November first in relation to new PCI compliance standards.
My PMS integration is dependent on this function so am hoping it is compatible.
I presume it uses .net framework function?


It will be related to .net framework because that is what SambaPOS is built using.

From a quick look, it doesn’t look good. I believe SambaPOS V5 is built in .net framework 3.5, which according to http://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/ does not support TLS and the only option is to upgrade the .net framework version used, not an option for us.

However, there is a workaround posted here https://stackoverflow.com/a/44004297 on the 2nd answer involving installing a microsoft patch that adds TLS 1.2 support to .net framework 3.5 and tweaking the registry - you might want to check that out.

EDIT: SambaPOS V4 and V5 are built with .net framework 4.5

In order to check what is actually being used, you need to intercept the post. So would involve you posting to somewhere you host. You can check also Postman, they have a mock server that is free for testing APIs, if you post to it, you can probably see the SSL/TLS version it’s sending.



SambaPOS since V4 uses .Net 4 … which is why Win XP is not supported.

In any case, you can build your own PostJson function using the host.x helper to hook any C# Assembly or .Net library


Great, thats good to hear if its not already compatible it will be resolvable, got a bit worried when the notification came through from the PMS Dev Team.


Found this;

.NET 4.6 and above. You don’t need to do any additional work to support TLS 1.2, it’s supported by default.
.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
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

.NET 4.0. TLS 1.2 is not supported, but if you have .NET 4.5 (or above) installed on the system then you still can opt in for TLS 1.2 even if your application framework doesn’t support it. The only problem is that SecurityProtocolType in .NET 4.0 doesn’t have an entry for TLS1.2, so we’d have to use a numerical representation of this enum value:

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

.NET 3.5 or below. TLS 1.2 is not supported (*) and there is no workaround. Upgrade your application to more recent version of the framework.

Am I remembering correctly that samba requires 4.5 on install?
Its not an area im experianced in but if we update .net framework does this mean samba uses the new framework version?


No, software built for a specific version will only use that version.

The only exception would be when Microsoft release a hotfix or patch for a .net version.


But it is 4.5 right? so should be able to push tls1.2 as described in theory.


Yeah, I just checked…V4 onwards is using .net framework 4.5


Got link to there test server and got 1.2 working with the registry adjustments as below;

It may be possible to enable TLS 1.2 by default without modifying the source code by setting the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don't exist: "HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319" and "HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319". Although the version number in those registry keys is 4.0.30319, the .NET 4.5, 4.5.1, and 4.5.2 frameworks also use these values. Those registry keys, however, will enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on that system. It is thus advisable to test this change before deploying it to your production servers. This is also available as a registry import file. These registry values, however, will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.

@emre as you are working on next version, may I request that depending on what .net may be used that TLS 1.2 or higher is available/set by default if not already on the .net version used.
The v1.2 is required for PCI compliance and would expect most services will if not already planning to, increase security to this level in the not so distant future.