About IIS 6 Security

IIS 6.0 should be configured to use the strongest and most secure encryption methods available. This short guide will take you through the necessary steps for helping to pass stringent security scans for SSL enabled web servers.

Enabling SSL has both positive and negative issues. Confidentiality and positive site identification are very important gains, while slightly increased resource usage, more difficult troubleshooting, and the inability to host multiple websites on a single IP address are concerns to be addressed. However any web server that would transmit personal information or sensitive data must be protected with strong encryption.

Both PCT 1.0 and SSLv2 protocols have serious vulnerabilities[1]. Although the server will attempt to negotiate using the strongest protocols and encryption algorithms first and only drop to SSLv2 if necessary, the attacks on these protocols can be triggered as long as the protocol is enabled. Since all modern browsers have supported SSLv3 and TLSv1 for many years, there should be no requirement for SSLv2 in most circumstances.

FIPS 140-2 provides a standard method for ensuring that the encryption algorithms chosen meet the highest security standards. Using the strongest encryption methods that are certified by the US Government helps assure confidence in your systems.

Testing both before and after can be accomplished by using the SSLDigger[2] tool or using the Nessus scanning tool[3].

Please note that the following changes affect more than just IIS 6.0. The following changes concern the core cryptographic modules in the operating system used by all services and applications, such as IPSec. All these changes may be applied at the same time for a single reboot of the system.

Enabling FIPS 140-2 Encryption Algorithms

About the FIPS 140-2 standard:

The National Institute of Standards and Technology (NIST) issued the FIPS 140 Publication Series to coordinate the requirements and standards for cryptography modules which include both hardware and software components. Federal agencies and departments can validate that the module in use is covered by an existing FIPS 140-1 and FIPS 140-2 certificates which specifies the exact module name, hardware, software, firmware, and/or applet version numbers. The cryptographic modules are produced by the private sector or open source communities for use by the U.S. government and other regulated industries (such as financial and health-care institutions) that collect, store, transfer, share and disseminate "sensitive, but un-classified (SBU)" information.[4]

Enabling FIPS encryption algorithms on Windows 2003 is accomplished these steps.

1. Run GPEDIT.MSC from the Start / Run menu.

2. Navigate to Local Computer Policy – Computer configuration – Windows Settings – Security Settings – Local Policy – Security Options.

3. Select the option: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing. Enable this option.

4. Reboot the computer.

Please note that this group policy may (and should be) also be configured at the Active Directory OU level for easy distribution to multiple servers. This policy may also be assigned to all workstations and servers, however if you require encryption on file servers down level clients such as NT 4 and Windows 98 systems may not be able to communicate properly.

Disabling SSLv2 and PCT 1.0

SSL is not an encryption algorithm but is a method of setting up a secure connection using other encryption methods. Since the SSL options chosen apply to the OS and not specifically IIS, these choices also apply to other SSL enabled services such as POP3 and SMTP.

The SSLv2 and PCT 1.0 encryption protocol security flaws are best rectified by disabling SSLv2 and only using SSLv3 and TLSv1 protocols. All modern browsers support SSLv3 and TLSv1.

Having SSLv2 enabled on a web server is rated as a Medium Vulnerability within Verizon Business.

Save then import the following registry file contents into the server’s registry or make the changes manually, and then reboot the server.

Windows Registry Editor Version 5.00

[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

Manual Method[5]:

1. From the Start menu, click Run.

2. In the Open box, type Regedit.exe, and click OK.

3. Navigate to and double-click the following key in the registry:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\PCT 1.0\Server

4. From the Edit menu, point to Add, click DWORD Value and then add the following registry value: Enabled

5. Data: Set this to 0x00000000.

6. Repeat for the following registry key:
HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\SSL 2.0\Server

7. Quit Registry Editor.

8. Reboot the computer.

Enabling Kernel Mode SSL

Enabling kernel-mode Secure Sockets Layer (SSL) improves SSL performance because encryption and decryption operations take place in the faster processing space of the kernel. However, enabling kernel-mode SSL disables user-mode SSL. For more information, see Kernel-Mode SSL[6].

To configure SSL to run in kernel mode:

1. From the Start menu, click Run.

2. In the Open box, type Regedit.exe, and click OK.

3. Navigate to and double-click the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

4. From the Edit menu, point to Add, click DWORD Value and then add the following registry value: EnableKernelSSL

5. Data: Set this to 0x00000001 to use kernel-mode SSL instead of user-mode SSL.

6. Quit Registry Editor.

7. Restart IIS.

The following restrictions apply to running SSL in kernel mode:

· Client certificates are not supported.

· RC2 ciphers are not supported.[7]

· The Private Communications Technology (PCT) 1.0 protocol is not supported.[8]

· Configuration changes to server certificates require a restart of the HTTP service.

· ISAPI GetServerVariable calls for certificate information do not work.

· Bulk encryption offload is not supported.

· ISAPI filters do not get READ RAW notifications regardless of the security of the connection. This restriction affects only IIS 5.0 compatibility mode, because IIS 6.0 worker process isolation mode does not support READ RAW DATA filters regardless of the setting for kernel-mode SSL.

SSL Certificate Subject Alternate Names

Using Subject Alternate Names (SAN) is a method for having a single SSL certificate show as valid for multiple hostnames. When requesting the SSL certificate from the Certificate Authority you must request the SAN at that point.

An example would be using a web browser to visit https://hostname.domainname.com and seeing the certificate as valid, as the SSL certificate name was hostname.domainname.com. However, if your workstation is in the domainname.com domain also, you’d be able to visit https://hostname and connect to the site, but you would receive an SSL warning as the name does not match the certificate name. This may be frustrating to the end user.

Utilizing the SAN, the certificate would be created and assigned the name of both hostname.domainname.com and hostname and would validate for both correctly.

To request a certificate with Subject Alternate Name from Microsoft Certificate Authority server:

1. Choose Request certificate

2. Choose Submit an advanced certificate request

3. Choose Create and submit a request to this CA

4. Enter the primary fully qualified domain name in the Name field

5. Choose all other options as required for your request

6. Enter the following in Attributes:
SAN:DNS={primary FQDN}&DNS={hostname only}&DNS={other alternate names as necessary}

7. Click "Submit"

For the example above enter in Attributes:

SAN:DNS=hostname.domainname.com&DNS=hostname

The Certificate Authority must be configured to allow Subject Alternate Names one time before this will work. On the Windows 2003 Certificate Authority server’s command prompt enter:

1. certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

2. net stop certsvc

3. net start certsvc

[1] http://xforce.iss.net/xforce/alerts/id/168 http://www.openssl.org/news/secadv_20051011.txt

[2] http://www.foundstone.com/us/resources/proddesc/ssldigger.htm

[3] http://nessus.org

[4] http://en.wikipedia.org/wiki/FIPS_140-2

[5] http://support.microsoft.com/kb/187498/EN-US/

[6]http://technet2.microsoft.com/WindowsServer/en/library/85A628D9-5E20-4D79-911C-8063F0533CC61033.mspx

[7] RC2 is blocked by FIPS 140-2 mode.

[8] PCT 1.0 is blocked by disabling SSLv2.