Thursday, April 28, 2016

NetScaler VPX - load balance Exchange - Part 6 (SSL Offloading - Security Risks)

In my previous blog post, I enabled SSL Offloading which has one remarkable disadvantage: traffic between the NetScaler SNIP (subnet address of the NetScaler) and the Exchange server(s) is not encrypted. How much of a risk does this represent? It all depends on your security requirements. Some organizations may consider (accurately or not) that their internal network is secure and that unencrypted data is not a significant risk. Other organizations may have policies that do not allow data to be decrypted elsewhere than at the two endpoints exchanging the data.

But what exactly could we "see" if the traffic (for Outlook Web App in this case) is unencrypted? Usernames and especially passwords in clear text would be the worst scenario. But could we see anything else?

I attempted to respond to this question by capturing packets between the NetScaler and Exchange with WireShark.


I installed WireShark 2.0.2 on the Exchange server and created what is known as a "capture filter" so only data passing between the NetScaler SNIP and the Exchange server would be collected.

I will not present the use of WireShark in detail but here is the text I entered for the capture filter:


This is the "SNIP" (subnet IP) of the NetScaler VPX.

Note: for those not familiar with the basic use of WireShark (how to start and stop a capture, how to create capture and display filters, how to search for various elements (strings for example) in captured packets, I would recommend you consult one of the numerous tutorials or videos online.

Likewise, I assume basic knowledge of Exchange (2010) administration. In the paragraphs below, I have screenshots of the OWA properties page in the Exchange Management Console (EMC): Server Configuration > Client Access. I will not present a step-by-step path to these pages or how to change settings. This is also true of the IIS Manager and browsing among the different properties of the different virtual directories.

In each case (see below) I started the capture just before attempting to login to OWA with Internet Explorer 11. Once the test user was logged in, I stopped the capture.

The test username and password are, respectively:
  • alan.reid
  • MyPassword123#

Yes, it is useful to know these credentials beforehand but I learned that they can be easily detected in the captured data regardless, by simply searching for the string "password".

Forms-based authentication

For my first attempt, the OWA virtual directory was configured with "forms-based authentication". This is how the authentication settings appear...

In Exchange:

And in IIS Manager:

Remember! SSL terminates at the NetScaler. SSL is not enabled between the NetScaler and the Exchange server where the packet capture was performed.

Searching for the string "password" (without quotes) in the packet details produced the following results:

User credentials are easily visible (no need to highlight in bright yellow).

Reminder: when forms-based authentication is selected, the user will see a logon page similar to this:

Integrated Windows Authentication

What about Windows Authentication? I thought that with this type of authentication, at least the password would be encrypted. With this hypothesis in mind, I changed the OWA authentication settings so they looked like this...

In Exchange:

In IIS Manager:

Note: after this change to the virtual directory settings, a message displays, reminding us to execute the command "iisreset /noforce" so the new settings take effect. Make sure you do this. Otherwise, results may be inconsistent and confusing.

Note: make changes to authentication settings with the EMC in Exchange (or the EMS if you prefer the command line). I only show the IIS Manager settings for reference.

Windows Authentication is an improvement. The password is not sent in clear text. If we search the packet details, with the same settings as those above, we observe that no such string can be found:

We can observe the name of the user but the NTLM authentication does protect the password from packet capture and analysis. Below, we can see the NTLM activity but not the password itself (only the username):

Note: NTLM authentication and Windows Authentication are more or less synonymous - at least for this experiment.

Reminder: when (Integrated) Windows Authentication is selected, the user will either see a logon page like this...

Or... OWA will open automatically with no need to re-enter user credentials.

Some clarification: Integrated Windows Authentication should allow us to open OWA without having to enter our credentials a second time. This type of authentication uses the credentials that we used to login to the client machine itself. There are some conditions however.
  • The (Windows) client machine must be a domain member.
  • Under the Internet Options "Advanced" tab, the setting "Enable integrated Windows authentication" must be checked.
  • The URL for the OWA website must be added to Local Intranet sites under the "Security" tab of Internet Explorer.
Even then, I was only able to make this work after a complete reboot of both the client machine and the Exchange servers (although this may not be absolutely necessary).


With forms-based authentication, SSL Offloading exposes both the username and the password. Even with integrated Windows authentication, SSL offloading exposes the username. Moreover, elements of the OWA webpage are also visible, for example the names of persons with whom the user is corresponding. Wireshark allows us to export elements such as images using "File - Export Object - HTTP" and is apparently able to reconstitute an entire webpage (although some elements may be absent). In summary, SSL Offloading represents a security risk if we cannot guarantee that the network between the NetScaler and the Exchange server(s) is indeed secure. Since SSL Offloading is a feature on most load balancers, this remark is valid for load balancers in general (and not just the NetScaler product suite).

No comments:

Post a Comment