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: firstname.lastname@example.org
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 email@example.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"
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.
QUESTION: Hi Tom,
ANSWER: Hi Andrew!
QUESTION: Hi Tom,
ANSWER: Hi Robert!
Got a question for Dr. Tom? Send it to firstname.lastname@example.org.