Secure Web Communications

Internet communications that are based on the Transfer Control Protocol/Internet Protocol (TCP/IP), such as the Hypertext Transfer Protocol (HTTP), Telnet, and File Transfer Protocol (FTP), are not secure because all communication occurs in plaintext. Confidential or sensitive information that is transmitted with these protocols can easily be intercepted and read unless the information is protected by encryption technology.

In addition, because any Web client can send HTTP requests to a Web server and exploit weaknesses in the HTTP protocol or its implementation, Web servers that use only standard HTTP to communicate with Web clients are easy targets for denial-of-service attacks and other types of attacks. Moreover, Web clients that communicate by using standard HTTP are easy targets for unauthorized Web servers, which can impersonate legitimate Web sites and which might contain either virus-laden software for download by users or malicious scripts and programs.

In Windows 2000, you can deploy Internet Information Services to provide secure Web communication channels to ensure the integrity and confidentiality of Web communications in your organization. For more information about Internet Information Services, see Internet Information Services Help and the Microsoft ® Windows ®  2000 Server Resource Kit Internet Information Services Resource Guide .

Protocols for Secure Web Communication

Secure Web communication protocols provide a way to authenticate clients and servers on the Web and to protect the confidentiality of communication between clients and servers. A variety of secure communication standards that use public key technology have been developed, including Secure Hypertext Transfer Protocol (SHTTP), IP Security (IPSec), PPTP, and L2TP. The leading general-purpose, secure Web communication protocols are SSL 3.0 and the open TLS protocol that is based on SSL. The SSL and TLS protocols are widely used to provide secure channels for confidential TCP/IP communication on the Web.

One disadvantage of SSL and TLS, however, is that the strength of the cryptography that is used for secure channels is subject to government export and import restrictions. For example, the strength of symmetric key encryption that is used by technology that is nonexportable is much higher (128 bits) than the strength of the symmetric key cryptography that is used by technology that is exportable (40 bits or 56 bits). Both servers and clients must use the same cryptographic strength and the same cryptography algorithms when they communicate over a secure channel. At the beginning of SSL and TLS sessions, the server chooses the strongest cryptography that is available to both the server and the client. Maximum security for secure SSL and TLS communication is available only between servers and clients that can both support the higher-strength nonexportable cryptography.

For secure Web communication with banks and other financial institutions, other specialized protocols that use strong cryptography have been developed (as allowed by import or export restrictions on cryptography). Qualifying institutions can use these special protocols to provide strong cryptography for Web transactions, and at the same time circumvent the import and export restrictions that apply for SSL and TLS. Two of the leading secure Web communication protocols of this type are the secure electronic transaction (SET) protocol and the SGC protocol. Internet Information Services supports SGC; Microsoft® Wallet (which is available for the Microsoft® Internet Explorer 5 Internet browser) supports SET.

The SGC protocol is an extension of SSL, which requires a special SGC certificate to enable strong, 128-bit secure communication for the Web server. Internet Explorer and many other Web clients support SGC for both exportable and nonexportable versions of Web clients. Web clients do not need certificates for SGC communication. However, to use SGC communication with a Web server, you must obtain an SGC server certificate from an authorized, commercial CA. The commercial CA that issues your SGC certificate verifies that you are qualified to use SGC. Currently, many financial institutions and institutions in other specific industries can qualify for SGC certificates. For more information about SGC and qualifying institutions, see the Microsoft Security Advisor link on the Web Resources page at .

Benefits of Secure Web Communication

SSL and TLS can provide the following protection for Web communication:

  • Server authentication that is based on the server's authentication certificate. Clients can identify the server by its certificate and can choose to communicate with authenticated servers. Clients can detect whether an unauthorized entity is trying to impersonate a legitimate Web server.

  • Optional, mutual authentication between servers and clients that is based on both clients and servers having trusted certificates. Both servers and clients can choose to trust only those certificates that are issued by a specific CA.

  • Confidential Web communications that use an encrypted, secure channel. The server and the client negotiate the cryptographic algorithms that are to be used. They also negotiate the secret, shared session key that is used for secure communication. By default, secure Web communication uses the longest secret session key that is supported by both the server and the client. You can configure Internet Information Services to require strong (128-bit) session keys, or you can allow secure communication with shorter keys that are supported by exportable Web clients.

  • Data integrity that is based on Hash Message Authentication Codes (HMACs). An intruder cannot tamper with the data because the transmitted information is accompanied by message digests that must be verified before the information is accepted by the receiving client or server.

Internet Information Services and Web Communication

Windows 2000 Server includes Internet Information Services, which you can use to deploy Web sites on your intranets, extranets, or the Internet. You can use the Internet Information Services console in Microsoft Management Console (MMC) to configure and manage your Web sites, including configuring them for SSL and TLS Web communication. You can use the Internet Information Services console in Microsoft Management Console (MMC) to configure

For secure Web communication in which the client authenticates the server, only the server must have a valid authentication certificate. For optional secure Web communication that requires authentication of both the server and the client, the Web server and the Web client both must have valid certificates. If either of them does not have a valid authentication certificate, the secure channel is not completed.

You can use Certificate Services to issue client and server authentication certificates that work with both Internet Information Services and Internet Explorer, as well as with many other Web server and Web client products. You can also use other certificate services to provide certificates for secure Web communication.

For secure Web communication on an intranet or on extranets, you can often reduce the costs of certificate services by deploying your own CAs. You control the certificates that are trusted for authentication. However, for secure Web communication on the Internet, clients are usually more likely to trust a server certificate that has been issued by a commercial CA than a server certificate that has been issued by your organization. Furthermore, it is generally very costly to manage your own certificate services for secure Web client authentication certificates for public users on the Internet. Therefore, for Internet communication, consider obtaining Web server authentication certificates from commercial CAs. For Internet Web clients, consider trusting client authentication certificates from leading commercial CAs.

When you configure Internet Information Services to require client authentication certificates, the only Web clients that can communicate with the Web site are those whose authentication certificates are valid and contain a certification path with a root CA that has its certificate in the Trusted Root Certification Authorities store. But you can create certificate trust lists (CTLs) to specify other CAs that are trusted for each Web site. Because root CAs with certificates in the Trusted Root Certification Authorities store are trusted for a wide range of security functions , consider using CTLs whenever you want to trust a root CA from outside your organization. For example, you might create CTLs to trust client authentication certificates that are issued by business partners or by a commercial CA.

Secure Web Communication Options

By default, secure Web communication for Internet Information Services requires authentication of the server to clients, but clients are not required to have a certificate for authentication to the server. You have the option of configuring Internet Information Services to prevent clients from communicating with Web sites if they do not have valid and trusted authentication certificates, which reduces the risk of denial-of-service attacks. You can require secure channels for all Web communication to protect confidential information, or you can use secure channels to transmit only selected information, such as personal information and credit card numbers.

The users of your Web sites on the Internet are usually customers that use a mixture of Web browsers, including Web browsers that support strong cryptography and Web clients that do not support strong cryptography. With Internet Information Services, the default configuration for SSL and TLS communication enables secure channels to default to the lowest strength of cryptography that is supported by each user's Web browser.

You have the option of configuring Web sites to require the maximum 128-bit cryptographic strength for SSL and TLS clients so that Web clients that support only the weaker cryptography cannot communicate with the Web site. For example, you might configure Internet Information Services to require strong encryption on your intranet or extranets. Of course, you must also deploy Web clients and Web servers in your organization to support the stronger cryptography requirements.

If you meet the SGC qualification requirements, you also might be able to use SGC on the Internet to provide strong 128-bit encrypted communication with clients that support SGC. To use SGC with Internet Information Services, you must obtain an SGC server certificate from a commercial CA. Or you can configure Internet Information Services to use SSL, TLS, and SGC. If the Web client supports SGC, SGC is used; otherwise SSL or TLS is used.

Secure channels require that information be both encrypted and decrypted on both the server and the client. Most of the client computers in use today can handle the encryption and decryption load of secure channels easily. However, multiple, concurrent secure channels can place a large load on a Web server. To improve the performance of secure-channel Web servers, you can use very fast multiple processor computers and crypto-accelerator boards. You can also design Web sites to use secure channel sessions for only a portion of the content on the Web site. For example, you can design Web pages to require secure channels only for forms that are used to submit confidential information, such as credit card numbers or payroll information.