The Heartbleed vulnerability in OpenSSL (CVE-2014-0160) has received a significant amount of attention recently. While the discovered issue is specific to OpenSSL, many customers are wondering whether this affects Microsoft’s offerings, specifically Windows and IIS.  Microsoft Account and Microsoft Azure, along with most Microsoft Services, were not impacted by the OpenSSL vulnerability. Windows’ implementation of SSL/TLS was also not impacted.

We also want to assure our customers that default configurations of Windows do not include OpenSSL, and are not impacted by this vulnerability.   Windows comes with its own encryption component called Secure Channel (a.k.a. SChannel), which is not susceptible to the Heartbleed vulnerability.

This applies to all Windows operating systems and IIS versions, up to and including IIS 8.5 running on any of the following operating systems:

•             Windows Server 2003 and 2003R2
•             Windows Server 2008
•             Windows Server 2008R2
•             Windows Server 2012
•             Windows Server 2012R2

Customers running software on Windows that uses OpenSSL instead of SChannel (for example, running the Windows version of Apache), may be vulnerable.  We recommend that all customers who may be vulnerable follow the guidance from their software distribution provider.  For more information and corrective action guidance, please see the information from US Cert here.

Microsoft’s Application Request Router (ARR) IIS Extension is a complex piece of software which integrates with several other components to do its job. These components are URL Rewrite, Web Farm Framework and ARR’s External Cache module. For things to work correctly, not only do you need all components, but they must also be installed in a specific order, which can be confusing. Several years ago, Microsoft introduced the Web Platform Installer (WebPI) mechanism, which makes it easy to manage installed components. It’s used with many things nowadays, and is also a good way to install ARR and all its components properly and easily.

Occasionally, though, you might find yourself in a situation where you still prefer to avoid using the WebPI installation option. For example, one such scenario is when installing ARR on the Server Core edition of Windows, where WebPI cannot be used. If so, another option you have is installing it using our IExpress package, which includes all the components together. To use it, download it from this page and install.

Another option is to install the components by hand, which will require you to download the components separately. This is the procedure for doing so:

1. Stop IIS first by typing net stop was /y and net stop wmsvc /y on an elevated command-line window:

*** note that WMSVC is the IIS Web Management Service, which might not be enabled on your server. In such a case, trying to stop it will result with The Web Management Service service is not started. This is not unusual and should not be cause for alarm.

2. Download and install the Web Farm Framework module. It is currently available in version 1.1

3. Download and install the External cache module. It is currently available in version 1.0

4. Download and install the URL Rewrite module. It is currently available in version 2.0 

5. Download and install ARR itself. It is currently available in version 3.0

6. Start the IIS services back (or, simply reboot your server) and you should be good to go!

If you need to do this on an X86 server, like windows 2008, you can download the X86 version of these components here:

· Web Farm Framework X86

· External cache X86

· URL Rewrite X86

· ARR X86

While security is on everyone’s mind, some organization with higher than usual security requirements have had some concerns regarding the encryption used in web-based transactions. Everyone knows that SSL encryption is pretty much the default for any web-based connection that requires security, but SSL itself is about much more than simply “have it/don’t have it”.

Those who deal a lot with security know that encryption is comprised of multiple parts. There is the protocol, such as TLS version 1, version 1.1 or 1.2; there’s the Cipher, which can include DES, Triple DES, RC2, RC4 and others; there’s the hash, which could be MD5 or SHA. For the cipher itself, one could have preference for a key length, which could be as short as 40 bit, or much longer. In the world of security, we refer to a combination of the above as a “Cipher Suite”.

Any software that supports encryption comes with a pre-configured set of supported suites, and some support more than others. For example, Windows 2008 and Window Vista included a whole slew of new protocols, making them better-built for the security-conscious organization. One topic that has come up recently is related to Windows support for Perfect Forward Secrecy. Perfect Forward Secrecy, or PFS for short, is the ability of certain encryption protocols to provide better security by using unique session keys that are not derived from the server’s private key. I won’t go into detail here, as PFS is well documented (for example, Vincent Bernat’s blog discusses it in detail http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html ), but this brings up the question “How can I take advantage of this awesome thing?”

Before we answer that, we should clarify that just because it’s more secure doesn’t automatically make it “better”. More security, you see, has a price, because the more complex negotiation process takes a toll on the computer’s resources, and the toll can be as high as 30%. If your server is highly utilized, then enabling PFS might saturate your CPU and require you to add another server to your array or pay more for resource usage if you are using a cloud-based service such as Azure. Another potential challenge with enabling PFS is that some older clients may not support it, leaving potential users reading error messages instead of your words of wisdom.

As I said, Windows 2008 and Vista added support for new stuff, and PFS is one of them. However, that doesn’t mean that it will automatically come into play. When a web client (such as Internet Explorer) and a web server (such as IIS) use encryption, the first step is negotiating the protocol. This is invisible to the naked eye, but if you examine a connection with a tool such as Network Monitor, you will see this:

What you see above is the 1^st part of the security negotiation, and that’s a request coming from the client (the browser). In the bottom part you can see a list of Cipher Suites that the client supports, and this way it’s laying the ground rules for the server.

The server looks at this list, and selects the first protocol that it supports, and when it replies to the client (one packet later), we can see it like this:

This, by the way, is a standard SSL handshake for an IE10 browser talking to an IIS 8.5 server with an out-of-the-box configuration.

If we were to have a desire to limit this to only protocols that use PFS, we would need to either configure our clients to only support such suites, or configure our servers to only agree to use such suites. If you are a user who wants to enjoy the utmost security and does not mind that many websites will refuse to talk to your browser, you can do so using Steve Riley’s guide at http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx . Here, however, we want to focus on the server side.

Before we go on, we should clarify that PFS is an encryption technology, and not a name of a specific protocol. The name of the actual protocol is Diffie-Hellman Ephemeral, or DHE for short (Diffie-Hellman refers to the encryption experts Bailey Diffie and Martin Hellman who have single-handedly developed some of the most important security and encryption technologies in history). As you might have noticed above, the list of suites supported by IE includes quite a few variations with DHE:

In the screenshot above, the bottom 7 suites all use DHE, and that’s good news! This list might seem short, but keep in mind that the encryption system in Windows (known as Schannel) actually supports much more. The above list is only items that have been specifically enabled. For a full list of supported suites, visit http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx

Since web browsers normally don’t prefer to use PFS, you might want to configure your server to enforce it. To do so, you can either tell your server to prefer suites with PFS, or you can go all-the-way and tell it to not accept any others. To do so, you can configure the list of supported protocols using the registry, as described in the following article: http://support.microsoft.com/kb/245030. Another option, which is quite easier, is to use IIS Crypto, a publicly available free tool by Nartac Software (https://www.nartac.com/Products/IISCrypto/Default.aspx). With IIS Crypto you can easily select which protocols, hashes, ciphers and key-exchanges are available for Schannel (and therefore IIS) to use, and you can also control the pecking order that affects the selection process:

Once you make changes to this, you can use Netmon to track the negotiation, and observe the suite that was used:

One last thing to keep in mind is that different clients, even if they do support PFS, may not support the same combination of encryption elements (that comprise a Cipher Suite, that is) and so if you are making changes to this configuration, make sure you test various browsers extensively, including various versions of these browsers. We’re sure you don’t want to get a nasty from that guy in accounting who still uses Internet Chameleon…right?!

Introduction

Application Request Routing (ARR) is a proxy-based routing module that uses HTTP headers, server variables, and load balance algorithms to determine how to forward HTTP requests to content servers. The release of ARR 3.0 in July 2013 contains a few new features, as well as bug fixes. The following information describes the new features and how to use them, as well as general information about ARR 3.0

Support matrix

ARR 3.0 was tested and is supported on Windows Server 2008, 2008 R2, 2012 and 2012 R2. It’s available in an X86 version for Windows Server 2008, and an X64 version, which is supported on all the above platforms.

Installation

Microsoft recommends ARR to be install from within the Web Platform Installer module (WebPI). To install from WebPI, type ARR in the search box, and click the appropriate item to install it.

It’s also possible to install ARR by downloading the MSI package, but please note that installing it directly requires the administrator to perform several steps in a specific order (normally, WebPI manages that automatically). These steps are:

1. Stop IIS by running the commands net stop was and net stop wmsvc on an elevated command-prompt window

2. Install URL rewrite (v2)

3. Install Web Farm Framework (v1)

4. Install ARR (v3)

5. Install the External Cache module (v1)

6. Start the IIS services back, or reboot the server.

To download the ARR MSI, visit this page. To download the MSI for the other pieces, visit this page.

New features

ARR 3.0 was released in Beta in December of 2012, and included the following new features:

· Retries for URL Health Monitoring

· Web Socket Support

The final version (July 2013) also adds support for Session affinity opt-out. Here are the details about these features.

Retries for URL Health Monitoring

As part of normal farm management, ARR performs health-test for configured web servers, so that if a server in the farm becomes unavailable, ARR would not forward requests to it. Before version 3, health monitoring would mark a server as unavailable if it fails to respond a single time. This may impact availability in certain situations, because intermittent network or application errors could lead to a server being marked as unavailable when in fact it was.

To address that, health-monitoring can now be configured by the administrator to retry, and conclude that the server is unavailable only after a defined retry-count. By default, Health-monitoring will retry the check 3 times, and the administrator can change the value to a different one by editing the configuration in ApplicationHost.config.

The following article describes additional parameters that can be configured as part of health monitoring: http://blogs.iis.net/richma/archive/2010/12/14/application-request-routing-health-check-features.aspx

WebSocket Support

With the release of Windows Server 2012, IIS added support for using WebSockets. Since WebSockets requires special handling by proxies, ARR needed some changes to be able to support this feature. This allows ARR to distinguish between a regular HTTP request and a WebSockets request, and handle them correctly.

WebSocket support requires the WebSocket feature to be installed on IIS, but does not require any other configuration or action. Install the feature using the Server Manager Add Roles and Features, and once that is complete, ARR 3.0 will handle the requests appropriately. The new feature supports both plain (ws://) and secure WebSocket (wss://) requests and it can also provide SSL offloading for WSS requests.

Session affinity opt-out

An important part of load balancing is maintaining affinity. Maintaining affinity means that once ARR routes a request to a server, subsequent requests from the same client that are a part of the same session should go to the same server. To maintain affinity, ARR attaches a unique affinity session cookie to each new session, with the selected server stored in the cookie. Once a subsequent request from the same client arrives, ARR decodes the cookie, extracts the server name, and knows to route that request to the same server. Similar methods are employed by all commercial reverse proxies. Here’s an example of such a cookie:

The challenge with this mechanism is that a session cookie can exist indefinitely, and so if the client’s browser remains open, it will continue serving back the affinity cookie, and be continuously redirected to that same server. In an environment where many clients keep their browsers open for extended period of time, this could, over time, lead to an imbalance in client distribution.

To address this, ARR 3.0 allows web applications to opt-out of session affinity. To do this, an application would need to set a special response-header that signals to ARR to disable affinity for the application.

The special response header is Arr-Disable-Session-Affinity and the application would set the value of the header to be either True or False. If the value of the header is true, ARR would not set the affinity cookie when responding to the client request. In such a situation, subsequent requests from the client would not have the affinity cookie in them, and so ARR would route that request to the backend servers based on the load balance algorithm. Note that this behavior could have serious impact on session-sensitive application, so enabling this on a web application must be considered carefully.

Troubleshooting

To help troubleshoot potential issues, FREB (Failed Requests Tracing – formerly known as Failed Request Event Buffering) has specific events for WebSocket requests. The WebSocket protocol mandates that when a WebSocket connection is initiated by a client, the accepting server should reply with a 101 status code, along with a Sec-WebSocket-Accept key. In the event a connection is accepted, IIS’s WebSocket module will raise a FREB event titled WEBSOCKET_HANDSHAKE_SUCCESS. If there is a problem, a failed event will be raised. By setting the appropriate filters in FREB, you can capture and examine these events:

When enabling FREB, keep in mind that setting a trace for success-type events (such as 101 and 200 status codes) on a production server would result in a large number of events, which could increase the load on the server to unacceptable levels, and is therefore not recommended.

In addition, new performance counters that are specific for WebSockets have been added to Windows, and they are under the W3SVC_W3WP group in PerfMon:

Blog post by Erez Benari and Jenny Lawrance

When Christopher Bullock wrote about the certainties in life in his book The Political History of the Devil, he probably should have added a 3^rd certainty…that your certificates WILL expire and you’ll have to renew them. I think we can forgive that, as he wrote the book in 1726 and websites weren’t as popular as they are today. However, the topic of certificate renewal is one that certainly plagues the nightmares of every seasoned system administrator.

Ultimately, if you’re an efficient fellow, you can try to have all your certificate expire around the same date, or set reminders in Outlook to remind you about the upcoming expiration, but in reality, it’s the sort of things that tend to get missed even by the most experienced engineers. Even if you do get it right, or have your certificates automatically renew, there’s still the issue of certificate rebind. When an IIS site is configured for a certificate, it has to be re-bound when the certificate is renewed, and if you don’t perform this (by going to the site binding dialog, and selecting the new certificate from the certificate drop-down), you ARE going to get some nasty phone calls.

To make things easier, Microsoft has implemented a new helper mechanism in windows called Certificate Services Lifecycle Notifications. This mechanism is part of Windows 8 and Windows 2012, and it creates system events when certain certificate-related things happen. For example, when a certificate is about to expire (a day before expiration), an event with ID 1003 will be logged under /Applications and Services Logs/Microsoft/Windows/CertificateServicesClient-Lifecycle-System or /Applications and Services Logs/Microsoft/Windows/CertificateServicesClient-Lifecycle-User:

The details pane will show more info, such as the certificate’s subject name and thumbprint:

Other events that might be recorded as part of this mechanism are:

1. New certificate has been installed

2. Certificate has been renewed or replaced

3. Certificate has expired

4. Certificate has been deleted

5. Certificate has been archived

6. Certificate has been exported

Because these events are now logged, administrators can make use of them to help them take care of the other aspects of certificate management. For example, you can use Task Manager to trigger a task when one of these events occur, and the task can do whatever you need it to do, from a simple pop-up notification to the administrator all the way to complex code or scripts that can cure cancer on-queue. The following wiki article by Kurt Hudson details this mechanism and some of the things you can do with it:

http://social.technet.microsoft.com/wiki/contents/articles/14250.certificate-services-lifecycle-notifications.aspx

To take this a step further, the IIS team has implemented some new functionality in IIS 8.5, which is part of the upcoming Windows 2012 R2 release. This functionality is designed to take advantage of the same notification mechanism and automatically re-bind a certificate that has been renewed.

To make this happen, IIS can automatically register a task in the system’s Task Scheduler, and the task is keyed to trigger upon a certificate-renewal event (event ID 1001). When such an event happens (either when the administrator has manually renewed the certificate, or if it renews with Auto-enrollment), the scheduled task runs IIS’s command-line based tool APPCMD, and gives it the thumbprint of the old (expired) certificate and the thumbprint of the new one. Using these two parameters, APPCMD locates the websites which are bound to the old certificate and rebinds them to the new one.

As far as the user-interface goes, the IIS console now offers the following option, which allows the administrator to enable or disable this functionality:

The tasks created by this mechanism in Task Scheduler can be viewed by opening up Task Scheduler, and navigating to /Microsoft/Windows/CertificateServicesClient, and as you can see, it shows the parameters sent to APPCMD:

If you disable this function in IIS Manager, the task is deleted. This is a good opportunity to note that fiddling with the settings in this task or deleting it manually is not supported, and could have unpredictable results, so don’t do it.

With this feature, the process of certificate renewal can finally be put in the “fugget about it” pile. Simply setup your certificates to automatically renew with Autoenrollment, enable this feature on your IIS servers and go back to reading The Political History of the Devil.