All posts in category Encryption

Cloudflare Public DNS Resolver Now Available

Cloudflare Public DNS Resolver Now AvailableCloudflare has become a nearly ubiquitous cloud service provider in recent years, fronting many of the busiest web sites on the Internet. They provide tremendous value both in terms of security and performance for their customers. They have a wide array of solutions designed to provide better security, including optimized SSL/TLS configuration and Web Application Firewall (WAF) capabilities. Their DDoS mitigation service is second to none, and their robust Content Delivery Network (CDN) ensures optimal loading of content for web sites anywhere in the world.

Public DNS Resolver

Recently Cloudflare announced their first consumer service, a public DNS resolver that is free for general use. It offers exceptional performance and supports many of the latest DNS security and privacy enhancements such as DNS-over-TLS. Cloudflare has also pledged not to write DNS queries to disk at all and not to store them for more than 24 hours to further ensure privacy for their customers.

Cloudflare Public DNS Resolver Now Available

DNS Security Controls

What Cloudflare DNS is lacking today is granular security enforcement to provide additional protection for client computers outside the firewall. For example, public DNS resolvers from OpenDNS and Quad9 have built-in security features that use threat intelligence to identify and block DNS name resolution requests for domains that are known to be malicious or unsafe. OpenDNS has the added benefit of providing more granularity for setting policy, allowing administrators to select different filtering levels and optionally to create custom policies to allow or block individually selected categories. With OpenDNS, security administrators can also manage domains individually by manually assigning allow or block to specific, individual domains as necessary.

Recommended Use Cases

Cloudflare DNS clearly offers the best performance of all public DNS resolvers today, which makes it a good candidate for servers that rely heavily on DNS for operation. Mail servers come to mind immediately, but any system that performs many forward and/or reverse DNS lookups would benefit from using Cloudflare DNS. Cloudflare DNS can also be used by client machines where better performance and enhanced privacy are desired.

Quad9 DNS is a good choice for client computers where additional security is required. OpenDNS is the best choice where the highest level of security is required, and where granular control of security and web filtering policies is necessary.

Additional Information

Cloudflare DNS
Quad9 DNS
OpenDNS
Dnsperf.com

2 Comments
by Richard M. Hicks on April 3, 2018  •  Permalink
Posted in cloud, Cloudflare, DNS, Encryption, OpenDNS, public cloud, Quad9, Security, SSL and TLS
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on April 3, 2018

https://directaccess.richardhicks.com/2018/04/03/cloudflare-public-dns-resolver-now-available/

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

Leave a comment
by Richard M. Hicks on March 5, 2018  •  Permalink
Posted in certificates, DirectAccess, Encryption, IP-HTTPS, IPv6, IPv6 Transition, multisite, PKI, PowerShell, public key infrastructure, Remote Access, Security, SSL and TLS, transition technology, Windows 10, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on March 5, 2018

https://directaccess.richardhicks.com/2018/03/05/directaccess-ip-https-and-symantec-ssl-certificates/

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

3 Comments
by Richard M. Hicks on February 19, 2018  •  Permalink
Posted in DirectAccess, encapsulation, Encryption, IP-HTTPS, IPv6, IPv6 Transition, Remote Access, SSL and TLS, transition technology, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 19, 2018

https://directaccess.richardhicks.com/2018/02/19/directaccess-ip-https-performance-issues/

DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

DirectAccess and Always On VPN with Trusted Platform Module (TPM) CertificatesTo enhance security when provisioning certificates for DirectAccess (computer) or Windows 10 Always On VPN (user) it is recommended that private keys be stored on a Trusted Platform Module (TPM) on the client device. A TPM is a dedicated security processor included in nearly all modern computers. It provides essential hardware protection to ensure the highest levels of integrity for digital certificates and is used to generate, store, and restrict the use of cryptographic keys. It also includes advanced security and protection features such as key isolation, non-exportability, and anti-hammering to prevent brute-force attacks.

To ensure that private keys are created and stored on a TPM, the certificate template must be configured to use the Microsoft Platform Crypto Provider. Follow the steps below to configure a certificate template required to use a TPM.

  1. Open the Certificate Templates management console (certtmpl.msc) and duplicate an existing certificate template. For example, if creating a certificate for DirectAccess, duplicate the Workstation Authentication certificate template. For Always On VPN, duplicate the User certificate template.
  2. On the Compatibility tab, ensure the Certification Authority and Certificate recipient compatibility settings are set to a minimum of Windows Server 2008 and Windows Vista/Server 2008, respectively.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates
  3. Select the Cryptography tab.
  4. Choose Key Storage Provider from the Provider Category drop down list.
  5. Choose the option Requests must use one of the following providers and select Microsoft Platform Crypto Provider.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

Note: If Microsoft Platform Crypto Provider does not appear in the list above, got to the Request Handling tab and uncheck the option Allow private key to be exported.

Complete the remaining certificate configuration tasks (template display name, subject name, security settings, etc.) and publish the certificate template. Client machines configured to use this template will now have a certificate with private key fully protected by the TPM.

Additional Resources

Trusted Platform Module (TPM) Fundamentals

DirectAccess and Always On VPN Certificate Auto Enrollment

9 Comments
by Richard M. Hicks on February 12, 2018  •  Permalink
Posted in Always On VPN, AOVPN, certificates, DirectAccess, Encryption, PKI, public key infrastructure, Remote Access, Security, TPM, Trusted Platform Module, Windows 10, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 12, 2018

https://directaccess.richardhicks.com/2018/02/12/directaccess-and-always-on-vpn-with-trusted-platform-module-tpm-certificates/

What is the Difference Between DirectAccess and Always On VPN?

Always On VPN Device Tunnel Configuration Guidance Now AvailableDirectAccess has been around for many years, and with Microsoft now moving in the direction of Always On VPN, I’m often asked “What’s the difference between DirectAccess and Always On VPN?” Fundamentally they both provide seamless and transparent, always on remote access. However, Always On VPN has a number of advantages over DirectAccess in terms of security, authentication and management, performance, and supportability.

Security

DirectAccess provides full network connectivity when a client is connected remotely. It lacks any native features to control access on a granular basis. It is possible to restrict access to internal resources by placing a firewall between the DirectAccess server and the LAN, but the policy would apply to all connected clients.

Windows 10 Always On VPN includes support for granular traffic filtering. Where DirectAccess provides access to all internal resources when connected, Always On VPN allows administrators to restrict client access to internal resources in a variety of ways. In addition, traffic filter policies can be applied on a per-user or group basis. For example, users in accounting can be granted access only to their department servers. The same could be done for HR, finance, IT, and others.

Authentication and Management

DirectAccess includes support for strong user authentication with smart cards and one-time password (OTP) solutions. However, there is no provision to grant access based on device configuration or health, as that feature was removed in Windows Server 2016 and Windows 10. In addition, DirectAccess requires that clients and servers be joined to a domain, as all configuration settings are managed using Active Directory group policy.

Windows 10 Always On VPN includes support for modern authentication and management, which results in better overall security. Always On VPN clients can be joined to an Azure Active Directory and conditional access can also be enabled. Modern authentication support using Azure MFA and Windows Hello for Business is also supported. Always On VPN is managed using Mobile Device Management (MDM) solutions such as Microsoft Intune.

Performance

DirectAccess uses IPsec with IPv6, which must be encapsulated in TLS to be routed over the public IPv4 Internet. IPv6 traffic is then translated to IPv4 on the DirectAccess server. DirectAccess performance is often acceptable when clients have reliable, high quality Internet connections. However, if connection quality is fair to poor, the high protocol overhead of DirectAccess with its multiple layers of encapsulation and translation often yields poor performance.

The protocol of choice for Windows 10 Always On VPN deployments is IKEv2. It offers the best security and performance when compared to TLS-based protocols. In addition, Always On VPN does not rely exclusively on IPv6 as DirectAccess does. This reduces the many layers of encapsulation and eliminates the need for complex IPv6 transition and translation technologies, further improving performance over DirectAccess.

Supportability

DirectAccess is a Microsoft-proprietary solution that must be deployed using Windows Server and Active Directory. It also requires a Network Location Server (NLS) for clients to determine if they are inside or outside the network. NLS availability is crucial and ensuring that it is always reachable by internal clients can pose challenges, especially in very large organizations.

Windows 10 Always On VPN supporting infrastructure is much less complex than DirectAccess. There’s no requirement for a NLS, which means fewer servers to provision, manage, and monitor. In addition, Always On VPN is completely infrastructure independent and can be deployed using third-party VPN servers such as Cisco, Checkpoint, SonicWALL, Palo Alto, and more.

Summary

Windows 10 Always On VPN is the way of the future. It provides better overall security than DirectAccess, it performs better, and it is easier to manage and support.

Here’s a quick summary of some important aspects of VPN, DirectAccess, and Windows 10 Always On VPN.

Traditional VPN DirectAccess Always On VPN
Seamless and Transparent No Yes Yes
Automatic Connection Options None Always on Always on, app triggered
Protocol Support IPv4 and IPv6 IPv6 Only IPv4 and IPv6
Traffic Filtering No No Yes
Azure AD Integration No No Yes
Modern Management Yes No (group policy only) Yes (MDM)
Clients must be domain-joined? No Yes No
Requires Microsoft Infrastructure No Yes No
Supports Windows 7 Yes Yes Windows 10 only

Always On VPN Hands-On Training

If you are interested in learning more about Windows 10 Always On VPN, consider registering for one of my hands-on training classes. More details here.

Additional Resources

Always On VPN and the Future of Microsoft DirectAccess

5 Important Things DirectAccess Administrators Should Know about Windows 10 Always On VPN

3 Important Advantages of Windows 10 Always On VPN over DirectAccess

7 Comments
by Richard M. Hicks on February 5, 2018  •  Permalink
Posted in 6to4, Always On VPN, AOVPN, DirectAccess, DirectAccess Deprecated, DirectAccess End of Life, DirectAccess EOL, encapsulation, Encryption, Enterprise, EOL, IP-HTTPS, IPv6, IPv6 Transition, MFA, Multifactor Authentiction, NAP, OTP, Remote Access, Security, SSL and TLS, transition technology, VPN, Windows 10, Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 5, 2018

https://directaccess.richardhicks.com/2018/02/05/what-is-the-difference-between-directaccess-and-always-on-vpn/

Enabling Secure Remote Administration for the NetMotion Mobility Console

During the initial setup of a NetMotion Mobility gateway server, the administrator must choose to allow either Secure (HTTPS) or Non-secure (HTTP) connections when using the web-based Mobility Console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Configuring HTTPS

Security best practices dictate HTTPS should be enabled to protect credentials used to log on to the gateway remotely. Immediately after selecting the Secure (https:) option, the administrator is prompted to enter server certificate information. Enter this information and click OK to continue and complete the rest of the configuration as necessary.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Self-Signed Certificate

When logging in to the Mobility console, the administrator is presented with a certificate error indicating there is a problem with the website’s security certificate. This is because the certificate is self-signed by the NetMotion Mobility gateway server and is not trusted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

PKI Issued Certificate

The recommended way to resolve this is to request a certificate from a trusted certification authority (CA). To do this, open the Mobility Management Tool on the Mobility gateway server and click on the Web Server tab.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click on the Server Certificate button and then click New in the Certificate Request section.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In the SAN (subject alternative name) field of the Optional Extension section enter the Fully Qualified Domain Name (FQDN) of the server using the syntax dns:fqdn. Include both the FQDN and the single-label hostname (short name) separated by a comma to ensure both names work without issue. For example:

dns:nm1.lab.richardhicks.net,dns:nm1

Enabling Secure Remote Administration for the NetMotion Mobility Console

Before requesting a certificate from a CA, the root and any intermediate CA certificates must first be imported. Click the Import button next to each, as required.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Copy in the Certificate Request section to copy the Certificate Signing Request (CSR) to the clipboard and then save it to a text file. Now submit the CSR to be signed by the CA using the certreq.exe command. Open an elevated command or PowerShell window and enter the following commands.

certreq.exe -attrib “CertificateTemplate:[TemplateName]” -submit [Path_to_CSR_file]

For example:

certreq.exe -attrib “CertificateTemplate:LabWebServer” -submit certreq.txt

Select a CA from the list and click OK, then save the certificate response when prompted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Response and specify the location of the certificate response file saved in the previous step.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Once complete, the newly issued certificate will be in place. Click Close to complete the process.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Yes when prompted to restart the Mobility console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Trusted Certificate

Opening the Mobility Console no longer produces a certificate error message with a certificate installed from a trusted CA.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In addition, if you followed the guidance above and included the single-label hostname in the SAN field, accessing the server using the short name will also work without issue.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Summary

Always select the option to use HTTPS to ensure the highest level of security and protection of credentials when remotely administering a NetMotion Mobility gateway server. For optimal security and to provide the best user experience, use a certificate issued and managed by a trusted CA to prevent certificate errors when opening the Mobility console.

Additional Information

NetMotion Mobility as an Alternative to DirectAccess

NetMotion Mobility Device Tunnel Configuration

Comparing NetMotion Mobility and DirectAccess Part 1 – Security

Comparing NetMotion Mobility and DirectAccess Part 2 – Performance

DirectAccess and NetMotion Mobility Webinar

 

3 Comments
by Richard M. Hicks on February 1, 2018  •  Permalink
Posted in Encryption, NetMotion, NetMotion Mobility, Remote Access, Security, SSL and TLS, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 1, 2018

https://directaccess.richardhicks.com/2018/02/01/enabling-secure-remote-administration-for-the-netmotion-mobility-console/

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

Always On VPN Protocol Recommendations for Windows Server Routing and Remote Access Service (RRAS)Windows 10 Always On VPN is infrastructure independent and can be implemented using third-party VPN devices. It is not necessary to deploy any Windows servers at all to support an Always On VPN solution. However, in a recent blog post I outlined some compelling reasons to consider using Windows Server 2016’s Routing and Remote Access Service (RRAS) feature to terminate VPN connections. RRAS supports both modern and legacy VPN protocols, each with their own advantages and disadvantages. The choice of which protocols to support will be determined by many factors, but it is important to understand the capabilities of each to make an informed decision.

RRAS VPN Protocols

Windows RRAS supports the following VPN protocols.

  • Internet Key Exchange version 2 (IKEv2) – RFC7296
  • Secure Sockets Tunneling Protocol (SSTP) – Microsoft
  • Layer Two Tunneling Protocol over IPsec (L2TP/IPsec) – RFC2661
  • Point-to-Point Tunneling Protocol (PPTP) – RFC2637

There are pros and cons associated with each of these VPN protocols. Here’s a breakdown of each.

IKEv2

This IPsec-based VPN protocol is the preferred choice for most deployments. IKEv2 provides the best security and performance, with native features that enhance mobility. This latest version of IKE (v2) features streamlined messaging during connection establishment and enhanced session management that reduce protocol overhead and improve performance.

Advantages: Best security and performance.
Disadvantages: Firewalls may block required UDP ports.

SSTP

SSTP is an excellent alternative to IKEv2. It uses industry standard Transport Layer Security (TLS), making it widely accessible from most locations. It provides good security out of the box, but can be improved upon with additional configuration. SSTP lends itself well to load balancing, making it much easier to scale out than IKEv2. Optionally, TLS can be offloaded to an Application Delivery Controller (ADC) to reduce resource utilization on the RRAS server and further improve performance.

Advantages: Easy to configure with firewall friendly access.
Disadvantages: Not as secure IKEv2.

L2TP

While technically supported for Always On VPN, L2TP is a legacy VPN protocol that offers no real advantages over IKEv2. Its use is unnecessary and should be avoided.

Advantages: None.
Disadvantages: Firewalls may block required UDP ports.

PPTP

PPTP is considered an obsolete VPN protocol with many known security vulnerabilities. Its use should be avoided at all costs.

Advantages: None.
Disadvantages: Insecure.

Summary

Implementation best practices dictate that IKEv2 and SSTP be enabled to support Windows 10 Always On VPN connections when using Windows Server 2016 RRAS. The use of L2TP/IPsec and PPTP should be avoided. The combination of IKEv2 and SSTP will provide the best security and availability for remote workers. Clients that can establish IKEv2 VPN connections can take advantages of the security and performance benefits it provides. SSTP can be enabled as a fallback for clients that are unable to establish an IKEv2 connection due to restricted firewall access.

Always On VPN Hands-On Training

Interested in learning more about Windows 10 Always On VPN? Hands-on training classes are now forming. More details here.

Additional Resources

Frequently Asked Questions about Microsoft’s PPTP Implementation

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

Windows 10 Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know about Always On VPN 

3 Important Advantages of Windows 10 Always On VPN over DirectAccess 

Windows 10 Always On VPN Hands-On Training Classes

3 Comments
by Richard M. Hicks on January 22, 2018  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, Encryption, Load Balancing, Remote Access, Security, SSL and TLS, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 22, 2018

https://directaccess.richardhicks.com/2018/01/22/always-on-vpn-protocol-recommendations-for-windows-server-routing-and-remote-access-service-rras/

DirectAccess IP-HTTPS Null Cipher Suites Not Available

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableMicrosoft first introduced support for null cipher suites for the IP-HTTPS IPv6 transition technology in Windows Server 2012, and it is supported for DirectAccess in Windows 8.x and Windows 10 clients. Using null cipher suites for IP-HTTPS eliminates the needless double encryption that occurs when using encrypted cipher suites. DirectAccess is a unique workload where SSL/TLS encryption isn’t really required because the payload being transported in HTTPS is already encrypted.

No Encryption by Design

When supporting Windows 8.x and Windows 10 clients, ensuring null cipher suites (TLS_RSA_WITH_NULL_SHA and TLS_RSA_WITH_NULL_SHA256) are enabled and operational is crucial to providing the highest levels of performance and scalability for the remote access solution. When following implementation best practices, this isn’t really an issue. However, in some cases null cipher suites may be disabled. This will result in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients.

Validating SSL/TLS Configuration

The easiest way to verify that null cipher suites are being offered by the DirectAccess server is to use the Qualys SSL Labs server test site. Ideally you should see a result similar to this.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 1. Qualys SSL Labs server test site results for properly configured DirectAccess server.

Don’t be alarmed by the overall rating “F”. That happens because the Qualys test site is designed to test web servers where using null cipher suites would be a serious security issue. As I stated previously, the DirectAccess workload is unique in that its HTTPS payload is already encrypted, so using null cipher suites is acceptable in this scenario.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 2. Qualys SSL Labs server test site results for properly configured DirectAccess server showing support for null SSL/TLS cipher suites.

Null Cipher Suites Missing

When performing the Qualys SSL labs server test on a DirectAccess server, an overall rating of “A” is not desirable and indicates the DirectAccess server is misconfigured. This is caused by the lack of support for null cipher suites.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 3. Qualys SSL Labs server test site results for misconfigured DirectAccess server.

Common Causes

Null cipher suites for SSL and TLS can be disabled for a variety of reasons. Below are some of the most common causes for the lack of support for null cipher suites for DirectAccess.

Self-Signed Certificates – Using the Getting Started Wizard (simplified deployment) will configure DirectAccess using a self-signed certificate for IP-HTTPS. Using a self-signed certificate is discouraged for numerous reasons, most importantly because it disables support for null cipher suites.

Security Hardening – Security administrators may proactively disable support for null cipher suites in a misguided effort to “improve security” for DirectAccess. While this is acceptable and recommended on a web server, it is not advisable to disable null cipher suites on a DirectAccess server.

SSL Certificate Signing Algorithm – Using an SSL certificate signed with an Elliptical Curve (EC) key as opposed to an RSA key will result in the loss of support for null cipher suites for IP-HTTPS. High security/assurance certificates signed with EC keys are not recommended for use on DirectAccess servers and should be avoided if possible.

DirectAccess Configuration Options – Enabling One-Time Password (OTP) authentication on the DirectAccess server will also result in a loss of support for null cipher suites. Also, adding additional roles to the DirectAccess server such as client-based VPN or the Web Application Proxy (WAP) can also result in null cipher suites being disabled.

Summary

Null cipher suites are implemented by design on DirectAccess servers to enhance performance for Windows 8.x and Windows 10 clients and improve overall scalability for the implementation. They eliminate the pointless double encryption of DirectAccess communication, which itself is already encrypted. For optimal performance and scalability, be sure to follow implementation best practices and use a PKI-managed (public or private) SSL certificate signed with an RSA key (SHA-256 recommended). Resist the urge to “harden” the DirectAccess server by disabling support for null cipher suites, and avoid the use of SSL certificates signed with EC keys. In addition, carefully consider DirectAccess deployment options such as OTP authentication and consider deploying roles such as VPN and WAP on a separate server.

Additional Information

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

DirectAccess and FIPS Compliant Algorithms for Encryption

SSL Certificate Considerations for DirectAccess IP-HTTPS 

 

 

3 Comments
by Richard M. Hicks on December 18, 2017  •  Permalink
Posted in Compliance, DirectAccess, Encryption, IP-HTTPS, IPv6, IPv6 Transition, Multifactor Authentiction, OTP, Remote Access, Security, SSL and TLS, transition technology, VPN, Web Application Proxy, Windows 10, Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 18, 2017

https://directaccess.richardhicks.com/2017/12/18/directaccess-ip-https-null-cipher-suites-not-available/

DirectAccess and FIPS Compliant Algorithms for Encryption

DirectAccess administrators may be required to enable Federal Information Processing Standards (FIPS) compliant algorithms for encryption, hashing, and signing on DirectAccess servers to meet certain regulatory and compliance requirements.

DirectAccess and FIPS Compliant Algorithms for Encryption

Performance Impact

Be advised that enabling this setting will disable support for null cipher suites for the IP-HTTPS IPv6 transition technology. This will result in the double encryption of all DirectAccess client communication, which will increase resource consumption on DirectAccess servers. This leads to reduced scalability and degraded performance for all DirectAccess clients, including Windows 8.x and Windows 10.

If enabling FIPS compliant cannot be avoided, additional compute capacity (CPU and memory) should be provisioned. For best results, add additional servers to distribute the workload and improve performance for DirectAccess clients.

Always On VPN

If you’re looking for better security and performance, consider migrating to Windows 10 Always On VPN. Always On VPN fully supports FIPS compliant algorithms without the negative performance impact associated with DirectAccess. If you’d like to learn more about security and Always On VPN, fill out the form below and I’ll get in touch with you.

Additional Resources

Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know About Always On VPN 

3 Important Advantages of Always On VPN over DirectAccess 

1 Comment
by Richard M. Hicks on December 6, 2017  •  Permalink
Posted in Always On VPN, Compliance, DirectAccess, Encryption, IP-HTTPS, IPv6, IPv6 Transition, Remote Access, Security, SSL and TLS, VPN, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 6, 2017

https://directaccess.richardhicks.com/2017/12/06/directaccess-and-fips-compliant-algorithms-for-encryption/

DirectAccess Reporting Fails and Schannel Event ID 36871 after Disabling TLS 1.0

IMPORTANT NOTE: The guidance in this post will disable support for null SSL/TLS cipher suites on the DirectAccess server. This will result in reduced scalability and performance for all clients, including Windows 8.x and Windows 10. It is recommended that TLS 1.0 not be disabled on the DirectAccess server if at all possible.

When performing security hardening on the DirectAccess server it is not uncommon to disable weak cipher suites or insecure protocols such as SSL 3.0 and TLS 1.0. However, after disabling SSL 3.0 and TLS 1.0 you will find that it is no longer possible generate reports. Clicking the Generate Report link in the Remote Access Management console returns no data.

DirectAccess Reporting Fails after Disabling TLS 1.0

In addition, the System event log indicates Schannel errors with Event ID 36871. The error message states that “A fatal error occurred while creating a TLS client credential. The internal error state is 10013.”

DirectAccess Reporting Fails after Disabling TLS 1.0

To resolve this issue and restore DirectAccess reporting functionality you must enable the use of FIPS compliant encryption algorithms on the DirectAccess server. This change can be made locally or via Active Directory group policy. Open the Group Policy Management Console (gpmc.msc) for Active Directory GPO, or the Local Group Policy Editor (gpedit.msc) on the DirectAccess server and navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing and select Enabled.

DirectAccess Reporting Fails after Disabling TLS 1.0

If using Active Directory GPO, ensure that the GPO is applied all DirectAccess servers in the organization. A restart is not required for this setting to take effect. Once this change has been made, reporting should work as expected.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites
DirectAccess Video Training Courses on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book on Amazon.com

1 Comment
by Richard M. Hicks on June 26, 2017  •  Permalink
Posted in DirectAccess, Encryption, IP-HTTPS, IPv6 Transition, Remote Access, Security, SSL and TLS, troubleshooting, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on June 26, 2017

https://directaccess.richardhicks.com/2017/06/26/directaccess-reporting-fails-and-schannel-event-id-36871-after-disabling-tls-1-0/

« Older Posts
%d bloggers like this: