Security Recommendations for Internet facing Web Servers¶

Server-Side Protocol Support¶

In order to complete a TLS handshake, both parties must support at least one common protocol and cipher suite. When discussing the TLS handshake we will use the terms server-side TLS and client-side TLS.

Server-Side TLS - This will be a service, such as a web server which accepts requests and serves content. Webmasters and server administrators can configure the server settings to dictate which protocols the server will support for the TLS handshake. The following section discusses this is detail

Client-Side TLS - This will be handled by a Web browser or user device, such as a smartphone. The client will initiate the TLS handshake. Webmasters and developers will have no control over which protocols and ciphers a client will try to negotiate with. We can, however, influence the decision by disabling any protocols or ciphers at the server-side that we do not want to use.

Windows Server 2016¶

Windows Server 2016, being the latest production version of Microsoft’s server operating system, naturally provides support for the newest and most secure cipher suites.

Notably, Server 2016 supports the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher (and the AES_256 variant) which provides both Forward Secrecy (using ECDHE) and Authenticated Encryption (AEAD) while using RSA authentication. All earlier versions of Windows need to either use ECDSA authentication (by using an ECC certificate) or rely on the much slower DHE in order to provide both AEAD and PFS (Perfect Forward Secrecy).

A full list of supported ciphers and protocols for Windows Server 2016, can be found here

As the table shows above, TLS 1.0 is still enabled by default on Windows Server 2016 for backwards compatibility. If you have no services that require this then you can go-ahead and disable the TLS 1.0 protocol.

Windows Server 2012 R2¶

In the table shown above, you can see that all protocols except SSLv2 are enabled by default. From these defaults, we recommend that SSLv3 and TLS 1.0 are disabled, as these are considered cryptographically weaker than the latest TLS versions.

If Windows Updates are being routinely applied to your Windows Server (and they should be!) then you should have the following Cumulative update installed on 2012 R2 servers already:

KB2919355 - Cumulative Update April 2014

This cumulative update installs KB2929781 which adds 4 GCM ciphers to the Schannel provider and re-orders the cipher priority.

GCM ciphers offer Authenticated Encryption (AEAD) and currently provide the best encryption. Out of these additional ciphers, the 2 listed below also provide Perfect Forward Secrecy (PFS) through the use of the DHE_RSA key exchange:

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

You may notice in Microsoft documentation that these ciphers are near the top in the cipher order. This is partly because they remain the only ways to support PFS and AEAD when using RSA authentication on Windows servers prior to Server 2016.

In the real world, these 2 ciphers are rarely negotiated due to limited client-side support.

If you choose to use the DHE key exchange, you should ensure that the Diffie-Hellman keys for your server are strong enough. If you follow a regular Windows Update schedule KB3174644 should already be installed to provide updated support for the Diffie-Hellman Key Exchange. Once this patch is installed, you will be able to define the length of the DH private key, up to a size of 4096 bits. Additional information provided here.

Note: The Ephemeral Diffie Hellman (DHE) key exchange using a secure key (at least 2048 bits) is much more computationally expensive on both the client and the server, and is therefore slower than the more modern Elliptic Curve Diffie Hellman (ECDHE) exchange. If you MUST support AEAD on Server 2012 R2 while using an RSA signature certificate then this is the only option.

Windows Server 2008 R2 / 2012¶

In the table shown above, you can see the default enabled SSL/TLS versions for these operating systems. From these defaults, we recommend that TLS 1.1 and TLS 1.2 are enabled if not already. We also advise that SSLv2, SSLv3 and TLS 1.0 are disabled, as these are considered cryptographically weaker than the latest TLS versions.

Security Advisory 3042058 introduced 4 new ciphers suites to Server 2008 R2 and Server 2012. This now means that forward secrecy (PFS) with Authenticated Encryption (AEAD) is available on 2008 R2 and 2012 when using a standard RSA authentication by prioritising these 2 ciphers:

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

In the real world, these 2 ciphers are rarely negotiated due to limited client-side support.

As mentioned above, you will need to ensure that KB3174644 is installed to provide updated support for the Diffie-Hellman Key Exchange.

Note: The DHE key exchange using a secure key (at least 2048 bits) is much more computationally expensive on both the client and the server, and is therefore slower than the more modern ECDHE exchange. If you MUST support AEAD on Server 2008 R2 or Server 2012 while using an RSA certificate then this is the only option.

If you are running a production web server with SSL/TLS being terminated directly on the 2008 R2 or 2012 server, we recommend looking to either upgrade your operating system, or implementing a Webcelerator/Loadbalancer solution to terminate the secure connection. Both these options will make available newer, more secure cipher suites, which provide both authenticated encryption and forward secrecy.

Windows Server 2008¶

In the table shown above, you can see the default enabled SSL/TLS versions for this operating system. Before you disable insecure protocols (SSLv2, SSLv3 and TLS1.0), you will need to ensure you have no applications such as old versions of SQL server which requires them.

Due to the age of this operating system, TLS 1.1 and 1.2 are not supported by default. Support can be added for TLS1.1 and 1.2 by installing the following Windows update:

KB4019276

On systems that have a regular update schedule, it is possible that this patch has been superseded by a more recent update. You can check this by ensuring that the schannel.dll file is at least version 6.0.6002.24129 by running the following command from an elevated Command Prompt:

wmic datafile where Name="c:\\Windows\\System32\\schannel.dll" get Description,Version

Once support for TLS 1.2 has been enabled, you will need to install KB4074621 to enable the use of TLS1.1 and 1.2 for RDP connections before disabling any of the older suites.

Loadbalancer, WAF, and Webcelerator solutions¶

In order for a device, such as a load balancer, to inspect HTTPS Web traffic, it must be able to decrypt any packets between the client’s browser and the backend web server. The same applies to a Webcelerator - If the Webcel cannot decrypt the traffic then it will be unable to cache any static content for future requests. This means that either SSL Offloading or Secure Origin Pull should be used and the TLS connection terminated at the device. More information on this is provided in our Webcel guide

If HTTPS traffic to your Web server is terminated at one of these edge devices, then you can get in touch with our Support Team to adjust the supported TLS protocols and cipher suites per your requirements.

The next thing to look at is how .NET Framework applications interact with Schannel.