SSL

SSL technology is used to encrypt communication between a client and a Web site. SSL is well known for its use in commercial Web sites, but it is equally valuable in almost any type of distributed application.

For a server to support SSL connections, it must have an X.509 digital certificate. This certificate indicates that the server identity is registered with a valid Certificate Authority (CA). We'll consider how to obtain a certificate in the next section.

A secure SSL session unfolds over several steps. The process is outlined here:

  1. The client requests an SSL connection.

  2. The server signs its certificate and sends it to the client.

  3. The client verifies that the certificate was issued by a CA it trusts, matches the expected server, and has not expired or been revoked. The client continues to the next step only if all this information is validated.

  4. The client tells the server what encryption key lengths it supports.

  5. The server chooses the strongest key length that is supported by both the client and server, and informs the client what it is.

  6. The client randomly generates a session key, encrypts it using the server's public key, and sends it to the server.

  7. The server decrypts the session key using its private key. Both the client and server now have a session key they can use to encrypt communication for the duration of the session.

SSL and Certificates

To use SSL, you first need to install a server-side certificate using IIS. You can generate your own certificate for testing (using Certificate Server from Windows 2000 Server or Windows .NET Server, which requires Active Directory). When deploying a public application, however, you will probably want to use a genuine certificate authority such as VeriSign (http://www.verisign.com).

One of the easiest ways to purchase a certificate is to create and e-mail a certificate request to the appropriate Certificate Authority. IIS Manager allows you to create a certificate request automatically by following these steps:

  1. Expand the Web Sites group, right-click on your Web site (often called Default Web Site), and choose Properties.

  2. In the Directory Security tab, click the Server Certificate button. This starts the IIS Certificate Wizard that requests some basic organization information and generates a request file.

  3. Complete all steps of the wizard. Figure 13-7 shows one step, where you must choose the Web site name and key length. The larger the bit length, the stronger the key.

    Figure 13-7. The IIS Certificate Wizard

    graphics/f13dp07.jpg

  4. E-mail the generated request file (which is automatically encrypted using the public key of the Certificate Authority) to the CA.

  5. You will receive a certificate that you can install in IIS to complete the request, along with additional step-by-step instructions from the CA.

You can read much more information about certificate requests and how to use certificates with IIS in detail in the online IIS help, at http://localhost/iisHelp.

Certificates Establish Trust

In a distributed application, identity verification is a thorny problem. Just how can a client be sure that the server is who it claims to be? A clever attacker could use IP spoofing or some other advanced technique to masquerade as the server, create a secure SSL session with an unsuspecting client, and then seamlessly decrypt all the sensitive information the client sends.

SSL solves this problem using digital certificates. Certificates have two purposes:

  • They show that the server is registered with a Certificate Authority (CA). In other words, the CA vouches for the server's identity.

  • The server is not known to be malicious. If it is, its certificate will be revoked.

Clients use certificates to partially validate the server's identity. In other words, clients make the decision "I will trust this server because the CA vouches that it is Amazon.com," not "I trust this server because it claims to be Amazon.com." Every computer is preconfigured with a list of trusted CAs. This list can be modified using a tool such as makecert.exe (which is installed with the .NET Framework). Certificates also contain a small set of identifying information, including the holder's name, organization, and address; the holder's public key; validation dates; and a unique serial number.

Certificates are fundamentally limited in scope. They don't indicate that the server application is free from error, trustworthy, secure against outside attackers, or provided by a reliable business. They simply allow you to validate its identity through a third party.

Communicating with SSL

After you've installed your certificate, you just need to ensure that client requests use a URL that starts with https: rather than http: to use SSL encryption. If you're using an XML Web service, you can modify the base Url property of the generated proxy class (inherited from the WebClientProtocol class in the System.Web.Services.Protocols namespace), as shown in Listing 13-19.

Listing 13-19 Enabling SSL on the client side
 Dim Proxy As New localhost.SSLServiceTest() Proxy.Url = "https://localhost/DistributedCode/SSLServiceTest.asmx" ' (You can now send an SSL-encrypted message). Proxy.Url = "http://localhost/DistributedCode/SSLServiceTest.asmx" ' (You can now send normal unencrypted requests). 

This technique is particularly useful when you work with a service that uses ticket-based authentication. In this case, you might want to use SSL only when calling the Login method. To perform the required URL manipulations without hard-coding the URL, you can use the System.Uri class:

 Dim Proxy As New localhost.SSLServiceTest() Dim WSUri As New Uri(Proxy.Url) ' Use SSL. ' WSUri.Host = "localhost" and ' WSUri.Path = "/DistributedCode/SSLServiceTest.asmx"  Proxy.Url = "https://" & WSUri.Host & WSUri.AbsolutePath ' Use ordinary HTTP. Proxy.Url = "http://" & WSUri.Host & WSUri.AbsoultePath 

In your XML Web service code, you can check whether a user is connecting over a secure connection using the HttpRequest.IsSecureConnection property, as shown in Listing 13-20.

Listing 13-20 Verifying SSL on the server side
 If Not Context.Request.IsSecureConnection Then     Throw New SecurityException( _       "This page must be requested through SSL.") Else     ' (Perform action.) End If 

In a .NET Remoting scenario, you just modify the URL in the client's configuration file so that it starts with https: rather than the http: prefix.

Keep in mind that when you use SSL, all traffic is encrypted, not just the data you're exchanging. For example, the text in an XML Web service request message that identifies the method to execute is encrypted, along with the body of the message, the envelope, and all SOAP headers. This is one reason why SSL has a reputation for being slow.



Microsoft. NET Distributed Applications(c) Integrating XML Web Services and. NET Remoting
MicrosoftВ® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting (Pro-Developer)
ISBN: 0735619336
EAN: 2147483647
Year: 2005
Pages: 174

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net