In all cases, employees and other network users must have a clear understanding of the enterprise’s expectations. If the organization wishes to enforce standards on internet behavior, then the organization must define and publish those standards in policy directives. It is difficult to enforce an unwritten policy. It also may be difficult to fire an employee for violating an unwritten policy.

Many enterprise networks try to limit web misuse by blocking access to web content. Here are three approaches:

1. Website whitelist. This lists all websites that employees may visit. It is often impractical to maintain an effective whitelist. It must grant access to every site that the employees might need to get their work done. It is hard to anticipate all sites people might need to visit. If the needed site isn’t on the list, a task is delayed while the list is updated.

2. Content control software or website blacklist. This lists all websites that employees should not visit. Such lists are often built into commercial products, and the vendor maintains the list. In some cases, the list classifies sites according to the type of content. The network administrators may then allow access to some types of sites and block access to other types.

3. Web traffic scanning. Whitelists and blacklists do not eliminate the risk of malware infections via drive-by downloads. Such attacks even infect legitimate sites on occasion. Web traffic scanners search for malware in the HTML and other files returned to browsers by web servers. However, this introduces a delay in web browsing if the scanning times are excessive.

   In practice, many enterprises and users rely on client-based antivirus software to resist drive-by downloading of malware.

Traffic blocking is rarely 100 percent effective. Users may employ several techniques to disguise their web traffic. These are often the same techniques that people use to ensure personal privacy on the internet (see Section 15.5). Most employers would be very unhappy with employees who used such techniques to violate the company’s acceptable-use policy.

We introduced the maxim Trust, but Verify (in Section 4.5). Instead of restricting user actions ahead of time with web blocking, we monitor their behavior. We use the results of monitoring to ensure that users comply with the web usage policy.

Some sites simply keep a log of URLs visited by users and examine the log for suspicious or inappropriate site names. This is not practical in larger organizations. Some sites use content control software: Instead of using it to block access, the software keeps a record of visits. The administrators then can create a report indicating the visits to different types of sites and, if necessary, narrow down visits to specific client computers and desktops.

After we produce a policy directive on web use, we must ensure that the user community understands it. That naturally leads to training. A newly enacted policy requires an initial announcement and explanation to the existing user community. New users learn of the policy during an introductory orientation.

We reinforce the policy training by providing reminders to the user community. An effective reminder indicates that the policy exists and that management pays attention to it. If the enterprises monitor user behavior, then it is worthwhile to remind users of such monitoring. It is particularly effective to provide evidence of such monitoring by reporting general statistics on web use. We improve compliance if people know their work is being monitored.

Most internet-connected networks allow their users to browse the web. The site’s gateways and firewalls are configured to allow such traffic to pass. Some protocols take advantage of this: Instead of using TCP to establish their own, separate connections, the protocols travel inside HTTP traffic. We call this HTTP tunneling.

Tunneling requires a special-purpose client and a matching server. The client opens an HTTP connection to the server and they exchange packets by embedding them inside the HTTP data (FIGURE 15.8).

Some applications have a plausible reason for tunneling. For example, some web applications that exchange XML data may embed the XML within an HTTP tunnel.

To make the tunnel work, client-side software embeds the tunneled data in an HTTP message and sends it to a tunneling server. The server extracts the tunneled data and processes it. To simple firewalls, the exchange looks like a conventional HTTP connection. In fact, the XML tunnel carries more sophisticated XML-formatted data.

Although XML tunnels may have a legitimate purpose, other applications use tunneling to circumvent firewall port filtering. For example, there are general-purpose tunneling applications that embed an entire IP packet inside the HTTP message. This allows the client to use any application protocol desired. If the local network’s firewall blocks applications on most ports except web traffic on port 80, then the general-purpose tunnel bypasses that restriction.

Several open-source and commercial packages provide general-purpose HTTP tunneling. The packages allow the user to exchange packets with any internet host using essentially any protocol. For example, the tunnel could allow a user to communicate via a special-purpose gaming protocol port, even if the local network’s firewall blocks that port.

All tunnels, including the general-purpose tunnel, require client software to embed and extract the tunneled data. The client must connect to a server that processes the tunneled data. General-purpose tunnels generally rely on a corresponding server on the public internet, outside the local network’s firewall. Some commercial packages charge a fee to use their tunneling servers.

Sophisticated firewalls and monitoring systems can detect and block some types of tunneling. If the administrators use a website whitelist or can identify tunnel servers, then they can block access to those servers. Some monitoring systems may be able to examine the HTTP traffic itself and recognize tunneling protocols.

Tunneling is a variation of techniques used to achieve higher degrees of privacy while browsing on the internet. Section 15.5.2 discusses these techniques further.

Some tunneling software uses SSL to encrypt the HTTP traffic. There is no way to detect tunneling encrypted inside such a connection.

If the name check shown in Figure 15.10 detects a mismatch, the browser displays a warning. FIGURE 15.11 shows the warning displayed by the Firefox browser.

In the figure, the URL contained the domain name “www.ccr.gov.” Under “Technical Details,” the warning notes that the certificate contained the name “www.bpn.gov” instead.

This warning does not always indicate a fraudulent site or even a fraudulent certificate. If the organization has reorganized its site or changed site domain names, then the mismatch may be accidental. Figure 15.11 is an example of such an error; the certificate was issued by the appropriate agency, but it contained the wrong domain name.

When the URL and certificate names don’t match, we can examine the certificate ourselves and decide its legitimacy. Browsers always provide a mechanism for examining the SSL certificate being used. If we click on “I Understand the Risks” on the Firefox notice, it takes us to another screen that allows display of the certificate. FIGURE 15.12 shows the certificate associated with this error.

We can decide to trust the certificate in Figure 15.12 based on its contents. The owner and domain name legitimately could apply to this site (the “ccr” site is for U.S. government contractors, and the Defense Logistics Agency might legitimately manage that site). The certificate display also indicates that it was signed by a recognized CA: Verisign. When judging a certificate’s legitimacy, we consider the following three questions:

1. Is the owning organization a legitimate entity that could reasonably be operating that website? For that matter, is it unlikely that the organization would host a bogus site?

2. Could the domain name in the certificate legitimately apply to the site selected by the URL? For example, there could be a partial match between the certificate’s domain name and the URL’s domain name, and yet the browser comparison still could fail. Some certificates allow different local subdomains, while others will only accept a specific subdomain like “www”—or the certificate could include a legitimate variant of the organization’s name.

3. Was the certificate issued by a legitimate CA?

If the answer to all three questions is “yes,” then the certificate should be trustworthy. The first question may be the hardest to answer without further research. Government agencies or well-known, reputable companies usually are trustworthy in such cases. However, there are so many small companies on the web that it’s hard to identify all of them reliably, much less assess their trustworthiness. Some well-known businesses use a third-party service company to provide sales and “shopping cart” features for their websites. Thus, we might end up using an unrecognized company to complete a sale involving a familiar brand name.

The second question is a variant of the first: It is easier to trust the site if the domain names are part of one another. However, a total mismatch doesn’t indicate a bogus site if the site’s owner is legitimate. The third question is addressed in the next section: the assessment of “untrusted” CAs.

In some cases, there is simply not enough information available to identify a legitimate site with 100 percent confidence. There will always be risks in business transactions, whether on the web, on the phone, or in person.

Every valid public-key certificate contains a digital signature. We validate the certificate by checking the signature, using the CA’s public key. When SSL was a new technology, it was easy to check certificates. There was only a single authority who issued certificates for SSL, and the authority’s public key was built into the browser software.

Today, there are hundreds of recognized, reputable CAs. Modern browsers maintain a built-in list of recognized CAs. The left-hand side of FIGURE 15.13 shows an example of such a list. The list includes a few representative authorities; a typical browser might contain 200 such entries.

The built-in list contains a public-key certificate for each recognized CA. Each certificate contains the name and public key for an authority. The certificate format provides a safe and convenient way to distribute the information.

Figure 15.13 shows how Firefox used its built-in list of authorities to verify the bpn.gov certificate shown in Figure 15.12. Firefox produced an alert (Figure 15.11) indicating that the certificate’s name (bpn.gov) did not match the URL name (ccr.gov). Firefox did, however, verify the authenticity of bpn.gov’s certificate.

If a CA is not in the browser’s built-in list, then the browser cannot verify the certificate’s digital signature and thus cannot tell if the certificate is legitimate. When this happens, the browser produces a security alert like the one in Figure 15.11. This time, however, the technical details explain that the browser does not trust the authority who issued the certificate.

This poses a difficult security problem with no simple answer. The certificate in fact may be legitimate, or it may be a bogus certificate produced by an attacker. There are two ways an attacker might exploit a bogus certificate in this case:

1. The bogus certificate might be part of a phishing attack: The bogus site may try to trick us into disclosing login information. SSL may protect the connection, but the information we type travels directly to the attacker’s system. (See Section 14.3.2.)

2. The bogus certificate might be part of a bucket brigade attack. (See Section 8.6.) Again, the attacker might intercept SSL-protected login information for the legitimate site.

On the other hand, both the site and certificate might be genuine. Not all legitimate sites use CAs that appear in the browsers’ built-in lists. The U.S. military, for example, may use its own CAs to sign certificates. Public-key certificates for those authorities aren’t generally distributed with commercial browsers. Users who regularly visit those sites eliminate the alert by installing the appropriate U.S. military certificate in their browser. This allows the browser to verify the military-issued certificates automatically.

There are two strategies for dealing with an untrusted certificate:

1. Risky but simple: Decide to trust the certificate, but treat the site with some suspicion. If the site proves legitimate over several interactions, perhaps it is trustworthy.

2. Safe but complicated: Locate an SSL-protected site that can download the missing certificate for the authority. Install the certificate into the browser. Unfortunately, it isn’t always simple to locate such sites and certificates.

Public-key certificates generally carry a range of effective dates; the certificate in Figure 15.12 was issued on 8/4/14 to expire on 8/5/15. Servers occasionally may use a certificate for a few weeks past its expiration date, and this is usually an administrative oversight. Even though the mistake suggests carelessness on the site’s part, it usually does not indicate a bogus site. Avoid certificates that are months or years out of date.

This error occurs if the CA actually has revoked a certificate. The authority only revokes a certificate following a request from the certificate’s owner. This occurs rarely and almost certainly indicates that the certificate is bogus.

This may arise if an attacker simply modifies the public-key certificate directly. For example, the attacker might leave the certificate alone, except to substitute one name for another or one public key for another. Any change to the certificate’s contents should invalidate the digital signature. This clearly indicates a bogus certificate.