Choosing Security Solutions That Use Public Key Technology
Choosing Security Solutions That Use Public Key Technology |
|
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.
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,
SSL and TLS can provide the following protection for 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.
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
If you meet the SGC qualification requirements, you also might be able to use SGC on the Internet to provide strong
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.