Wednesday, March 25, 2020

Forcing TLS 1.2 and set Default Protocol for communication to TLS 1.2

In order to force TLS 1.2 on any system, you need to disable following registry changes.  If you don't want to do those changes manually, there is a nice free tool IIS Crypto which can do it for you.

Registry Changes:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server


Create DWORD DisabledByDefault value is 0 and Enabled value is 1, which means that TLS 1.2 is enabled by default.

You also need to set DisabledByDefault to 1 and Enabled to 0 for following Registry Entries


HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server

If you are doing it through IIS Crypto, select only TLS 1.2 in server and client protocols.



Now, you need to make sure that you set the default communication to TLS 1.2 for any .net managed application.
Set following registry for the same .
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]       "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001


For 64 bit,
[HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001
[HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001


You can also run the following command at elevated command prompt to add SchUseStrongCrypto key.

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:32

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64

Reboot the computer once done. And you are all set.

*.Net framework application build with 4.6.2+ use TLS 1.2 by default for the communication. but other doesn't. So you need to explicitly tell .net framework to use System Default TLS Version.

Please leave comment if you encounter any issue.

Ref:
https://thedynamicsexplorer.com/2019/11/06/dynamics-gp-error-msg-a-fatal-error-occurred-while-creating-an-ssl-client-credential-the-internal-error-state-is-10013-with-the-web-client/

https://docs.microsoft.com/en-us/configmgr/core/plan-design/security/enable-tls-1-2-client

I ran into this issue when one of our report on SQL report server wasn't able to call an API which was only supporting TLS 1.2.

Sunday, March 15, 2020

New In Azure - Feb 2020


  • Azure Cosmos DB 
    • New Free tier supporting 400 RUs, One per subscription
    • auto pilot mode which increse the RUs to a max threshold set by you when required.
  • Azure VM Updates Configuration
    • Maintenance policy can be set and executed with apply update. 
    • That will apply  all the updates available until that time. 
    • Can be scheduled to run during maintenance. 
    • This is to avoid any intrupption like Freeze/Reboot during updates. 
    • Supported only on dedicated/isolated VMs at the moment.
  • Ultra Disk
    • High IO disk. Supporting 80K IO per second with less than mili second latency
    • Ideal for highly critical application where a second of failure isn't ideal.
    • Only supported over certain types of VMs
  • Private Link
    • Is used to secure your resources so that you don't need to open the internet access on your devices
    • You can enable private link for a resources say storage by assigning it a VNET, which would give the resource the same IP range as VNET and the resource can be acessed privately from a VM or any other resource in that VNET
    • Your storage account in this case can only be accessed from the resource in VNET which would add more security to it. 
  • Azure Data Studio
    • Can be used to connect to SQL
    • provide a nice way to create reports that can be shared easily
    • Platform independent
  • Azure CDN Rules Engine
    • Azure CDN now supports the rules engine. 
    • You can create 2 rules at the moment while its in preview with 5 in GA. 
    • This will move the job of rules evaluation from origin to the edge. 
    • Rules like URL ReWrite / URL Redirect can be cofigured easily. 
    • You can add/edit/delete your own headers before the request hits the origin.
    • Costing Update: No charges for the data transfered from origin to the edge. 
  • Kubernetes API Security
    • now you can apply the ip-policy to your kubernets server so that the API can be accessed only from the allowed ip range. 
    • you can still access the Azure API which controls the Kubernets from any where provided you have necessary rights but your communication to Kubernets API is restricted by the whitelisted IP address.