In a previous blog post, I discussed setting up the Windows Standards-Based Storage Management Service (referred to below as Storage Service) on Windows Server 2012 R2. For Windows Server 2016 and System Center 2016 Virtual Machine Manager, configuration is much simpler since installation of the service includes setting up the necessary self-signed certificate. We also allow using CA signed certificates now provided the Common Name (CN) is “MSSTRGSVC”.

Before I get into those changes, I want to talk about the Transport Layer Security 1.2 (TLS 1.2) protocol, which is now a required part of the Storage Management Initiative Specification (SMI-S).

TLS 1.2

Secure communication through the Hyper Text Transport Protocol (HTTPS) is accomplished using the encryption capabilities of Transport Layer Security, which is itself an update to the much older Security Sockets Layer protocol (SSL) – although still commonly called Secure Sockets. Over the years, several vulnerabilities in SSL and TLS have been exposed, making earlier versions of the protocol insecure. TLS 1.2 is the latest version of the protocol and is defined by RFC 5246.

The Storage Networking Industry Association (SNIA) made TLS 1.2 a mandatory part of SMI-S (even retroactively). In 2015, the International Standards Organization (ISO) published ISO 27040:2015 “Information Technology – Security Techniques – Storage Security”, and this is incorporated by reference into the SMI-S protocol and pretty much all things SNIA.

Even though TLS 1.2 was introduced in 2008, it’s uptake was impeded by interoperability concerns. Adoption was accelerated after several exploits (e.g., BEAST) ushered out the older SSL 3.0 and TLS 1.0 protocols (TLS 1.1 did not see broad adoption). Microsoft Windows offered support for TLS 1.2 beginning in Windows 7 and Windows Server 2008 R2. That being said, there were still a lot of interop issues at the time, and TLS 1.1 and 1.2 support was hidden behind various registry keys.

Now it’s 2016, and there are no more excuses for using older, proven-insecure protocols, so it’s time to update your SMI-S providers. But unfortunately, you still need to take action to fully enable TLS 1.2. There are three primary Microsoft components that are used by the Storage Service which affect HTTPS communications between providers and the service: SCHANNEL, which implements the SSL/TLS protocols; HTTP.SYS, an HTTP server used by the Storage Service to support indications; and .NET 4.x, used by Virtual Machine Manager (VMM) (not by the Storage Service itself).

I’m going to skip some of the details of how clients and servers negotiate TLS versions (this may or may not allow older versions) and cipher suites (the most secure suite mutually agreed upon is always selected, but refer to this site for a recent exploit involving certain cipher suites).

A sidetrack: Certificate Validation

How certificates are validated varies depending on whether the certificate is self-signed or created by a trusted Certificate Authority (CA). For the most part, SMI-S will use self-signed certificates – and providers should never, ever, be exposed to the internet or another untrusted network. A quick overview:

A CA signed certificate contains a signature that indicates what authority signed it. The user of that certificate will be able to establish a chain of trust to a well-known CA.

A self-signed certificate needs to establish this trust in some other way. Typically, the self-signed certificate will need to be loaded into a local certificate store on the system that will need to validate it. See below for more on this.

In either case, the following conditions must be true: the certificate has not expired; the certificate has not been revoked (look up Revocation List for more about this); and the purpose of the certificate makes sense for its use. Additional checks include “Common Name” matching (disabled by default for the Storage Service; must not be used by providers) and key length. Note that we have seen issues with certificates being valid “from” a time and there is a time mismatch between the provider and the storage service. These tend to cure themselves once the start time has been passed on both ends of the negotiation. When using the Windows PowerShell cmdlet Register-SmisProvider you will see this information.

In some instances, your provider may ignore one or more of the validation rules and just accept any certificate that we present. A useful debugging approach but not very secure!

One more detail: when provisioning certificates for the SMI-S providers, make sure they use key lengths of 1024 or 2048 bits only. 512 bit keys are no longer supported due to recent exploits. And odd length keys won’t work either. At least I have never seen them work, even though technically allowed.

Microsoft product support for TLS 1.2

This article will discuss Windows Server and System Center Releases, and the .NET Framework. It should not be necessary to mess with registry settings that control cipher suites or SSL versions except as noted below for the .NET framework.

Windows Server 2012 R2/2016

Since the initial releases of these products, there have been many security fixes released as patches, and more than a few of them changed SCHANNEL and HTTP.SYS behavior. Rather than attempt to enumerate all of the changes, let’s just say it is essential to apply ALL security hotfixes.

If you are using Windows Server 2016 RTM, you also need to apply all available.

There is no .NET dependency.

System Center 2012 R2 Virtual Machine Manager

SC 2012 R2 VMM uses the .NET runtime library but the Storage Service does not. If you are using VMM 2012 R2, to fully support TLS 1.2, the most recent version of .NET 4.x should be installed; this is currently .NET 4.6.2. Also, update VMM to the latest Update Release.

If, for some reason, you must stay on .NET 4.5.2, then a registry change will be required to turn on TLS 1.2 on the VMM Server(s) since by default, .NET 4.5.2 only enables SSL 3.0 and TLS 1.0.

The registry value (which changes to allow TLS 1.0, TLS 1.1 and TLS 1.2 and not SSL 3.0 which you should never use anyway) is:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 “SchUseStrongCrypto”=dword:00000001

You can use this PowerShell command to change the behavior:

Set-ItemProperty -Path “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319” -Name “SchUseStrongCrypto” -Value “1” -Force

(Note that the version number highlighted applies regardless of a particular release of .NET 4.5; do not change it!)

This change will apply to every application using the .NET 4.x runtime on the same system. Note that Exchange 2013 does not support 4.6.x, but you shouldn’t be running VMM and Exchange on the same server anyway! Again, apply this to the VMM Server system or VM, which may not be the same place you are running the VMM UI.

System Center 2016 VMM

VMM 2016 uses .NET 4.6.2; no changes required.

Exporting the Storage Service Certificate

Repeating the information from a previous blog, follow these steps on the VMM Server machine:

• Run MMC.EXE from an administrator command prompt.
• Add the Certificates Snap-in using the File\Add/Remove Snap-in menu.
• Make sure you select Computer Account when the wizard prompts you, select Next and leave Local Computer selected. Click Finish.
• Click OK.
• Expand Certificates (Local Computer), then Personal and select Certificates.
• In the middle pane, you should see the msstrgsvc Right click, select All Tasks, Export… That will bring up the Export Wizard.
• Click Next to not export the private key (this might be grayed out anyway), then select a suitable format. Typically DER or Base-64 encoded are used but some vendors may support .P7B files. For EMC, select Base-64.
• Specify a file to store the certificate. Note that Base-64 encoded certificates are text files and can be open with Notepad or any other editing program.

Note: if you deployed VMM in a HA configuration, you will need to repeat these steps on each VMM Server instance. Your vendor’s SMI-S provider must support a certificate store that allows multiple certificates.

Storage Providers

Microsoft is actively involved in SNIA plugfests and directly with storage vendors to ensure interoperability. Some providers may require settings to ensure the proper security protocols are enabled and used, and many require updates.

OpenSSL

Many SMI-S providers and client applications rely on the open source project OpenSSL.

Storage vendors who use OpenSSL must absolutely keep up with the latest version(s) of this library and it is up to them to provide you with updates. We have seen a lot of old providers that rely on the long obsolete OpenSSL 0.9.8 releases or unpatched later versions. Microsoft will not provide any support if your provider is out-of-date, so if you have been lazy and not keeping up-to-date, time to get with the program. At the time of this writing there are three current branches of OpenSSL, each with patches to mend security flaws that crop up frequently. Consult the link above. How a provider is updated is a vendor-specific activity. (Some providers – such as EMC’s – do not use OpenSSL; check with the vendor anyway.)

Importing the Storage Service certificate

This step will vary greatly among providers. You will need to consult the vendor documentation for how to import the certificate into their appropriate Certificate Store. If they do not provide a mechanism to import certificates, you will not be able to use fully secure indications or mutual authentication with certificate validation.

Summary

To ensure you are using TLS 1.2 (and enabling indications), you must do the following:

• Check with your storage vendor for the latest provider updates and apply them as directed
• Update to .NET 4.6.2 on your VMM Servers or enable .NET strong cryptography if you must use .NET 4.5.x for any reason
• Install the Storage Service (installing VMM will do this for you)
• If you are using Windows Server 2012 R2, refer back to this previous blog post to properly configure the Storage Service (skip this for Windows Server 2016)
• Export the storage service certificate
• Import the certificate into your provider’s certificate store (see vendor instructions)
• Then you can register one or more SMI-S providers, either through the Windows Register-SmisProvider cmdlet or using VMM