Why Serve Secure Content

Crackers who install packet sniffers on the server's network, the client's network, or an intervening router may be able to read the traffic sent between the web server and the web browser. Submitting sensitive information, such as credit card numbers, over such a link is therefore risky. Secure HTTP makes such sniffing pointless; the cracker sees only encrypted traffic, and therefore can't extract sensitive data from the exchange. In theory, a cracker could decrypt the traffic, but the CPU requirements of breaking the encryption schemes used are enormous—it would take years of CPU time to do the job, at least with today's CPUs and encryption algorithms.

In addition to securing the content of data transfers, secure HTTP provides an authentication benefit. The encryption protocols used enable one or both sides to authenticate the identity of the other side. In secure HTTP, this is most often used to enable the browser to verify the server's identity. Doing this provides some protection against a miscreant setting up a fake website, breaking into a DNS server, redirecting traffic intended for the legitimate site to the fake one, and stealing sensitive data. If this happens, the user's web browser displays a warning dialog box, such as the one shown in Figure 23.2, which is presented by Opera when an unknown certificate crosses its path. Assuming the user knows what this message means, the user is then alerted to the possibility of a hijacked website and won't blindly reveal sensitive information. Unfortunately, many users don 'funderstand what dialog boxes such as the one shown in Figure 23.2 mean, and they approve the transactions without further checks. Many browsers, including Opera, make accepting the suspicious certificate the default action—a dubious practice from a security point of view.

Figure 23.2: Secure HTTP provides authentication and warnings when a server's identity can't be verified.

Note Web browsers alert their users to unknown certificates using dialog boxes that vary substantially in form and style. Most don't present much of the information shown in Figure 23.2 unless you click a button to reveal details.

Figure 23.2: Secure HTTP provides authentication and warnings when a server's identity can't be verified.

Note Web browsers alert their users to unknown certificates using dialog boxes that vary substantially in form and style. Most don't present much of the information shown in Figure 23.2 unless you click a button to reveal details.

Secure websites are most commonly associated with financial transactions—web merchants and online banking are two very high-profile and common uses of these techniques. If you intend to set up such a site, do not rely on this chapter alone; there are many security issues you must consider. Hire somebody who's experienced with such configurations. This chapter's coverage of secure content is most useful for a webmaster who wants to use encryption on somewhat less sensitive data, probably on a private website. For instance, you might want to use secure HTTP to encrypt data delivered via a web server to employees, as a precaution against local sniffing; or possibly to encrypt somewhat sensitive data on a public website. You'll have to judge for yourself when the data become sensitive enough to require calling in an outside expert to help configure the system.

Note Part of the reason for bringing in a security expert is to help secure all of the systems around the web server—the databases it uses, other server programs running on the web server computer or other computers near it on the network, and so on.

Web servers normally respond to connection attempts on port 80. In order to avoid confusion, secure web servers normally respond to another port: 443. (The https:// header in a URI tells the web browser to connect to this port.) As described in the upcoming section, "Changing the Apache Configuration," you may need to tell Apache to listen to this port for secure connections. One server can listen to both the secure and normal HTTP ports, or you can run different server programs on the different ports. Using firewall rules, you can even redirect traffic so that one computer serves one port and another computer serves another port, with the same apparent outside IP address.

0 0

Post a comment