Wireless Networking in the Developing World

Wireless Security

 In a traditional wired network, access control is very straightforward:  If a
person has physical access to a computer or network hub, they can use (or
abuse) the network resources.  While software mechanisms are an impor-
tant component of network security, limiting physical access to the network
devices is the ultimate access control mechanism.  Simply put, if all termi-
nals and network components are physically accessible only accessible to
trusted individuals, the  network can likely be trusted.
   The rules change significantly with wireless networks.  While the apparent
range of your access point may seem to be just a few hundred meters, a user
with a high gain antenna may be able to make use of the network from several
blocks away.  Should an unauthorized user be detected, is impossible to sim-
ply “trace the cable” back to the users location.  Without transmitting a single
packet, a sufficiently talented nefarious user can capture and log traffic on a wireless
network to disk. This data can later be used to launch a more sophisticated attack
against the network. Never assume that radio waves simply “stop” at the edge of
your property line, or inside your building. 
  It is usually unreasonable to completely trust all users of the network, even on
wired networks.  Disgruntled employees, uneducated network users, and sim-
ple mistakes on the part of honest users can cause significant harm to network
operations.  As the network architect, your goal is to facilitate private commu-
nication between legitimate users of the network.  While a certain amount of
access control and authentication is necessary in any network, you have failed
in your job if legitimate users find it difficult to use the network to communicate.
Theres an old saying that the only way to completely secure a computer is to
unplug it, lock it in a safe, destroy the key, and bury the whole thing in concrete.
While such a system might be completely “secure”, it is useless for
communication. 
 When you make security decisions for your network, remember that above all else, the network exists so that its users can communicate with each other.
Security considerations are important, but should not  get in the way of the networks' users.
A simple rule-of-thumb as to whether or not the network is getting in the way of its users is to look at how much time you or other staff spend on helping people get on the network. If regular users are repeatedly having problems simply gaining access to the network, even after they have been provided instruction and training on how to do so, it's possible that the access procedures are too cumbersome and a review of them is in order.

 

Physical security for wireless networks.

When installing a network, you are building an infrastructure that people de-
pend on. Security measures exist to ensure that the network is reliable.
Wireless networks have physical components, such as wires and
boxes, which are easily disturbed. In many installations, people will not un-
derstand the purpose of the installed equipment, or curiosity may lead them
to experiment. They may not realize the importance of a cable connected to
a port. Someone may unplug an Ethernet cable so that they can connect
their laptop for 5 minutes, or move a switch because it is in their way. A plug
might be removed from a power bar because someone needs that recepta-
cle. Assuring the physical security of an installation is paramount. Signs and
labels will only be useful to those who can read your language. Putting things
out of the way and limiting access is the best means to assure that accidents
and tinkering do not occur.
 In less developed economies, proper fasteners, ties, or boxes will not be as
easy to find. You should be able to find electrical supplies that will work just
as well. Custom enclosures are also easy to manufacture and should be
considered essential to any installation. It is often economical to pay a mason
to make holes and install conduit. Where this would be an expensive option
in the developed world, this type of labour intensive activity can be affordable
in less developed regions. PVC can be embedded in cement walls for passing
cable from room to room. This avoids the need to smash new holes every
time a cable needs to be passed. Plastic bags can be stuffed into the conduit
around the cables for insulation. Small equipment should be mounted on the wall and larger equipment  should be put in a closet or in a cabinet.

Switches

Switches, hubs or interior access points can be screwed directly onto a wall
with a wall plug. It is best to put this equipment as high as possible to reduce
the chance that someone will be able to touch the device or its cables without significant effort.

Cables

At the very least, cables should be hidden and fastened.  It is possible to find
plastic cable conduit that can be used in buildings. If you cannot find it, simple
cable attachments can be nailed into the wall to secure the cable. This will make
sure that the cable doesn't hang where it can be snagged, pinched or cut. When
fastening cable to the wall, it is important to not nail or screw into the cable itself.
The cable contains many tiny wires that the network data travels over. Nailing through the cable will damage it and make it useless for transmitting data. Take care also to not overly bend or twist the cable as this will damage it as well.

 It is preferable to bury cables, rather than to leave them hanging across a
yard. Hanging wires might be used for drying clothes, or be snagged by a
ladder, etc. To avoid vermin and insects, use plastic electrical conduit. The
marginal expense will be well worth the trouble. The conduit should be buried
about 30 cm deep, or below the frost level in cold climates. It is worth the
extra investment of buying larger conduit than is presently required, so that
future cables can be run through the same tubing. Consider labeling buried
cable with a "call before you dig" sign to avoid future accidental outages.

Power

It is best to have power bars locked in a cabinet. If that is not possible, mount
the power bar under a desk, or on the wall and use duct tape (or gaffer tape, a
strong adhesive tape) to secure the plug into the receptacle. On the UPS and
power bar, do not leave any empty receptacles. Tape them if necessary. Peo-
ple will have the tendency to use the easiest receptacle, so make these critical
ones difficult to use. If you do not, you might find a fan or light plugged into
your UPS; though it is nice to have light, it is nicer to keep your server running!

Water

Protect your equipment from water and moisture. In all cases make sure that
your equipment, including your UPS is at least 30 cm from the ground, to
avoid damage from flooding. Also try to have a roof over your equipment, so
that water and moisture will not fall onto it. In moist climates, it is important
that the equipment has proper ventilation to assure that moisture can be ex-
hausted. Small closets need to have ventilation, or moisture and heat can
degrade or destroy your gear.

Masts

Equipment installed on a mast is often safe from thieves. Nevertheless, to de-
ter thieves and to keep your equipment safe from winds, it is good to over-
engineer mounts. Painting equipment a dull white or grey color reflects the sun
and makes it look plain and uninteresting. Panel antennas are often preferred
because they are much more subtle and less interesting than dishes. Any in-
stallation on walls should be high enough to require a ladder to reach. Try
choosing well-lit but not prominent places to put equipment. Also avoid antennae
that resemble television antennae, as those are items that will attract interest by
thieves, where a wifi antenna will be useless to the average thief.

Threats to the network

One critical difference between Ethernet and wireless is that wireless networks
are built on a shared medium.  They more closely resemble the old network
hubs than modern switches, in that every computer connected to the network
can “see” the traffic of every other user.  To monitor all network traffic on an
access point, one can simply tune to the channel being used, put the network
card into monitor mode, and log every frame.  This data might be directly valu-
able to an eavesdropper (including data such as email, voice data, or online
chat logs).  It may also provide passwords and other sensitive data, making it
possible to compromise the network even further.  As well see later in this
chapter, this problem can be mitigated by the use of encryption.
 Another serious problem with wireless networks is that its users are relatively
anonymous.  While it is true that every wireless device includes a unique
MAC address that is supplied by the manufacturer, these addresses can of-
ten be changed with software.  Even when the MAC address is known, it can
be very difficult to judge where a wireless user is physically located.  Multi-
path effects, high-gain antennas, and widely varying radio transmitter charac-
teristics can make it impossible to determine if a wireless user is
sitting in the next room or is in an apartment building a mile away.

 While unlicensed spectrum provides a huge cost savings to the user, it has
the unfortunate side effect that denial of service (DoS) attacks are trivially
simple.  By simply turning on a high powered access point, cordless phone,
video transmitter, or other 2.4GHz device, a malicious person could cause
significant problems on the network.  Many network devices are vulnerable to
other forms of denial of service attacks as well, such as disassociation flood-
ing and ARP table overflows.

Here are several categories of individuals who may cause problems on a
wireless network:
Unintentional users.  Densely populated areas such as city centers and university commons can lead to a density of wireless access points. In these  populated areas, it is common for laptop users to accidentally associate to
the wrong network.  Most wireless clients will simply choose any available
wireless network, often the one with the strongest signal, when their preferred network is unavailable.  The user may then make use of this network as usual, completely
unaware that they may be transmitting sensitive data on someone elses network.
Malicious  people may even take advantage of this by setting up access points in stra-
tegic locations, to try to attract unwitting users and capture their data.

The first step in avoiding this problem is educating your users, and stress-
ing the importance of connecting only to known and trusted networks. 
Many wireless clients can be configured to only connect to trusted net-
works, or to ask permission before joining a new network.  As we will see
later in this chapter, users can safely connect to open public networks by
using strong encryption.
War drivers.  The “war driving” phenomenon draws its name from the
popular 1983 hacker film, “War Games”.  War drivers are interested in find-
ing the physical location of wireless networks.  They typically drive around
with a laptop, GPS, and omnidirectional antenna, logging the name and
location of any networks they find.  These logs are then combined with logs
from other war drivers, and are turned into graphical maps depicting the
wireless “footprint” of a particular city.
 The vast majority of war drivers likely pose no direct threat to networks, but
the data they collect might be of interest to a network cracker.  For example,
it might be obvious that an unprotected access point detected by a war driver
is located inside a sensitive building, such as a government or corporate of-
fice.  A malicious person could use this information to illegally access the
network there.  Arguably, such an AP should never have been set up in the
first place, but war driving makes the problem all the more urgent.  As we will
see later in this chapter, war drivers who use the popular program NetStum-
bler can be detected with programs such as Kismet.  For more information
about war driving, see sites such as http://www.wifimaps.com/,
http://www.nodedb.com/,  or http://www.netstumbler.com/ .
Rogue access points.  There are two general classes of rogue access
points:  those incorrectly installed by legitimate users, and those installed
by malicious people who intend to collect data or do harm to the network. 
In the simplest case, a legitimate network user may want better wireless
coverage in their office, or they might find security restrictions on the corpo-
rate wireless network too difficult to comply with.  By installing an inexpen-
sive consumer access point without permission, the user opens the entire
network up to potential attacks from the inside.  While it is possible to scan
for unauthorized access points on your wired network, setting a clear policy
that prohibits them is a very important first step. 
 The second class of rogue access point can be very difficult to deal with.  By
installing a high powered AP that uses the same ESSID as an existing net-
work, a malicious person can trick people into using their equipment, and log
or even manipulate all data that passes through it.  Again, if your users are
trained to use strong encryption, this problem is significantly reduced.
Eavesdroppers.  As mentioned earlier, eavesdropping is a very difficult
problem to deal with on wireless networks.  By using a passive monitoring
tool (such as Kismet), an eavesdropper can log all network data from a
great distance away, without ever making their presence known.  Poorly
encrypted data can simply be logged and cracked later, while unencrypted
data can be easily read in real time.

If you have difficulty convincing others of this problem, you might want to
demonstrate tools such as Driftnet (http://www.ex-parrot.com/~chris/driftnet/).
Driftnet watches a wireless network for graphical data, such as GIF and JPEG files. While other users are browsing the Internet, these tools simply display all graphics found in a
graphical collage. While you can tell a user that their email is
vulnerable without encryption, nothing drives the message home like show-
ing them the pictures they are looking at in their web browser.
Again, while it cannot be completely prevented, proper application of strong
encryption will discourage eavesdropping.

 This introduction is intended to give you an idea of the problems you are up
against when designing a wireless network.  Later in this chapter, we will look
at tools and techniques that will help you to mitigate these problems.
 
One issue we have not discussed yet is that of authentication. Authentication is simply a system or mechanism that requires users to prove that they are who they say they are when they log onto the network. Authentication is important and complex enough that we felt it deserved its own chapter in this book so we will only touch on it briefly here.

Privacy

Most users are blissfully unaware that their private email, chat conversations,
and even passwords are often sent “in the clear” over dozens of untrusted
networks before arriving at their ultimate destination on the Internet.  How-
ever mistaken they may be, users still typically have some expectation of
privacy when using computer networks.
Privacy can be achieved, even on untrusted networks such as public access
points and the Internet. The only proven effective method for protecting pri-
vacy is the use of strong end-to-end encryption.

Encryption techniques such as WEP and WPA attempt to address the privacy
issue at layer two, the data-link layer.  This does protect against eavesdrop-
pers listening in on the wireless connection, but this protection ends at the
access point.  If the wireless client uses insecure protocols (such as POP or
simple SMTP for receiving and sending email), then users beyond the AP
can still log the session and see the sensitive data.  As mentioned earlier,
WEP also suffers from the fact that it uses a shared private key.  This means
that legitimate wireless users can eavesdrop on each other, since they all
know the private key.
By using encryption to the remote end of the connection, users can neatly
sidestep the entire problem.  These techniques work well even on untrusted
public networks, where eavesdroppers are listening and possibly even ma-
nipulating data coming from the access point.
To ensure data privacy, good end-to-end encryption should provide the fol-
lowing features:
Verified authentication of the remote end.  The user should be able to
know without a doubt that the remote end is who it claims to be.  Without
authentication, a user could give sensitive data to anyone claiming to be
the legitimate service.
Strong encryption methods.  The encryption algorithm should stand up
to public scrutiny, and not be easily decrypted by a third party.  There is no
security in obscurity, and strong encryption is even stronger when the algo-
rithm is widely known and subject to peer review.  A good algorithm with a
suitably large and protected key can provide encryption that is unlikely to
be broken by any effort in our lifetimes using current technology. Beware of product vendors who assure you that their proprietary encryption using trade-secret algorithms are better than open, peer-reviewed ones.
Public key cryptography.  While not an absolute requirement for end-to-
end encryption, the use of public key cryptography instead of a shared key
can ensure that an individual's data remains private, even if the key of an-
other user of the service is compromised.  It also solves certain problems
with distributing keys to users over untrusted networks.
Data encapsulation.  A good end-to-end encryption mechanism protects
as much data as possible.  This can range from encrypting a single email
transaction to encapsulation of all IP traffic, including DNS lookups and
other supporting protocols.  Some encryption tools simply provide a secure
channel that other applications can use.  This allows users to run any pro-
gram they like and still have the protection of strong encryption, even if the
programs themselves dont support it.
Be aware that laws regarding the use of encryption vary widely from place to
place.  Some countries treat encryption as munitions, and may require a
permit, escrow of private keys, or even prohibit its use altogether.  Before
implementing any solution that involves encryption, be sure to verify that use
of this technology is permitted in your local area.
In the following sections, well take a look at some specific tools that can pro-
vide good protection for your users data.

------------------------------------------------ 

SSL

The most widely available end-to-end encryption technology is Secure
Sockets Layer,
known simply as SSL. Built into virtually all web browsers,
SSL uses public key cryptography and a trusted public key infrastructure
(PKI) to secure data communications on the web. Whenever you visit a web
URL that starts with https, you are using SSL.

The SSL implementation built into web browsers includes a collection of certificates from organizations called certificate authorities(CA). A CA authority validates the identity of network users and/or providers are who they say they are and issues a certificate saying so. Rather than doing this by a signed fancy document suitable for framing, this is done through the exchange of cryptographic keys. As an example, Someone wanting a certificate for their website submits a certificate request(CR) encoded("signed") with a cryptographic key created specifically for signing the certificate request. They submit this request to the CA, who then "signs" the request with their own key. These are encoded in the certificate along with the exact name of the website that the requester wants the certificate to be valid for. For example, WWW.AIPOTU.GOV, from a certificate perspective, is not the same as AIPOTUE.GOV. Each site would require its own certificate to present to a browser to do authenticated HTTPS transactions. If the owner of AIPOTUE.GOV domain only has their certificate issued for AIPOTUE.GOV and not also WWW.AIPOTUE.GOV, a user accessing the "WWW" address will see a warning for about an invalid certificate for that site. This can be confusing to some users and, over time, lead them to just expect SSL Certificate warnings from their browser as normal when the truth is completely the opposite case.

When you browse to a website that uses SSL, the browser and the server first exchange certificates. The browser then verifies that the hostname in the certificate provided by the server matches the DNS hostname that the browser knows the server by, that the certificate has not expired or been revoked and that it has been signed by a trusted certificate authority. The server optionally verifies the validity of the browser's certificate. If the certificates are approved, both sides then negotiate a master session key using the previously exchanged certificates to protect the session that is being established. That key is then used to encrypt all communications until the browser disconnects. This kind of data encapsulation is known as a tunnel.

<Figure 6.4>Eavesdroppers must break strong encryption to monitor traffic over an
encrypted tunnel. The conversation inside the tunnel is identical to any other unencrypted
conversation.

 

The user of certificates with a PKI not only protects communication from eavesdroppers but is also used to prevent the so-called man-in-the-middle(MITM) attack. In an MITM attack, a malicious user intercepts all communication between a client and a server. By presenting counterfeit certificates to both the client and the server, a malicious user could carry on two simultaneous encrypted sessions. Since this user knows the secret on both connections, it is trivial to observe and manipulate the data being passed between the client and the server.

<FIGURE 6.5>

Use of a good PKI can significantly reduce the chances of this kind of attack. In order to be successful, the malicious user would have to be in possession of a certificate signed by a trusted CA that it can present to the client to accept as authentic. This is only possible if they can trick the end-user into accepting it or if the CA is compromised.

Certificate Authorities bear a special burden to protect their systems and network from unauthorized access and malicious users. If a CA were to be compromised, the attacker who performed the compromise could conduct MITM attacks on any of the users trying to connect to systems with a certificate issued by that CA. They could also issue counterfeit certificates in response to legitimate certificate requests, ensuring their ability to intercept or interfere with encrypted communications between browser users and servers. While CA compromise was once held to be very unlikely to happen, there have been a number of incidents at the time of this writing proving this is no longer the case. Companies whose primary activity was in acting as a commercial CA have gone out of business as a result of having their systems compromised and counterfeit certificates issued under their name. In September 2011, the certificate authority DigiNotar was found to have been subverted by crackers, forcing all its certificates to be revoked and sending it into bankruptcy.

These compromises were not the result of sophisticated computer criminals employing exotic sophisticated attacks but simply lapses in the security of their overall infrastructure and security policies and procedures.

Finally, it is good to point out that SSL is not only used for web browsing. Insecure email protocols such as IMAP, POP, and SMTP can be secured by wrapping them in an SSL tunnel.
Most modern email clients support IMAPS and POPS (secure IMAP and POP) as well as SSL/TLS protected SMTP. If your email server does not provide SSL support, you can still secure it with SSL using a package like Stunnel (http://www.stunnel.org/). SSL can be used to effectively secure just about any service that runs over TCP.

SSH

Most people think of SSH as a secure replacement for telnet, just as scp
and sftp are the secure counterparts of rcp and ftp. SSH is much
more than encrypted remote shell. For example, it can also act as a general purpose encrypting tunnel, or even an encrypting web proxy. By first establishing an SSH connection to a trusted location near (or even on) a remote server, insecure protocols can be protected from eavesdropping and attack.

Like SSL, it uses strong public key cryptography to verify the remote server and encrypt data. Instead of a PKI, it uses a key fingerprint cache that is checked before a connection is permitted. It can use passwords and public keys for user authentication, and, through its support for the Pluggable Authentication Modules (PAM) system, can also support other methods of authentication.
 While this technique may be a bit advanced for many users, network architects
can use SSH to encrypt traffic across untrusted links, such as wireless
point-to-point links. Since the tools are freely available and run over standard
TCP, any educated user can implement SSH connections for themselves,
providing their own end-to-end encryption without administrator intervention.
OpenSSH (http://openssh.org/) is probably the most popular implementation
on Unix-like platforms. Free implementations such as Putty
(http://www.putty.nl/) and WinSCP (http://winscp.net/) are available for
Windows. OpenSSH will also run on Windows under the Cygwin package
(http://www.cygwin.com/). These examples will assume that you are using
a recent version of OpenSSH.

Figure 6.6: The SSH tunnel protects web traffic up to the SSH server itself.

To establish an encrypted tunnel from a port on the local machine to a port
on the remote side, use the -L switch. For example, suppose you want to
forward web proxy traffic over an encrypted link to the squid server at
squid.example.net. Forward port 3128 (the default proxy port) using this
command:
ssh -fN -g -L3128:squid.example.net:3128 squid.example.net

The -fN switches instruct ssh to fork into the background after connecting.
The -g switch allows other users on your local segment to connect to the local
machine and use it for encryption over the untrusted link. OpenSSH will
use a public key for authentication if you have set one up, or it will prompt
you for your password on the remote side. You can then configure your web
browser to connect to localhost port 3128 as its web proxy service. All web
traffic will then be encrypted before transmission to the remote side.
SSH can also act as a dynamic SOCKS4 or SOCKS5 proxy. This allows you
to create an encrypting web proxy, without the need to set up squid. Note
that this is not a caching proxy; it simply encrypts all traffic.
ssh -fN -D 8080 remote.example.net
Configure your web browser to use SOCKS4 or SOCKS5 on local port 8080,
and away you go.
SSH can encrypt data on any TCP port, including ports used for email. It can
even compress the data along the way, which can decrease latency on low
capacity links.
ssh -fNCg -L110:localhost:110 -L25:localhost:25 mailhost.example.net
The -C switch turns on compression. You can add as many port forwarding
rules as you like by specifying the -L switch multiple times. Note that in order
to bind to a local port less than 1024, you must have root privileges on the
local machine.
These are just a few examples of the flexibility of SSH. By implementing
public keys and using the ssh forwarding agent, you can automate the creation
of encrypted tunnels throughout your wireless network, and protect your
communications with strong encryption and authentication.

OpenVPN

OpenVPN is a VPN implementation built on SSL encryption with both a commercially-licensed and an Open Source "community" edition. There are OpenVPN client implementations for a wide range of operating systems including Linux, Window 2000/XP and higher, OpenBSD, FreeBSD, NetBSD, and Mac OS X. Many users find it easier to understand and configure than IPSEC VPNs.
OpenVPN also has some disadvantages, such as fairly high latency of traffic over the VPN tunnel. Some amount of latency is unavoidable since all encryption/decryption is done in
user space, but using relatively new computers on either end of the tunnel
can minimize this. While it can use traditional shared keys for authentication, OpenVPN really shines when used with SSL certificates and a certificate authority.

OpenVPN has many advantages that make it a good option for providing end-to-end security.

Some of these reasons include:

  • It is based on proven, robust, encryption protocols(SSL and RSA)
  •  It is relatively easy to configure
  •  It functions across many different platforms
  •  It is well-documented
  •  An Open-Source "Community" version is maintained in addition to a for-pay commercial version.
OpenVPN needs to connect to a single TCP or UDP port on the remote side.
Once established, it can encapsulate all data down to the Networking layer,
or even down to the Data-Link layer, if your solution requires it. You can use it
to create robust VPN connections between individual machines, or simply
use it to connect network routers over untrusted wireless networks.
VPN technology is a complex field, and is a bit beyond the scope of this
section to go into more detail. It is important to understand how VPNs fit
into the structure of your network in order to provide the best possible protection
without opening up your organization to unintentional problems.
There are many good online resources that deal with installing OpenVPN
on a server and client, we recommend this article from Linux Journal:
http://www.linuxjournal.com/article/7949 as well as the official HOWTO:
http://openvpn.net/howto.html

Tor & Anonymizers

The Internet is basically an open network based on trust. When you connect
to a web server across the Internet, your traffic passes through many different
routers, owned by a great variety of institutions, corporations and individuals.
In principle, any one of these routers has the ability to look closely at
your data, seeing the source and destination addresses, and quite often also
the actual content of the data. Even if your data is encrypted using a secure
protocol, it is possible for your Internet provider to monitor the amount of data
transferred, as well as the source and destination of that data. Often this is
enough to piece together a fairly complete picture of your activities on-line.
Privacy and anonymity are important, and closely linked to each other. There
are many valid reasons to consider protecting your privacy by anonymizing
your network traffic. Suppose you want to offer Internet connectivity to your
local community by setting up a number of access points for people to connect
to. Whether you charge them for their access or not, there is always the risk that people use the network for something that is not legal in your country
or region. You could plead with the legal system that this particular illegal
action was not performed by yourself, but could have been performed by
anyone connecting to your network. The problem is neatly sidestepped if it
were technically infeasible to determine where your traffic was actually
headed. And what about on-line censorship? Publishing web pages anonymously
may also be necessary to avoid government censorship.
There are tools that allow you to anonymize your traffic in relatively easy
ways. The combination of Tor (http://www.torproject.org/) and Privoxy
(http://www.privoxy.org/) is a powerful way to run a local proxy server that
will pass your Internet traffic through a number of servers all across the net,
making it very difficult to follow the trail of information. Tor can be run on a
local PC, under Microsoft Windows, Mac OSX, Linux and a variety of BSD's,
where it anonymizes traffic from the browser on that particular machine. Tor
and Privoxy can also be installed on a gateway server, or even a small embedded
access point (such as a Linksys WRT54G) where they provides anonymity
to all network users automatically.
Tor works by repeatedly bouncing your TCP connections across a number of
servers spread throughout the Internet, and by wrapping routing information
in a number of encrypted layers (hence the term onion routing), that get
peeled off as the packet moves across the network. This means that, at any
given point in the network, the source and destination addresses cannot be
linked together. This makes traffic analysis extremely difficult.
The need for the Privoxy privacy proxy in connection with Tor is due to the
fact that name server queries (DNS queries) in most cases are not passed
through the proxy server, and someone analyzing your traffic would easily be
able to see that you were trying to reach a specific site (say google.com) by
the fact that you sent a DNS query to translate google.com to the appropriate
IP address. Privoxy connects to Tor as a SOCKS4a proxy, which uses hostnames
(not IP addresses) to get your packets to the intended destination.
In other words, using Privoxy with Tor is a simple and effective way to prevent
traffic analysis from linking your IP address with the services you use
online. Combined with secure, encrypted protocols (such as those we have
seen in this chapter), Tor and Privoxy provide a high level of anonymity on
the Internet.

There has been error in communication with booki server. Not sure right now where is the problem.

You should refresh this page.