WindowsNetworking.com Monthly Newsletter of April 2008 Sponsored by: ScriptLogic

Welcome to the WindowsNetworking.com newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: tshinder@windowsnetworking.com

1. The Promise and Perils of SSL Offloading

Performance is everything when making your Web servers available to Internet users. It is even more important when you publish ecommerce Web servers to the Internet, as every second a user has to wait in order to complete the transaction increases the risk that the user will bail out of the purchase. The problem with performance and ecommerce (or any secure server) is that SSL encryption can also slow down connections to your Web server.

One way you can deal with this slowdown is to use something called "SSL offloading". When you use SSL offloading, the Web server does not have to do any of the encryption work. Instead, you put a reverse Web proxy server in front of the Web server. The reverse Web proxy server impersonates your Web server and SSL connections are terminated on the external interface of the reverse Web proxy. Then the reverse Web proxy decrypts the SSL session and forwards the requests as unencrypted HTTP requests to the Web server.

This works great because the Web server has a lot going on and does not need to suffer from the processor overhead secondary to SSL encryption. However, you have to be aware that there are serious security implications of SSL offloading.

First, you must be absolutely sure that the path between the reverse Web proxy's internal interface and the Web server is secure and not accessible to anyone who could plug in a network sniffer. The problem with this assumption is that an intruder does not need a network tap to use a network sniffer. An intruder could place sniffer software on a server on the same network as the Web server and read all the information going to and from the ecommerce Web server. Perhaps the only truly secure connection would be a crossover cable between the internal interface of the Web proxy and the Web server. Do not depend on VLAN tagging, as VLAN hopping is a well-recognized exploit and VLAN tagging has never been promoted as a security solution.

Second, the external user has an implicit agreement with you that the SSL session is secured from end to end, and that no clear-text traffic is moving over the networks between the client and server. This is a reasonable expectation for the end-user, since you typically do not inform them that they are terminating their secure connections at a reverse Web proxy and then allowing clear text from the internal interface of the reverse Web proxy and Web server. If there is ever a security event due to the HTTP only connection from the reverse Web proxy to the Web server, you could potentially be held liable for not securing the connection from end to end.

While SSL offloading provides a great performance enhancing solution for publishing secure Web servers, you need to consider the network security and end user expectations in this scenario. If your company provides ecommerce or other services over secure SSL links, and you're deploying or considering deploying SSL offloading, make sure you review the security implications and also the possible legal implications of an SSL offloading solution. To this end, make sure you consult your corporate attorney and let him know of your plans.

What do you think? Is SSL offloading worth the potential security risks it imposes? Let me know! Write to me at tshinder@windowsnetworking.com with your opinions and observations.

See you next month. Thanks!

=======================

Quote of the Month - "Whosoever desires constant success must change his conduct with the times"
-- Niccolo Machiavelli

=======================

2. ISA Server 2006 Migration Guide - Order Today!

3. WindowsNetworking.com Articles of Interest

• Configuring Windows Server 2008 & Windows Vista Wireless connections from the CLI using netsh wlan
• Deploying Vista - Part 2: Understanding Windows Setup and the Windows Imaging File Format
• Pre-Installation Steps for Installing Windows Server 2008
• Readers' Choice Awards Yearly Round Up 2007
• High Assurance Strategies
• Deploying Data Protection Manager 2007 (Part 4)
• Testing Applications for Vista Compatibility, Part 6
• Deploying Vista - Part 3: Understanding Configuration Passes

4. KB Articles of the Month

• Hyper-V virtual machines cannot reach the network when the vLan tagging is enabled on a Windows Server 2008-based computer
• The Network Policy Server may not log successful authentication events or failed authentication events in Event Viewer in Windows Server 2008
• Description of what to consider when you deploy Windows Server 2008 failover cluster nodes on different, routed subnets
• Remote access policies that have conditions that are based on the NAS IPv6 Address attribute do not function correctly in Windows Server 2008
• No firewall is enabled after you upgrade a Windows Server 2003-based NAT/Basic Firewall router to Windows Server 2008
• The backup may fail when you use a third-party backup product to perform a backup on a Windows Server 2008-based NPS computer
• A handle leak occurs in a Server Message Block (SMB) session between two Windows Vista-based computers or between two Windows Server 2008-based computers

5. Windows Networking Tip of the Month

Traveling always makes for interesting network troubleshooting problems. I often wonder how non-professionals survive hotel and conference center networks. Well, I guess that most users who are not experienced in networking call the Help Desk. I have even called the help desk a couple of times, when I ran out of ideas on how to get my laptop to connect to the hotel's wired or wireless networks.

While the Help Desk was able to fix almost all of my problems, there was one time where we just could not get to the root of the networking issue. In this situation, I was at a hotel that had both a wired and wireless connection available. I first tried the wired connection, and when I plugged in, it said that the network was disconnected. I tried repairing the connection but that did not work, and then I restarted the computer and that didn't fix the problem either.

Then I decided to try the wireless connection. Windows XP wasn't able to see any wireless networks available. Again, I tried repairing the wireless connection, but that did not help. I figured I wasted enough time trying to figure this out myself and I would call the Help Desk. We spent the next two hours trying a wide variety of things and nothing worked. We finally gave up and I decided to use my Windows Mobile PDA phone as my workstation for that trip. It was not too bad, since I had a Bluetooth keyboard and most of my work was e-mail and simple Word docs, and the phone had both Word and Exchange ActiveSync on it.

It was not until the end of my five day stay at that hotel that I realized what the problem was. The last time I used the laptop, it was connected to another hotel network that supported 100Mbps wired and 802.11g wireless. So, in a fit of nerdiness, I hard coded the physical NIC to use only 100Mbps full duplex and only 802.11g wireless networks. Well, the hotel I was staying at had an old 10Mbps wired line and an 802.11b wireless network. Since I hard coded my NICs for newer networks, the connections to the older technology networks failed.

Something to keep in mind if you are a real network nerd and play with your laptop's configuration a lot.

6. Helpful Links

• Using Windows Server 2008 as a Workstation
• Windows Server 2008 Desktop Experience Feature
• Windows Server® 2008 Network Shell (Netsh) Technical Reference
• New Networking Features in Windows Server 2008 and Windows Vista
• Troubleshooting Network and Sharing Center

7. Ask Dr. Tom

QUESTION: Hi Tom,

I sometimes have problems trying to figure out why a computer cannot connect to the network. Is there any "first step" that you use in order to find out if there is any kind of connectivity? Thanks! -Andrew

ANSWER: Hi Andrew!

I typically use the standard approach to troubleshooting network connectivity. Start with layer 1 (physical) and work my way up. So, the first step is to check the NIC. Is the NIC light working? Is the switch to which the NIC is plugged into working? If you have NIC troubleshooting tools, such as those that come with the Intel NIC driver package, you can use those.

If the physical layer is OK, the next step is to work with the datalink layer. For example, suppose your computer cannot connect to the Internet. What you can do is do is ping the default gateway, since the computer has to use its default gateway to reach the Internet.

If you find that you cannot ping the default gateway, the next step is to see if you have datalink connectivity to the default gateway. Remember, computers use an ARP request to determine MAC address of computers on the same physical link. The ARP request and response allows machines to resolve the MAC address of a specific IP address on the same physical link.

The ping to the default gateway might fail because the gateway might not allow ping requests for security reasons. In order to see if the gateway computer actually exists, use the arp -g command. If you see that your computer was able to resolve the MAC address from the default gateway's IP address, then you know you have datalink layer connectivity to the default gateway.

QUESTION: Hi Tom,

I run a Microsoft network and my boss has asked me about SSL VPN solutions. I have looked at several hardware vendors for an SSL VPN solution, but I am wondering if there are any Microsoft SSL VPN offerings that might be more secure or easier to manage. Thanks! -Robert.

ANSWER: Hi Robert!

Good question! Microsoft actually has two SSL VPN solutions. One of them comes with the Windows Server 2008 operating system and the other is a separate, fully featured SSL VPN solution.

The Windows Server 2008 SSL VPN solution is SSTP. SSTP is the secure socket tunneling protocol and essentially wraps a PPP connection in an encrypted HTTP header. SSTP provides full network level connectivity in the same way that PPTP or L2TP/IPsec provides. SSTP works with the Windows Server 2008 Routing and Remote Access Service (RRAS).

For an industrial strength SSL VPN solution, you might want to take a look at the Microsoft IAG 2007 SSL VPN gateway. IAG 2007 is the result of Microsoft's acquisition of Whale. I have compared Whale with other SSL VPN solutions and a couple of things stand out regarding the IAG 2007. First, IAG 2007 provides a much more secure solution because of its advanced positive and negative logic filtering for services that are connected through the IAG 2007 device. Second, the IAG 2007 is probably the easiest SSL VPN solution to set up and configure, especially the endpoint detection feature, which is built in for IAG 2007 and is not third party add-on or acquisition that was pasted onto an existing SSL VPN solution.

The primary drawback (at least for many Microsoft admins) is that IAG 2007 is only available in an appliance form factor. There is no trial software that you can install for your own testing. However, you might be able to get a demonstration box to test it out. My preferred IAG 2007 vendor is Celestix.

Got a question for Dr. Tom? Send it to tshinder@windowsnetworking.com.