Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Certificate Requirements for SSTPThe Windows Server 2016 Routing and Remote Access Service (RRAS) is commonly deployed as a VPN server for Windows 10 Always On VPN deployments. Using RRAS, Always On VPN administrators can take advantage of Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP) VPN protocol. SSTP is a Transport Layer Security (TLS) based VPN protocol that uses HTTPS over the standard TCP port 443 to encapsulate and encrypt communication between the Always On VPN client and the RRAS VPN server. SSTP is a firewall-friendly protocol that ensures ubiquitous remote network connectivity. Although IKEv2 is the protocol of choice when the highest level of security is required for VPN connections, SSTP can still provide very good security when implementation best practices are followed.

SSTP Certificate

Since SSTP uses HTTPS for transport, a common SSL certificate must be installed in the Local Computer/Personal/Certificates store on the RRAS VPN server. The certificate must include the Server Authentication Enhanced Key Usage (EKU) at a minimum. Often SSL certificates include both the Server Authentication and Client Authentication EKUs, but the Client Authentication EKU is not strictly required. The subject name on the certificate, or at least one of the Subject Alternative Name entries, must match the public hostname used by VPN clients to connect to the VPN server. Multi-SAN (sometimes referred to as UC certificates) and wildcard certificates are supported.

Always On VPN Certificate Requirements for SSTP

Certification Authority

It is recommended that the SSL certificate used for SSTP be issued by a public Certification Authority (CA). Public CAs typically have their Certificate Revocation Lists (CRLs) hosted on robust, highly available infrastructure. This reduces the chance of failed VPN connection attempts caused by the CRL being offline or unreachable.

Using an SSL certificate issued by an internal, private CA is supported if the CRL for the internal PKI is publicly available.

Key Type

RSA is the most common key type used for SSL certificates. However, Elliptic Curve Cryptography (ECC) keys offer better security and performance, so it is recommended that the SSTP SSL certificate be created using an ECC key instead.

Always On VPN Certificate Requirements for SSTP

To use an ECC key, be sure to specify the use of a Cryptographic Next Generation (CNG) key and select the ECDSA_P256 Microsoft Software Key Storage Provider (CSP) (or greater) when creating the Certificate Signing Request (CSR) for the SSTP SSL certificate.

Always On VPN Certificate Requirements for SSTP

Most public CAs will support certificate signing using ECC and Elliptic Curve Digital Signature Algorithm (ECDSA). If yours does not, find a better CA. 😉

Forward Secrecy

Forward secrecy (sometimes referred to as perfect forward secrecy, or PFS) ensures that session keys can’t be compromised even if the server’s private key is compromised. Using forward secrecy for SSTP is crucial to ensuring the highest levels of security for VPN connections.

To enforce the use of forward secrecy, the TLS configuration on the VPN server should be prioritized to prefer cipher suites with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

Authenticated Encryption

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) is a form of encryption that provides better data protection and integrity compared to older block or stream ciphers such as CBC or RC4.

To enforce the use of authenticated encryption, the TLS configuration on the VPN server should be prioritized to prefer cipher suites that support Galois/Counter Mode (GCM) block ciphers.

Important Note: In Windows Server 2016, GCM ciphers can be used with both RSA and ECC certificates. However, in Windows Server 2012 R2 GCM ciphers can only be used when an ECC certificate is used.

SSL Offload

Offloading SSL to a load balancer or application delivery controller (ADC) can be enabled to improve scalability and performance for SSTP VPN connections. I will cover SSL offload for SSTP in detail in a future post.

Summary

SSTP can provide good security for VPN connections when implementation and security best practices are followed. For optimum security, use an SSL certificate with an EC key and optimize the TLS configuration to use forward secrecy and authenticated cipher suites.

Additional Information

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN Certificate Requirements for IKEv2

3 Important Advantages of Always On VPN over DirectAccess

Microsoft SSTP Specification on MSDN

DirectAccess IP-HTTPS and Symantec SSL Certificates

DirectAccess IP-HTTPS and Symantec SSL CertificatesAn SSL certificate is required to support the IP-HTTPS IPv6 transition technology when configuring DirectAccess. Implementation best practices dictate using a public SSL certificate signed by a trusted third-party vendor such as Entrust, Verisign, DigiCert, and others. SSL certificates issued by a private PKI are acceptable if the client trusts the issuing CA. Self-signed certificates are supported in some deployment scenarios, but their use is generally discouraged. For more detailed information regarding SSL certificate considerations for DirectAccess IP-HTTPS click here.

Symantec Issued Certificates

Symantec is a popular commercial SSL certificate provider that has been commonly used for many years. However, due to integrity issues associated with their PKI management practices, Google and Mozilla announced they will soon be deprecating these certificates. This means users who browse to an HTTPS web site protected with a Symantec SSL certificate will receive a warning in their browser indicating the certificate is not trusted.

DirectAccess IP-HTTPS

It is important to note that there is no impact at all for DirectAccess when the server is configured to use an SSL certificate issued by Symantec. There is nothing you need to do to address this issue in this scenario. However, if a wildcard certificate is installed on the DirectAccess server and it is also used on other public-facing web servers in the organization, it is likely that the certificate will replaced, perhaps by another certificate provider. In this case, DirectAccess IP-HTTPS must be configured to use the new or updated SSL certificate.

Updating IP-HTTPS SSL Certificate

To update the DirectAccess IP-HTTPS SSL certificate, import the SSL certificate along with the private key in to the local computer certificate store on each DirectAccess server. Next identify the thumbprint of the new SSL certificate. Finally, open an elevated PowerShell command window and enter the following command.

$thumbprint = “ssl_cert_thumbprint”
$cert = Get-ChildItem -Path cert:\localmachine\my | where {$_.thumbprint -eq $thumbprint}
Set-RemoteAccess -SslCertificate $cert -PassThru

Be sure to replace “ssl_cert_thumbprint” with the actual thumbprint of your SSL certificate. 😉 In addition, for load-balanced and/or multisite deployments, run these PowerShell commands on each server in the enterprise.

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS

DirectAccess IP-HTTPS Null Cipher Suites Not Available 

DirectAccess IP-HTTPS Performance Issues

DirectAccess IP-HTTPS Performance Issues

DirectAccess IP-HTTPS Performance IssuesPerformance issues with DirectAccess are not uncommon. In fact, there are numerous threads on Microsoft and third-party forums where administrators frequently complain about slow download speeds, especially when using the IP-HTTPS IPv6 transition technology. Based on my experience the problem does not appear to be widespread but occurs with enough regularity that it is worthy of further investigation.

DirectAccess Design

The inherent design of DirectAccess is a major limiting factor for performance. DirectAccess uses a complex and heavy communication channel, with multiple layers of encapsulation, encryption, and translation. Fundamentally it is IPsec encrypted IPv6 traffic, encapsulated in HTTP, and then encrypted with Transport Layer Security (TLS) and routed over IPv4. It is then decrypted, decapsulated, decrypted again, then converted back to IPv4. The high protocol overhead incurred with multiple layers of encapsulation, encryption, and translation result in increased packet fragmentation, which further reduces performance.

DirectAccess Performance

Even under the best circumstances, DirectAccess performance is limited by many other factors, most notably the quality of the network connection between the client and the server. DirectAccess performs reasonably well over high bandwidth, low latency connections. However, network performance drops precipitously as latency increases and packet loss is encountered. This is to be expected given the design of the solution.

Intermediary Devices

It is not uncommon to find intermediary devices like firewalls, intrusion detection systems, malware scanners, and other security inspection devices limit the performance of DirectAccess clients. In addition, many security appliances have bandwidth caps enforced in software for licensing restrictions. Further, incorrect configuration of inline edge devices can contribute to increased fragmentation, which leads to poor performance as well.

Slow Downloads over IP-HTTPS

Many people report that download speeds seem to be artificially capped at 355Kbps. While this seems to be a display bug in the UI, there is plenty of evidence to indicate that, in some scenarios, DirectAccess is incapable of high throughput even over high-quality connections. Some who have deployed DirectAccess and VPN on the same server have reported that download speeds are only limited when using DirectAccess over IP-HTTPS and not with VPN using Secure Socket Tunneling Protocol (SSTP), which also uses TLS. This has led many to speculate that the issue is either a bug or a design flaw in the IP-HTTPS tunnel interface itself.

TCP Window Scaling Issues

In some of the network traces I’ve analyzed I’ve seen evidence that seems to support this theory. For example, a network trace taken when downloading a file over DirectAccess with IP-HTTPS showed the TCP window never scaled beyond 64K, which would seriously impede performance. Interestingly this doesn’t seem to happy when the client uploads files over IP-HTTPS. Clearly something unusual is happening.

Microsoft KB Article

Microsoft recently released a vaguely-worded KB article that appears to lend credence to some of these findings. The article seems to acknowledge the fact there are known issues with DirectAccess performance, but it lacks any specific details as to what the root cause is. Instead, it simply advises migrating to Windows 10 Always On VPN.

Summary

DirectAccess IP-HTTPS performance issues don’t appear to affect everyone, and the problem only seems to apply to file downloads and not to other types of traffic. However, there is mounting evidence of a systemic issue with DirectAccess performance especially over IP-HTTPS. Customers are advised to closely evaluate their uses cases for DirectAccess and if remote clients are frequently required to download large files over a DirectAccess connection, an alternative method of file transfer might be required. Optionally customers can consider evaluating alternative remote access solutions that offer better performance such as Windows 10 Always On VPN or third-party solutions such as NetMotion Mobility.

Additional Resources

Always On VPN and the Future of DirectAccess

What’s the Difference Between DirectAccess and Always On VPN?

NetMotion Mobility as an Alternative to Microsoft DirectAccess