Almost every organization these days has some sort of internal application that is Web based. Whether it’s a help desk tracking system, or a full-blown intranet, Web applications abound. As Web-based solutions continue to proliferate, it is becoming more and more important to protect the information on those sites, and it’s becoming harder and harder to protect the user’s password. Certificates provide a good way to secure user passwords, but you need a way to create certificates without having to pay lots of money to certificate-signing agencies. Self-signing certificates are the way to go.
Single sign-on: Blessing or curse?
Most organizations are pressing forward with a single sign-on project. These projects are designed to make every application operate with the same user credentials so users don’t have to remember different user names for every system, and so when users change their passwords, they don’t have to change them on every system.
Even if your organization doesn’t have a single sign-on initiative, it’s likely that you’re using the integrated security in IIS to allow users to log on with their LAN accounts. This is a great way to help reduce the complexity of having to know application passwords, but it means that every time a user authenticates to the Web, his or her password moves across the network and could be captured.
Authentication in IIS has three basic forms: Basic (plain text) Authentication, Digest Authentication, and Integrated Windows Authentication. The security implications of using basic are well known. Basic Authentication’s weaknesses are so well known, in fact, that Microsoft displays a warning if you try to turn it on, as shown in Figure A. Passwords transmitted with Basic Authentication can be captured from the network using readily available software and almost no effort.
|Here is Microsoft’s warning about Basic Authentication.|
Digest Authentication, new to IIS 5.0 and IE 5.0, has some pretty hefty requirements. First, you must be using Active Directory. Second, you must be using IIS on a domain controller. Finally, you must have turned on two-way passwords. This is something that is never recommended because someone can easily get the passwords of the users on the system if the server is ever physically taken. Therefore, naturally, you'll almost never select Digest Authentication.
Integrated Windows Authentication is better, in that it can be used without the forgoing restrictions. However, it also requires Internet Explorer. That means if your users like Netscape or some other browser, this kind of authentication won’t work. The net effect is that you may not be able to use this kind of authentication.
Of course, you can select multiple kinds of authentication for your Web server. You could let the Internet Explorer users authenticate with the Integrated Windows Authentication and then allow the other users to authenticate with Basic Authentication. Of course, that would still mean that non-IE users’ passwords would be vulnerable to snooping.
There are two key elements of Web authentication that are critical to realizing just how dangerous Basic Authentication is. First, authentication information is sent with each request to the Web server. Because the Web is stateless, it doesn’t remember the user from the first request to the second. Along with each request, the browser diligently resubmits the user’s password so that the Web server can determine whether the user has access to the page or not.
The result of this is that even though users are only prompted for their passwords once, their passwords can be transmitted over the network hundreds (or thousands) of times in the case of a single session. This greatly increases the chances that the password will be picked up off the network by some unscrupulous person.
The second key element is that the server cannot dictate through what methods the Web browser will submit the password. Although most browsers try the strongest password mechanism they know first, this is not technically required. This means that even though you have not turned on Basic Authentication, the Web browser might try to send a request to the server with Basic Authentication. This could ultimately reveal the user’s password.
Another related problem with Web authentication is that Integrated Windows Authentication cannot be passed from one server to another. So if you’re using the user’s credentials to authenticate to a SQL server or Exchange server that is not on the same server, you won’t be able to use Integrated Windows Authentication.
Unfortunately, in many cases, you’re forced to address the potential that Basic Authentication may be used or attempted with the browser. The only solution to this that ensures that the password can never be observed over the network is to use SSL.
As you know, SSL encrypts Web traffic so that it cannot be overseen by anyone else. However, SSL also encrypts the user’s requests, authentication, and any posted form data. This means that when using SSL, even Basic Authentication is protected from snooping eyes.
Turning on SSL
Turning on SSL on your Web server requires that you obtain a certificate first. The certificate is used to encapsulate the encryption keys used by SSL during the initialization phase of the conversation and to verify the identity of the server to the client machine.
Typically, you get a certificate from a certification authority (CA) that is trusted by the browsers that your users have. Companies like Verisign, Thawte, and others offer these certificates for varying prices. When a browser encounters an SSL site, it checks the certificate and determines if the certificate was created by a root certificate authority that it trusts. The trusted root list is defaulted when you install the browser, but it can be added to, or taken away from by the administrator as needed.
Because you want to ensure that the browser trusts the root certificate authority when working on the Internet, you’ll rarely use anything except for a certificate signed by one of the default-trusted roots. However, for internal applications you can create, sign, and use your own certificates.
Windows 2000 offers a Certificate Services option that allows any Windows 2000 computer to become a certificate authority. This means that you can issue your own certificates for SSL as well as certificates for user signing. User signing allows users to sign messages to provide proof that they were the originator and that the message wasn’t tampered with.
Installing Certificate Services
The process of installing Certificate Services is slightly more involved than selecting another Windows 2000 component because there is information that is bound into the certificate authority’s root certificate. The process of installing Certificate Services is rather simple.
Start the Add/Remove Programs applet by clicking Start-Settings-Control Panel-Add/Remove Programs. Click the Add/Remove Windows Components option. This will display the Windows Components dialog, as shown in Figure B.
|Here is the Windows Components dialog.|
Click the checkbox to the left of Certificate Services. A warning, as shown in Figure C, will appear.
|Certificate Services warns that the domain membership cannot be changed.|
Click Yes to the warning that you cannot join or be removed from a domain or rename the computer once Certificate Services have been installed. This will display the Certificate Authority Type dialog, as shown in Figure D.
|Here you need to select the certificate authority type.|
Select the type of certificate authority that you want to install. In most cases, an Enterprise root CA is the best choice because it will work in conjunction with Active Directory. Click the Next button to show the data entry dialog, as shown in Figure E.
|Here you can see the certificate authority identification information.|
Enter the identifying information for the CA in this dialog. This information will be bound into the certificate authority’s root certificate. This means that it will be visible to a client, so care should be taken in the information that is entered here. Note that you’re selecting the length of validity for the CA on the bottom. Typically, you’ll want this to be a fairly large number so that the CA will be able to issue certificates for a long time to come. Once the expiration has been reached, you will no longer be able to issue certificates from Certificate Services. Click the Next button to move to the data storage step, as shown in Figure F.
|Here you will enter the Certificate Services storage location.|
Enter the paths for the Certificate Services information, or accept the defaults, and click Next to continue to the warning shown in Figure G.
|Note that Certificate Services requires an IIS restart.|
If you have IIS already installed on the computer, Click OK at the warning that IIS will be shut down. When the installation has finished, click the Finish button.
Issuing an SSL certificate
The process of issuing an SSL certificate follows a surprisingly similar process. However, this time you start with a Web browser pointed at the server where you installed the Certificate Services. Start a Web browser and point it to http://localhost/certsrv. Replace localhost with the name of the server you installed Certificate Services on if you are not on that server. The Welcome screen for Certificate Services is shown in Figure H.
|This is the Welcome screen for the Certificate Services Web site.|
Accept the default option to request a certificate and click the Next button to show the certificate selection Web page, as shown in Figure I.
|Here you need to select the certificate type.|
Click the Advanced request radio button because you’re not requesting a user certificate. Click the Next button. Accept the default to submit the request via form and click Next.
Next you’ll see the certificate request form. In the Certificate template box, select the Web Server certificate. The rest of the dialog will change to allow you to specify the basic information for the Web site. Enter the basic information about the Web site and scroll down to the Key Options section.
In the CSP box, select the cryptographic provider you want to use. The Microsoft Base Cryptographic Provider is acceptable for testing, but you should consider a more secure provider, such as the Microsoft Strong Cryptographic Provider. Make sure that the Key Usage is set to Both. You can choose any key size you would like; however, the longer the key, the more intense the processing. Click the Submit button to create the certificate. Click the link to install the certificate.
Activating SSL on a Web site
Once you have a certificate, it’s time to install it on your Web site. To do so, open up Internet Services Manager from the Start-Programs-Administrative Tools folder. Expand the local computer, right click the Web site to secure and select properties.
Click the Directory Security tab. Next, Click the Server Certificate button. After that, click the Next button to advance beyond the welcome screen. Click Assign An Existing Certificate and click Next.
Select the certificate you issued and installed above. Click the Next button to continue. Confirm the details of the certificate and click Next. Click the Finish button to complete the installation of the certificate.
Click the Web Site tab and make sure that there is an SSL port specified. It should be 443 by default. Once you’re done, click the OK button and close the Internet Services Manager.