Using SSL to Safeguard Transmitted Data

Digital packets transmitted between Web browser and Web server by using Transmission Control Protocol/Internet Protocol (TCP/IP) are susceptible to unauthorized interception. In the case of anonymous access, such as in most Gopher or FTP service requests, this is not an issue. However, you usually secure your data transmission when you are conducting confidential business transactions that involve sensitive financial information or electronic correspondence.

There is no standard way to secure the FTP or Gopher service. You can use the Secure Sockets Layer protocol in Internet Information Server to transmit your encrypted information through the WWW service. This gain in security will cost processor performance, however.

The Secure Sockets Layer protocol provides data privacy, integrity, and authentication in a point-to-point connection between a Web browser and a Web server. Internet Information Server can send and receive private communication across the Internet with a browser that supports SSL. (SSL is based on a combination of public key and symmetric key cryptography, in addition to digital signature and certificate technology.)

Browser and server, although they have never before communicated with each other, can transmit encrypted data by using an agreed-upon method, a cryptographic key pair. By using digital signatures, each party can positively identify the other.

For international communications, you must limit your SSL key to 512 bits. The 1024-bit and 768-bit key options cannot be used internationally. For more information on SSL, see Chapter 3, "Server Security on the Internet," in the Windows NT Server Internet Guide, and the online Windows NT Server Microsoft Internet Information Server Installation and Administration Guide.

Both the browser and the server use an SSL security handshake to initiate a secure TCP/IP connection. The client and server agree on the level of security they will use and how to fulfill authentication requirements for their connection. After the handshake, the only role of SSL is to encrypt and decrypt the WWW service byte stream. The WWW service and the Web browser encrypt all the information in both request and response, including:

The URL the client is requesting.

Any submitted form contents, such as credit card numbers.

Any WWW service user names and passwords.

All data the server sends back to the client.

To maintain the performance level of your computer running Windows NT Server, consider using SSL only for highly sensitive information such as credit card transactions. Presently, SSL-encrypted transmissions are slower than unencrypted transmissions. As a consequence, Web server performance levels drop because of the encryption.

During the SSL session setup, browsers usually generate multiple threads reading from the server. This means that a client can initiate three or four session setups simultaneously that amount to nearly a quarter of a second of real processor time (3sessions x 85 milliseconds). During the SSL session setup, the initial private-key process takes approximately 85 milliseconds of real processor time for a 1024-bit key. Adding to this processor time are the interrupts for new packets and the input/output completion.

Once the server starts encrypting the stream back to the client, the overhead is 14 to 18 instructions per byte, depending on the architecture. Also, the maximum window size of an SSL encapsulated message is only 16K. The server cannot send larger, more efficient streams of data back to the client. Also, this SSL activity takes place in user mode, thus preventing the server from using TransmitFile or other fast APIs to send the data.

For more information on maximizing server performance, see Chapter 6, "Preventing Processor Bottlenecks," later in this book.