Blogging Techstacks

Gripe: Marketing, Development, and URLs

Just wanted to rant about another pet peeve of mine. As far as I am concerned, the disconnect between Development and the Business is no more pronounced as when the URL that the business advertises is different from the url of the application. For example, Development recently deployed a tomcat web application to www.site.com/webapp (not the actual name) and the next day, Marketing blasts the URL out to 20 or 30 thousand prospects as www.site.com/WEBAPP.

I mean really....haven't these two teams been working closely for at least the past few months developing this application? Has Microsoft's case-insensitive URL's in IIS completely lowered the bar when it comes to basic web knowledge? URLs are supposed to be case sensitive.

Obviously, it's relatively easy to fix with redirects, rewrites, whatever but how many requests wound up failing before the engineering folks got involved?

Extended Validation SSL Certificates: Scam or Vital?

I am very interested in getting opinions from other administrators out there regarding extended validation ssl certificates. I can't really see how they are more useful in protecting an electronic commerce transaction over a "plain old SSL cert".

Taking the most expensive implementation from Verisign to illustrate my point, a standard SSL cert costs $399.00 for a cert that will expire in 12 months. "Upgrade" to a 128-bit only certificate will set you back $995.00. "Upgrading" that standard cert to an Extended Validation cert will cost you $995.00 too but if you also add-on the 128-bit only option to that EV cert, you are looking at almost $1,500.00 USD just to color the address bar green. A $1,200 markup seems like a lot to pay for something that didn't seem to me to be that big a problem in the first place--especially when it could very well (for all I know) be providing nothing more than a false sense of security.

For example, if my browser bar is green, does this mean that I need to no longer worry about making sure that SSLv2 or Null and Weak encryption ciphers are disabled? Something tells me that the answer to this is, "Ummm....No....". So what is it? Are you buying Extended Validation certificates or are you just implementing the strongest possible controls on your site and buying the no-frills cert? Are certificate vendors simply ripping us off by tricking users into looking for the green bar or are these certs doing something magical? Did sales increase drastically for those of you who have implemented them?

IIS: Disabling SSLv2 and Weak Ciphers

The big items that show up most commonly for me on our quarterly PCI Compliance scans of IIS sites is the ever-present HTTP TRACE/TRACK vulnerability and SSL related items. Breaking the SSL ones down further, the most common items that show up are SSLv2 being enabled and Null and Weak encryption ciphers are allowed. This post will provide you with the registry changes necessary to disable these items directly on your IIS servers. I do not know yet if they work on IIS7 but they work fine on IIS4 through IIS6. If you are also looking for information on dealing with TRACE and TRACK, this article might be useful.

A few quarters back when we started taking this PCI stuff seriously, I was a bit surprised to see that the links for remediation provided to us from our scanning vendor resulted in Not Found responses on Microsoft's KB. So, after doing some googling and before-and-after experimentation using Foundstone's SSLDigger, I've come up with the following .reg file that you can import into your registry--or you can just enter them in manually. TRY IT OUT ON SOME TEST MACHINES OR VIRTUAL MACHINES YOU DON'T CARE ABOUT A FEW TIMES FIRST before you tackle your production boxes. Also, don't forget the usual warnings about how modifying the registry can be hazardous, dangerous, heretical, etc. and don't forget to have backups of everything.   I did however merge the following onto my test and production systems with favorable results.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000

When merged into the Windows registry, this will disable PCT 1.0 and SSLv2. It will also disable NULL and Weak Ciphers. It is also much less expensive than buying the 128 bit-only and higher certificates from your certificate provider, which should make our friends in Accounting and Purchasing like us for a day or so.

Update: Nartac Software publishes a Windows tool named IIS Crypto that allows you to perform all of these changes and more without the need to import registry entries yourself.  The tool is free as well, which is a big bonus.

Windows Server 2008 Administrator's Companion

Microsoft IIS 7 Implementation and Administration (Mastering)