Sensitive data transmitted over the Internet should always be encrypted to avoid potential intruders from eavesdropping on the communication anywhere along the route the data takes between the two machines. Wireless connections are particularly prone to this activity, as the eavesdropper does not even need to acquire a physical connection to the network being sniffed. Stories abound of would-be eavesdroppers driving around towns searching for unprotected wireless communications.
To protect against eavesdropping on Internet traffic being eavesdropped, the industry has developed several different encryption schemes. Examples include Secure-HTTP (S-
Digital Certificates
To allow two parties to communicate with each other via encrypted messages, at least one of the parties must have a digital certificate installed. (Typically, this certificate is referred to as a server certificate if installed on a Web server, or a personal certificate if installed in a browser.) The digital certificate contains a key that enables the sender to encrypt the data in a way that ensures that only the intended receiver is able to decipher the data and also proves to the recipient that it was really the alleged sender who actually sent the message. Certificates are transported from issuer to user by means of a certificate file. Typically, these files are themselves encrypted and protected by a user-selected (ideally strong) password. If an attacker is able to guess the password used to protect the certificate, he or she may be able to transfer the certificate to another machine (inside or outside of the owning organization). Then the attacker uses this second machine to try and trick another Internet user into thinking that he or she is communicating with the legitimate owner.
To reduce the threat of a certificate file being copied, thereby allowing an attacker to try and crack the password protecting the certificate at his or her leisure, the file should be removed from any easily accessible location that an attacker may be able to get to. For example, a floppy disk in a bank's safe deposit box makes for a much more secure home for the file than the hard drive of the Web server on which the certificate was installed. (Note that, once installed, the certificate file does not need to be stored on the machine that is using it.)
Encryption Strength
When using SSL to encrypt a Web page, the URL displayed by a browser is typically preceded by https (as opposed to http). Some browsers also use a visual cue to indicate whether the communication is encrypted or not (with broken keys and padlock icons). What the visual cue, or https prefix, does not indicate is the type of encryption being used for the communication. A number of different encryption algorithms exist (such as RC4, DES, and MAC), as do different encryption keys lengths (40, 56, 128, and 168 are currently the most common key-length implementations).
The ease with which a message can be deciphered using a brute-force attack (brute-force attacks are described in more detail in Chapter 4) is dependent upon the key size used to encrypt the message. (The larger the key, the longer it will take to break it.) So, a larger key size will make the data being transmitted more secure. Unfortunately, a larger-sized key will also make the encrypted data file larger, thereby utilizing additional network bandwidth, and it will place an additional strain on the CPU doing the encryption and deciphering. Therefore, a trade-off exists between improved security and improved performance. For marginally confidential information, such as a financial analyst's report that only paid subscribers are supposed to have access to, perhaps a weak and speedy encryption strategy would work best. On the other hand, super-sensitive data, such as a Swiss numbered bank account, ought to be encrypted using the strongest strategy available.
CERTIFICATE CLASSES
Certificates come in several different classes, the class reflecting the ease with which the certificate can be obtained from its issuer, and therefore the implied authenticity of its user. Class 1 certificates are typically easy to obtain; a valid credit card number may be all that is needed. Class 3 certificates typically require thorough background checks before they are released and therefore infer a higher level of trust that the person or organization purchasing the certificate is really the entity that they claim to be.
Whatever method of encryption an organization deems appropriate, the encryption method actually implemented by a Web site should be checked to ensure that it complies with the strength of encryption specified by the Web application's designers. One way to test this is to communicate with the target Web site using a browser that can be configured to work with different encryption settings, varying the settings to ensure that the data is not being under- or overencrypted. For instance, Opera 6.0 and Netscape 6.2 enable users to select which SSL encryption algorithms and key lengths may be utilized by the browser. In addition, some browsers provide the user with the opportunity to view the details of a downloaded certificate, such as its key length.
Mixing Encrypted and Nonencrypted Content
Because typically not every Web page on a Web site needs to be encrypted, most Web servers enable each page to be individually selected (or omitted) for encryption, thereby reducing the amount of data that actually needs to be encrypted. For instance, unlike the confirm trade page, it's unlikely that the help page on a stockbroker's Web site would need to be encrypted.
This concept can be taken to a more granular level, with individual Web page components being selectively encrypted or left unencrypted. For instance, typically most of the time spent downloading a Web page is in fact spent waiting for the images (as opposed to the text) on the Web page to be downloaded. Frequently, there is nothing confidential about these images and consequently little point in encrypting these network bandwidth-intense graphic files. (Once downloaded, the user could always save the unencrypted image to disk anyway.)
Mixing encrypted and unencrypted components on the same Web page has a drawback, as does, to a lesser extent, using encrypted and unencrypted Web pages on the same Web site. This is that some browsers will generate numerous (well-intentioned, but still annoying) messages, warning users that some of the components that make up the Web page are unencrypted, thereby creating a potential usability issue.
Just because a Web page has been downloaded in an encrypted format does not necessarily mean that the reply will be encrypted (or vice versa). For instance, a Web site's login page may be sent from the Web server to the browser unencrypted; there's no security risk in an eavesdropper viewing an empty login form. But the corresponding reply from the user, with the associated userID and password, should be encrypted. Unfortunately, this approach also has usability issues, as a user may incorrectly assume their reply (containing their userID and password) will not be encrypted and therefore be hesitant to use. That deduction would be made because the download empty login form had not been encrypted, causing the browser to display the unencrypted visual cue: an open padlock or broken key.
COOKIE ENCRYPTION
A Web site can use the HTTP Secure Cookie option to ensure that a cookie is only transmitted back to it if the cookie is first encrypted. This is a useful option if the Web site
Avoiding Encryption Bottlenecks
For many secure Web applications, encryption may be the first scalability bottleneck. Due to the heavy requirements of encryption, even a small number of simultaneous clients can saturate a Web server. To mitigate this problem, Web sites have adopted a number of different strategies, which are discussed in the following sections.