Implementing SSL Encryption and HTTPS

for RuBoard

As you may know, the Secure Sockets Layer (SSL) was created to provide a secure means of transferring data across a network using protocols supported by TCP/IP. HTTP, SMTP, and POP3 are examples of protocols that are capable of supporting SSL. By default, this layer operates (or listens) on port 443. The way it works is based on a rather simple principle known as public key encryption. Public key encryption relies on key pairs. With all these references to keys, it may be important to remind you that a key is merely a value used to encrypt and decrypt information. A password is an example of a key. .NET provides many key generation options that enable developers to use this technology with their own programs. One example of this is the RngCryptoServiceProvider class. Just two lines of C# code

 System.Security.Cryptography.RNGCryptoServiceProvider rng = new System.Security.Cryptography.RNGCryptoServiceProvider(); 

creates the instance. Two more lines of code

 byte[] random = new Byte[128]; rng.GetBytes(random); 

enable you to generate Random Number encryption keys. If you would like to see the results of this key in a simple display example, add the lines of code just shown to your code-behind page's Page_Load event and add Response.Write(System.Convert. ToBase64String(random)); . The results will look something like bvc8wwT3tJHhTuaqP kIY1WirlANWxl38FnBxb0s9umLyhe277ta4Z5nneQFTbSRzpsHHj4I2+34Z7KGi22bUVNGshXX 6nBUR4y/299MLyfjyvrTa1iq3FLQs0AXhrZpjehlpurzpGA7LKDUrN3sQ97N/qklHZzHqZuzAM 4IsViU= . To use SSL, you must first obtain a certificate from a certificate authority ”VeriSign or an internal Windows 2000 certificate server, for example. This certificate will contain two keys, one public and one private. The use of these keys in SSL is referred to as asymmetric, as whatever the private key encrypts, the public key decrypts, and vice versa. (In symmetric key encryption, the same keys are used for both encryption and decryption of information.) Once you have obtained and installed the certificate, configure whatever server type you need the encrypted services running on, and that is basically it. Now that you have this new toy, what does it do? How does it do it? Why is it secure? What does a digital certificate look like? Listing 16.1 illustrates a sample digital certificate.

Listing 16.1 Sample Digital Certificate

 -----BEGIN CERTIFICATE----- CBHcm91cCBDQS5jcmwwRqBEoEKGQGZpbGU6Ly9cXENFUlRTUlZcQ2VydFNydlxDZXJ0RW5yb2xsXE1TIENl cnRTcnYgVGVzdCBHcm91cCBDQS5jcmwwCQYDVR0TBAIwADBiBggrBgEFBQcBAQRWMFQwUgYIKwYBBQUHMAK GRmh0dHA6Ly9DRVJUU1JWL0NlcnRTcnYvQ2VydEVucm9sbC9DRVJUU1JWX01TIENlcnRTcnYgVGVzdCBHcm 91cCBDQS5jcnQwDQYJKoZIhvcNAQEEBQADQQAhq70nRlse0ulPstU+IWdjeNj5p -----END CERTIFICATE----- 

NOTE

Remember that in order to use SSL with a Web browser, that browser must support at least a 40-bit encryption algorithm and public key encryption. Most browsers (Internet Explorer, Netscape, and AOL) of version 3.0 and above support SSL.

SSL provides a protocol by which all information during a session is sent by the server and the client is encrypted. This means that when a client makes a request over HTTPS to a server, the server's public key is sent to the browser. The browser uses this key to encrypt the information before it leaves the client. Once the server gets the information, it attempts to decrypt it using its own key and finishing whatever process it was called to do, such as authenticating a user or processing a sensitive transaction.

To explain a little better how it does that, let's look at what the certificate does. The certificate contains information that guarantees that the server being visited is indeed the server it says it is. Again, a certificate will contain both a public and a private encryption key. Both the server and the client will have what are called trusted root certificates. These certificates basically indicate to the machine that if a certificate key is received and it came from a trusted source, it should be okay. Assuming that all checks out, meaning the client and server agree on a key to use, during the process (if not, your browser or managed network client should let you know), the server creates a unique session with the client and the data is encrypted using the server's key pair. As an added benefit, starting with Windows NT 4.0, a client certificate can be mapped to a specific user account. This allows the server to verify the caller's identity without sending any information to it. This feature comes in handy when you are using Web services across the Internet and need to validate a caller before allowing it access to your code.

NOTE

Remember that in order to further secure your files, you should use the NTFS file system. This is the default for Windows NT and 2000 and is even supported in XP Home Edition. If your hard drive is currently formatted using any version of FAT, you can use the Convert utility to fix this by executing the following DOS command from a command prompt window, or by selecting Start, Run and typing this in the resulting dialog box:

convert < drive letter > /FS:NTFS

Of course, replace the < drive letter > placeholder with the actual drive letter you wish to convert. Once converted to NTFS, a drive cannot be converted back to FAT without a third-party tool.

More About Certificates ”Options and Installing

Since the use of certificates is becoming more and more vital , this section can serve as either a refresher or an introduction to some basics about using certificates. This is not intended to be a definitive, all-inclusive directive, but rather a tool that, from a high level, eliminates the excuse , "I don't know how to implement SSL on IIS." The purpose of this illustration is based on real-world experience with MSCE+I's, MCSD+I's, and other senior-level developers who could not correctly request and install a certificate.

Figures 16.1 “16.12 illustrate the process of installing a certificate and enabling SSL on IIS using Windows 2000 and IIS 5.0. The steps for doing this on IIS 4.0 are quite similar. This is the first step to encrypting the data during an HTTPS session. First, using whatever method you are most comfortable with, open the Internet Information Services Management Console. In Windows 2000 and up, the Certificate Manager enables you to install and use certificates. This can be accessed in one of many ways. The easiest is by double-clicking your certificate file (.cer, for example) when you receive it. The associated wizard will then walk you through the steps involved in determining where to place your certificate. Another way, for the more advanced user, is to use the Microsoft Management Console (MMC). Using MMC, you can add the snap-in for certificate services and completely manage the importing, exporting, and requesting of certificates. Figure 16.1 shows this as access through the Computer Management Console.

Figure 16.1. IIS Computer Management Console.

Once you have received and installed a server certificate, IIS recognizes this and some options that were previously disabled are now available. Figure 16.2 is the result of right-clicking the Default Web Site folder and selecting Properties. Notice that the Server Certificate button is now enabled.

Figure 16.2. The Default Web Site Properties dialog.

When you click on the Server Certificate button, the Web Server Certificate Wizard is launched. Figure 16.3 shows this wizard's introductory dialog.

Figure 16.3. The Web Server Certificate Wizard.

Clicking the Next button brings up a dialog to select what you would like to do. Figure 16.4 shows the selection of the Assign an Existing Certificate option. Since we are importing a certificate that is already installed (read the paragraph at the beginning of this section if you missed the installation), none of the other options apply.

Figure 16.4. The IIS Certificate Wizard.

Next you will be presented with a list of the certificates installed on your machine that are available to serve as server authentication certificates. Figure 16.5 shows this dialog.

Figure 16.5. The Available Certificates dialog.

The next dialog box shown is basically a recap of the information contained within the certificate. Figure 16.6 illustrates what this might look like, based on information in a demonstration certificate.

Figure 16.6. The Certificate Summary dialog.

The end result is the Completing the Web Server Certificate Wizard screen shown in Figure 16.7. Basically, the only option here is to click Finish.

Figure 16.7. The Completing the Web Server Certificate Wizard dialog.

Now that the wizard is complete, you will notice that the other buttons under the Directory Security tab in the Default Web Site Properties dialog are available. Figure 16.8 is basically the same as Figure 16.2, except that we have configured IIS to know that a certificate is available.

Figure 16.8. The IIS Properties page.

Clicking on the View Certificate button brings up a dialog similar to the one shown in Figure 16.9. (Of course, unless you got your certificate from me and are using my machine, they will not be exactly alike.)

Figure 16.9. The Certificate dialog.

Now that the certificate is installed and configured, the SSL Port text box is now enabled (see Figure 16.10).

Figure 16.10. The Default Web Site Properties dialog with SSL enabled.

To actually enable SSL for a given site or directory, simply open the Properties for that site or virtual directory and adjust the appropriate settings on the Directory Security tab.

NOTE

It is recommended that you use SSL for every request that comes through your Web site that requires authentication. For example, in general for a publicly accessible area of your site, SSL may not be required; however, when a user reaches a form for entering sensitive information, SSL is enabled. The exception to this rule is where an entire site requires authentication to view any resource; in that case, the entire site may be protected under SSL.

Figure 16.11 shows the selections necessary on the Secure Communications dialog to establish secure connections on your IIS Web site.

Figure 16.11. The Secure Communications dialog.

Should users attempt to access the page via insecure means, they will get a message from the server similar to the one shown in Figure 16.12. You can prevent this page from being displayed by using a redirect page sending the request to the secure site.

Figure 16.12. HTTP 403.4 ”Forbidden message.

When you request a certificate, there are a few options to consider. Depending on the use of your application and your geographical location, your answers will vary. Keys come in different lengths; 40-bit, 128-bit, 256-bit, 512-bit, and 1024-bit sizes are common. Export versions of IIS are currently limited to using the 128-bit key to encrypt and decrypt data; however, you can still use up to a 512-bit key to protect the server data. Typically, it is recommended that you use the largest key available. The certificate authority you use will be able to provide you with more information on the available key sizes.

For more information about the many uses of certificates in Windows, consult the online help files for the product you are curious about using certificates with.

Considerations for Web Services

As Web services and remote objects will no doubt become the pre-eminent way that distributed applications are made available, this opens up some rather large security questions, beyond just using SSL. This is where remoting comes into play. This section covers some advanced topics in relation to remoting and how to maintain encryption of data elements when using the remoting framework. Remoting differs from Web services in that remoting offers more features and a certain fidelity not found in Web services.

NOTE

The term remoting is used to refer to the functionality provided for by the remoting framework part of the .NET Framework. As its name indicates, remoting provides several methods and interfaces enabling developers to create secure distributed applications. If you are unfamiliar with remoting, please view the .NET Framework SDK help files on remoting before reading further.

for RuBoard