CompTIA A_ Certification All-In-One Exam Guide, Seventh Edition - Michael Meyers [471]
Application Encryption
When it comes to encryption, even TCP/IP applications can get into the swing of things. The most famous of all application encryptions is Netscape’s Secure Sockets Layer (SSL) security protocol, which is used to create secure Web sites. Microsoft incorporates SSL into its more far-reaching HTTPS (HTTP over SSL) protocol. These protocols make it possible to create the secure Web sites people use to make purchases over the Internet. You can identify HTTPS Web sites by the HTTPS:// included in the URL (see Figure 26-29).
Figure 26-29 A secure Web site
To make a secure connection, your Web browser and the Web server must encrypt their data. That means there must be a way for both the Web server and your browser to encrypt and decrypt each other’s data. To do this, the server sends a public key to your Web browser so the browser knows how to decrypt the incoming data. These public keys are sent in the form of a digital certificate. This certificate is signed by a trusted authority that guarantees that the public key you are about to get is actually from the Web server and not from some evil person pretending to be the Web server. A number of companies issue digital certificates to Web sites, the most famous being VeriSign, Inc. A digital signature is similar to a digital certificate, but lacks third party support.
Your Web browser has a built-in list of trusted authorities. If a certificate comes in from a Web site that uses one of these highly respected companies, you won’t see anything happen in your browser; you’ll just go to the secure Web page, where a small lock will appear in the lower-right corner of your browser. Figure 26-30 shows the list of trusted authorities built in to the Firefox Web browser.
Figure 26-30 Trusted authorities
However, if you receive a certificate from someone not listed in your browser, the browser will warn you and ask you if you wish to accept the certificate, as shown in Figure 26-31.
Figure 26-31 Incoming certificate
What you do here is up to you. Do you wish to trust this certificate? In most cases, you simply say yes, and this certificate is added to your SSL cache of certificates. However, an accepted certificate may become invalid, usually because of something boring; for instance, it may go out of date or the public key may change. This never happens with the “big name” certificates built in to your browser—you’ll see this more often when a certificate is used, for example, in-house on a company intranet and the administrator forgets to update the certificates. If a certificate goes bad, your browser issues a warning the next time you visit that site. To clear invalid certificates, you need to clear the SSL cache. The process varies in every browser, but in Internet Explorer, go to the Content tab under Internet Options and click the Clear SSL state button (Figure 26-32).
Figure 26-32 The Internet Options Content tab
Wireless Issues
Wireless networks add a whole level of additional security headaches for techs to face, as you know from Chapter 24, “Wireless Networking.” Some of the points to remember or to go back and look up are as follows:
Set up wireless encryption, at least WEP, but preferably WPA or the more secure WPA2 and configure clients to use them.
Disable DHCP and require your wireless clients to use a static IP address.
If you need to use DHCP, only allot enough DHCP addresses to meet the needs of your network to avoid unused wireless connections.
Change the WAP’s SSID from default and disable SSID broadcast.
Filter by MAC address to allow only known clients on the network.
Change the default user name and password. Every hacker has memorized the default user names and passwords.
Update the firmware as needed.
If available, make sure the WAP’s firewall settings are turned on.
Chapter Review
Questions
1. What