It wasn't that long ago when simply using SSL, or its successor TLS, on Windows servers was enough to ensure secure...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
communications. Times have certainly changed. SSL and TLS have gotten a bad rap as of late -- and deservedly so. Several serious security flaws have been uncovered in the past year alone that you need to be aware of. Some of them affect Windows servers and some don't. Here's an overview of what you need to know:
Heartbleed, a flaw in OpenSSL, which is often run on Windows servers, exploits weaknesses in the TLS heartbeat extension and can provide remote access to memory of servers and the clients connected to them.
POODLE (Padding Oracle On Downgraded Legacy Encryption) is a man-in-the-middle vulnerability that affects SSL version 3.0 and TLS versions 1.0 through 1.2.
There are also various SSL and TLS flaws dating back many years that can impact the security of a Windows server, including several that affect SSL version 2 and weak encryption ciphers. The interesting thing is that, based on my security assessment experience, most Windows servers are vulnerable to at least one of these flaws, and often several. They're often sitting out on the Internet, waiting to be exploited.
So, how do you find out whether these vulnerabilities exist on your Windows servers? It's pretty simple -- just a matter of doing the following:
- Checking for the missing patches using WSUS, MBSA, or a third-party patch manager (note: patches alone will not fix all of the known flaws with SSL/TLS, i.e. Heartbleed);
- Running vulnerability scans using a network vulnerability scanner such as Nexpose or GFI LanGuard or a Web vulnerability scanner such as Netsparker or Acunetix Web Vulnerability Scanner; and
- Using a website such as SSL LABS SSL Server Test and freakattack.com to determine your existing configurations and weaknesses.
Having said all of this about the dangers of SSL and TLS, I'm not convinced that "data in transit" is where the real risks lie. Still, if your Windows servers are running versions of SSL and TLS that are known to be vulnerable to attack, you're asking for trouble. Consider what can happen. Best case, you'll get dinged in a vulnerability assessment or audit and will be required to fix the issues. Worst case, someone exploits the Heartbleed or similar flaw and you'll experience a breach. You really don't want to fall into either category.
The best place to be with Windows Server is to fix these pesky security issues and be done with them. But don't stop here. You have to be vigilant; this means upping your game on security testing and the necessary maintenance required to keep your systems resilient from attack -- regardless of the perceived risks -- moving forward.
Read about hidden vulnerabilities in Windows Server IIS.
Find out more about the Heartbleed bug.
Your Exchange Server SSL configuration options.