[or-cvs] r8882: checkpoint some blocking tweaks and edits (in tor/trunk: . doc/design-paper)
nickm at seul.org
nickm at seul.org
Tue Oct 31 19:17:19 UTC 2006
Author: nickm
Date: 2006-10-31 14:17:18 -0500 (Tue, 31 Oct 2006)
New Revision: 8882
Modified:
tor/trunk/
tor/trunk/doc/design-paper/blocking.tex
Log:
r9450 at Kushana: nickm | 2006-10-31 14:16:35 -0500
checkpoint some blocking tweaks and edits
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r9450] on c95137ef-5f19-0410-b913-86e773d04f59
Modified: tor/trunk/doc/design-paper/blocking.tex
===================================================================
--- tor/trunk/doc/design-paper/blocking.tex 2006-10-31 19:17:07 UTC (rev 8881)
+++ tor/trunk/doc/design-paper/blocking.tex 2006-10-31 19:17:18 UTC (rev 8882)
@@ -56,7 +56,7 @@
and law enforcement and government intelligence agencies who need to do
operations on the Internet without being noticed.
-Historically, research on anonymizing systems has assumed a passive
+Historically, research on anonymizing systems has focused on a passive
attacker who monitors the user (call her Alice) and tries to discover her
activities, yet lets her reach any piece of the network. In more modern
threat models such as Tor's, the adversary is allowed to perform active
@@ -65,22 +65,23 @@
to run a man-in-the-middle attack. But these systems still assume that
Alice can eventually reach the anonymizing network.
-An increasing number of users are making use of the Tor software
-not so much for its anonymity properties but for its censorship
-resistance properties -- if they access Internet sites like Wikipedia
-and Blogspot via Tor, they are no longer affected by local censorship
+An increasing number of users are using the Tor software
+less for its anonymity properties than for its censorship
+resistance properties---if they use Tor to access Internet sites like
+Wikipedia
+and Blogspot, they are no longer affected by local censorship
and firewall rules. In fact, an informal user study (described in
Appendix~\ref{app:geoip}) showed China as the third largest user base
for Tor clients, with perhaps ten thousand people accessing the Tor
network from China each day.
The current Tor design is easy to block if the attacker controls Alice's
-connection to the Tor network --- by blocking the directory authorities,
+connection to the Tor network---by blocking the directory authorities,
by blocking all the server IP addresses in the directory, or by filtering
based on the signature of the Tor TLS handshake. Here we describe a
design that builds upon the current Tor network to provide an anonymizing
network that also resists this blocking. Specifically,
-Section~\ref{sec:adversary} discusses our threat model --- that is,
+Section~\ref{sec:adversary} discusses our threat model---that is,
the assumptions we make about our adversary; Section~\ref{sec:current-tor}
describes the components of the current Tor design and how they can be
leveraged for a new blocking-resistant design; Section~\ref{sec:related}
@@ -98,70 +99,76 @@
in the critical path to a solution. Here we try to enumerate our best
understanding of the current situation around the world.
-In the traditional security style, we aim to describe a strong attacker
---- if we can defend against this attacker, we inherit protection
+In the traditional security style, we aim to describe a strong
+attacker---if we can defend against this attacker, we inherit protection
against weaker attackers as well. After all, we want a general design
-that will work for people in China, people in Iran, people in Thailand,
-whistleblowers in firewalled corporate networks, and people in whatever
-turns out to be the next oppressive situation. In fact, by designing with
+that will work for citizens of China, Iran, Thailand, and other censored
+countries; for
+whistleblowers in firewalled corporate network; and for people in
+unanticipated oppressive situations. In fact, by designing with
a variety of adversaries in mind, we can take advantage of the fact that
-adversaries will be in different stages of the arms race at each location.
+adversaries will be in different stages of the arms race at each location,
+and thereby retain partial utility in servers even when they are blocked
+by some of the adversaries.
We assume there are three main network attacks in use by censors
currently~\cite{clayton:pet2006}:
\begin{tightlist}
-\item Block destination by automatically searching for certain strings
-in TCP packets.
-\item Block destination by manually listing its IP address at the
+\item Block a destination or type of traffic by automatically searching for
+ certain strings or patterns in TCP packets.
+\item Block a destination by manually listing its IP address at the
firewall.
\item Intercept DNS requests and give bogus responses for certain
destination hostnames.
\end{tightlist}
-We assume the network firewall has very limited CPU per
+We assume the network firewall has limited CPU and memory per
connection~\cite{clayton:pet2006}. Against an adversary who spends
hours looking through the contents of each packet, we would need
some stronger mechanism such as steganography, which introduces its
own problems~\cite{active-wardens,tcpstego,bar}.
-More broadly, we assume that the chance that the authorities try to
-block a given system grows as its popularity grows. That is, a system
+More broadly, we assume that the authorities are more likely to
+block a given system as its popularity grows. That is, a system
used by only a few users will probably never be blocked, whereas a
well-publicized system with many users will receive much more scrutiny.
We assume that readers of blocked content are not in as much danger
as publishers. So far in places like China, the authorities mainly go
-after people who publish materials and coordinate organized movements
-against the state~\cite{mackinnon}. If they find that a user happens
+after people who publish materials and coordinate organized
+movements~\cite{mackinnon}.
+If they find that a user happens
to be reading a site that should be blocked, the typical response is
simply to block the site. Of course, even with an encrypted connection,
the adversary may be able to distinguish readers from publishers by
observing whether Alice is mostly downloading bytes or mostly uploading
-them --- we discuss this issue more in Section~\ref{subsec:upload-padding}.
+them---we discuss this issue more in Section~\ref{subsec:upload-padding}.
We assume that while various different regimes can coordinate and share
-notes, there will be a significant time lag between one attacker learning
+notes, there will be a time lag between one attacker learning
how to overcome a facet of our design and other attackers picking it up.
Similarly, we assume that in the early stages of deployment the insider
threat isn't as high of a risk, because no attackers have put serious
effort into breaking the system yet.
-We assume that government-level attackers are not always uniform across
+We do not assume that government-level attackers are always uniform across
the country. For example, there is no single centralized place in China
that coordinates its censorship decisions and steps.
We assume that our users have control over their hardware and
-software --- they don't have any spyware installed, there are no
+software---they don't have any spyware installed, there are no
cameras watching their screen, etc. Unfortunately, in many situations
-these threats are very real~\cite{zuckerman-threatmodels}; yet
+these threats are real~\cite{zuckerman-threatmodels}; yet
software-based security systems like ours are poorly equipped to handle
a user who is entirely observed and controlled by the adversary. See
Section~\ref{subsec:cafes-and-livecds} for more discussion of what little
we can do about this issue.
-We assume that widespread access to the Internet is economically and/or
-socially valuable in each deployment country. After all, if censorship
+We assume that widespread access to the Internet is economically,
+politically, and/or
+socially valuable to the policymakers of each deployment country. After
+all, if censorship
is more important than Internet access, the firewall administrators have
an easy job: they should simply block everything. The corollary to this
assumption is that we should design so that increased blocking of our
@@ -178,9 +185,13 @@
Tor is popular and sees a lot of use. It's the largest anonymity
network of its kind.
-Tor has attracted more than 800 routers from around the world.
-A few sentences about how Tor works.
-In this section, we examine some of the reasons why Tor has taken off,
+Tor has attracted more than 800 volunteer-operated routers from around the
+world. Tor protects users by routing their traffic through a multiply
+encrypted ``circuit'' built of a few randomly selected servers, each of which
+can remove only a single layer of encryption. Each server sees only the step
+before it and the step after it in the circuit, and so no single server can
+learn the connection between a user and her chosen communication partners.
+In this section, we examine some of the reasons why Tor has become popular,
with particular emphasis to how we can take advantage of these properties
for a blocking-resistance design.
@@ -196,39 +207,40 @@
For blocking-resistance, we care most clearly about the first
property. But as the arms race progresses, the second property
-will become important --- for example, to discourage an adversary
+will become important---for example, to discourage an adversary
from volunteering a relay in order to learn that Alice is reading
-or posting to certain websites. The third property is not so clearly
-important in this context, but we believe it will turn out to be helpful:
-consider websites and other Internet services that have been pressured
-recently into treating clients differently depending on their network
+or posting to certain websites. The third property helps keep users safe from
+collaborating websites: consider websites and other Internet services
+that have been pressured
+recently into revealing the identity of bloggers~\cite{arrested-bloggers}
+or treating clients differently depending on their network
location~\cite{google-geolocation}.
% and cite{goodell-syverson06} once it's finalized.
The Tor design provides other features as well over manual or ad
hoc circumvention techniques.
-Firstly, the Tor directory authorities automatically aggregate, test,
+First, the Tor directory authorities automatically aggregate, test,
and publish signed summaries of the available Tor routers. Tor clients
can fetch these summaries to learn which routers are available and
-which routers have desired properties. Directory information is cached
+which routers are suitable for their needs. Directory information is cached
throughout the Tor network, so once clients have bootstrapped they never
need to interact with the authorities directly. (To tolerate a minority
-of compromised directory authorities, we use a threshold trust scheme ---
+of compromised directory authorities, we use a threshold trust scheme---
see Section~\ref{subsec:trust-chain} for details.)
-Secondly, Tor clients can be configured to use any directory authorities
+Second, Tor clients can be configured to use any directory authorities
they want. They use the default authorities if no others are specified,
but it's easy to start a separate (or even overlapping) Tor network just
by running a different set of authorities and convincing users to prefer
a modified client. For example, we could launch a distinct Tor network
inside China; some users could even use an aggregate network made up of
-both the main network and the China network. But we should not be too
-quick to create other Tor networks --- part of Tor's anonymity comes from
+both the main network and the China network. (But we should not be too
+quick to create other Tor networks---part of Tor's anonymity comes from
users behaving like other users, and there are many unsolved anonymity
-questions if different users know about different pieces of the network.
+questions if different users know about different pieces of the network.)
-Thirdly, in addition to automatically learning from the chosen directories
+Third, in addition to automatically learning from the chosen directories
which Tor routers are available and working, Tor takes care of building
paths through the network and rebuilding them as needed. So the user
never has to know how paths are chosen, never has to manually pick
@@ -242,7 +254,7 @@
network), and uses Tor's flexible path-building to let users view Internet
resources from any point in the Blossom network.
-Fourthly, Tor separates the role of \emph{internal relay} from the
+Fourth, Tor separates the role of \emph{internal relay} from the
role of \emph{exit relay}. That is, some volunteers choose just to relay
traffic between Tor users and Tor routers, and others choose to also allow
connections to external Internet resources. Because we don't force all
@@ -252,13 +264,14 @@
the less likely it is that a given attacker will be watching both ends
of her circuit~\cite{tor-design}. As a bonus, because our design attracts
more internal relays that want to help out but don't want to deal with
-being an exit relay, we end up with more options for the first hop ---
-the one most critical to being able to reach the Tor network.
+being an exit relay, we end up with more options for the first hop---the
+one most critical to being able to reach the Tor network.
-Fifthly, Tor is sustainable. Zero-Knowledge Systems offered the commercial
-but now-defunct Freedom Network~\cite{freedom21-security}, a design with
+Fifth, Tor is sustainable. Zero-Knowledge Systems offered the commercial
+but now defunct Freedom Network~\cite{freedom21-security}, a design with
security comparable to Tor's, but its funding model relied on collecting
-money from users to pay relays. Modern commercial proxy systems similarly
+money from users to pay relay operators. Modern commercial proxy systems
+similarly
need to keep collecting money to support their infrastructure. On the
other hand, Tor has built a self-sustaining community of volunteers who
donate their time and resources. This community trust is rooted in Tor's
@@ -268,11 +281,11 @@
as described above, along with its open license, mean that its impact
will continue to grow.
-Sixthly, Tor has an established user base of hundreds of
+Sixth, Tor has an established user base of hundreds of
thousands of people from around the world. This diversity of
users contributes to sustainability as above: Tor is used by
ordinary citizens, activists, corporations, law enforcement, and
-even governments and militaries~\cite{tor-use-cases}, and they can
+even government and military users~\cite{tor-use-cases}, and they can
only achieve their security goals by blending together in the same
network~\cite{econymics,usability:weis2006}. This user base also provides
something else: hundreds of thousands of different and often-changing
@@ -289,14 +302,14 @@
Relay-based blocking-resistance schemes generally have two main
components: a relay component and a discovery component. The relay part
encompasses the process of establishing a connection, sending traffic
-back and forth, and so on --- everything that's done once the user knows
+back and forth, and so on---everything that's done once the user knows
where he's going to connect. Discovery is the step before that: the
process of finding one or more usable relays.
-For example, we described several pieces of Tor in the previous section,
-but we can divide them into the process of building paths and sending
+For example, we can divide the pieces of Tor in the previous section
+into the process of building paths and sending
traffic over them (relay) and the process of learning from the directory
-servers about what routers are available (discovery). With this distinction
+servers about what routers are available (discovery). With this distinction
in mind, we now examine several categories of relay-based schemes.
\subsection{Centrally-controlled shared proxies}
@@ -312,14 +325,15 @@
compared to systems that distribute trust over multiple relays, since a
compromised proxy can trivially observe all of its users' actions, and
an eavesdropper only needs to watch a single proxy to perform timing
-correlation attacks against all its users' traffic. Worse, all users
+correlation attacks against all its users' traffic and thus learn where
+everyone is connecting. Worse, all users
need to trust the proxy company to have good security itself as well as
to not reveal user activities.
On the other hand, single-hop proxies are easier to deploy, and they
can provide better performance than distributed-trust designs like Tor,
since traffic only goes through one relay. They're also more convenient
-from the user's perspective --- since users entirely trust the proxy,
+from the user's perspective---since users entirely trust the proxy,
they can just use their web browser directly.
Whether public proxy schemes are more or less scalable than Tor is
@@ -333,9 +347,9 @@
these websites get blocked (generally soon after the company becomes
popular), if the company cares about users in the blocked areas, they
start renting lots of disparate IP addresses and rotating through them
-as they get blocked. They notify their users of new addresses by email,
-for example. It's an arms race, since attackers can sign up to receive the
-email too, but they have one nice trick available to them: because they
+as they get blocked. They notify their users of new addresses (by email,
+for example). It's an arms race, since attackers can sign up to receive the
+email too, but operators have one nice trick available to them: because they
have a list of paying subscribers, they can notify certain subscribers
about updates earlier than others.
@@ -347,7 +361,7 @@
unsolved
topic, and we're stuck in this same arms race ourselves; we explore it
in more detail in Section~\ref{sec:discovery}. But first we examine the
-other end of the spectrum --- getting volunteers to run the proxies,
+other end of the spectrum---getting volunteers to run the proxies,
and telling only a few people about each proxy.
\subsection{Independent personal proxies}
@@ -365,11 +379,12 @@
from accessing Web sites. You, or a friend of yours, has to install the
Circumventor on some \emph{other} machine which is not censored.''
-This tactic has great advantages in terms of blocking-resistance ---
-recall our assumption in Section~\ref{sec:adversary} that the attention
+This tactic has great advantages in terms of blocking-resistance---recall
+our assumption in Section~\ref{sec:adversary} that the attention
a system attracts from the attacker is proportional to its number of
users and level of publicity. If each proxy only has a few users, and
-there is no central list of proxies, most of them will never get noticed.
+there is no central list of proxies, most of them will never get noticed by
+the censors.
On the other hand, there's a huge scalability question that so far has
prevented these schemes from being widely useful: how does the fellow
@@ -381,8 +396,8 @@
%discovery is also hard because the hosts keep vanishing if they're
%on dynamic ip. But not so bad, since they can use dyndns addresses.
-This challenge leads to a hybrid design --- centrally-distributed
-personal proxies --- which we will investigate in more detail in
+This challenge leads to a hybrid design---centrally-distributed
+personal proxies---which we will investigate in more detail in
Section~\ref{sec:discovery}.
\subsection{Open proxies}
@@ -449,13 +464,13 @@
public eye as a tool for retaining civil liberties in more free countries,
so perhaps blocking authorities don't view it as a threat. (We revisit
this idea when we consider whether and how to publicize a Tor variant
-that improves blocking-resistance --- see Section~\ref{subsec:publicity}
+that improves blocking-resistance---see Section~\ref{subsec:publicity}
for more discussion.)
-The broader explanation is that most government-level filters are not
-created by people setting out to block all possible ways to bypass
-them. They're created by people who want to do a good enough job that
-they can still appear in control. They realize that there will always
+The broader explanation is that the maintainance of most government-level
+filters is aimed at stopping widespread information flow and appearing to be
+in control, not by the impossible goal of blocking all possible ways to bypass
+censorship. Censors realize that there will always
be ways for a few people to get around the firewall, and as long as Tor
has not publically threatened their control, they see no urgent need to
block it yet.
@@ -481,6 +496,12 @@
\subsection{Bridge relays}
+Today, Tor servers operate on less than a thousand distinct IP; an adversary
+could enumerate and block them all with little trouble. To provide a
+means of ingress to the network, we need a larger set of entry points, most
+of which an adversary won't be able to enumerate easily. Fortunately, we
+have such a set: the Tor userbase.
+
Hundreds of thousands of people around the world use Tor. We can leverage
our already self-selected user base to produce a list of thousands of
often-changing IP addresses. Specifically, we can give them a little
@@ -530,7 +551,8 @@
Bridges use Tor to publish their descriptors privately and securely,
so even an attacker monitoring the bridge directory authority's network
can't make a list of all the addresses contacting the authority and
-track them that way.
+track them that way. Bridges may publish to only a subset of the
+authorities, to limit the potential impact of an authority compromise.
%\subsection{A simple matter of engineering}
%
@@ -554,7 +576,7 @@
%
%Lastly, since bridge authorities don't answer full network statuses,
%we need to add a new way for users to learn the current status for a
-%single relay or a small set of relays --- to answer such questions as
+%single relay or a small set of relays---to answer such questions as
%``is it running?'' or ``is it behaving correctly?'' We describe in
%Section~\ref{subsec:enclave-dirs} a way for the bridge authority to
%publish this information without resorting to signing each answer
@@ -610,7 +632,7 @@
HTTP request. A censor could create a network signature for the request
and/or its response, thus preventing these connections. To resolve this
vulnerability, we've modified the Tor protocol so that users can connect
-to the directory cache via the main Tor port --- they establish a TLS
+to the directory cache via the main Tor port---they establish a TLS
connection with the bridge as normal, and then send a special ``begindir''
relay command to establish an internal connection to its directory cache.
@@ -625,7 +647,8 @@
the best chance to reach them. Is this the best choice in all cases,
or should we encourage some fraction of them pick random ports, or other
ports commonly permitted through firewalls like 53 (DNS) or 110
-(POP)? We need
+(POP)? Or perhaps we should use a port where TLS traffic is expected, like
+443 (HTTPS), 993 (IMAPS), or 995 (POP3S). We need
more research on our potential users, and their current and anticipated
firewall restrictions.
@@ -633,23 +656,25 @@
Right now Tor uses some predictable strings in its TLS handshakes. For
example, it sets the X.509 organizationName field to ``Tor'', and it puts
the Tor server's nickname in the certificate's commonName field. We
-should tweak the handshake protocol so it doesn't rely on any details
-in the certificate headers, yet it remains secure. Should we replace
-it with blank entries for each field, or should we research the common
-values that Firefox and Internet Explorer use and try to imitate those?
+should tweak the handshake protocol so it doesn't rely on any unusual details
+in the certificate, yet it remains secure; the certificate itself
+should be made to resemble an ordinary HTTPS certificate. We should also try
+to make our advertised cipher-suites closer to what an ordinary web server
+would support.
-Worse, Tor's TLS handshake involves sending two certificates in each
-direction: one certificate contains the self-signed identity key for
-the router, and the second contains the current link key, signed by the
+Tor's TLS handshake uses two-certificate chains: one certificate
+contains the self-signed identity key for
+the router, and the second contains a current TLS key, signed by the
identity key. We use these to authenticate that we're talking to the right
-router, and also to establish perfect forward secrecy for that link.
-How much will these extra certificates make Tor's TLS handshake stand
-out? We have to work on normalizing our appearance not just in terms
-of the fields used in each certificate, but also in the number of
-certificates we present for each side.
-% Nick, I need help with the above paragraph. What are the two certs
-% for really, and how much work would it be to start acting like a normal
-% browser? -RD
+router, and to limit the impact of TLS-key exposure. Most (though far from
+all) consumer-oriented HTTPS services provide only a single certificate.
+These extra certificates may help identify Tor's TLS handshake; instead,
+bridges should consider using only a single TLS key certificate signed by
+their identity key, and providing the full value of the identity key in an
+early handshake cell. More significantly, Tor currently has all clients
+present certificates, so that clients are harder to distinguish from servers.
+But in a blocking-resistance environment, clients should not present
+certificates at all.
Lastly, what if the adversary starts observing the network traffic even
more closely? Even if our TLS handshake looks innocent, our traffic timing
@@ -672,7 +697,7 @@
local spoofing attacks? That is, since we never learned an identity
key fingerprint for the bridge, a local attacker could intercept our
connection and pretend to be the bridge we had in mind. It turns out
-that giving false information isn't that bad --- since the Tor client
+that giving false information isn't that bad---since the Tor client
ships with trusted keys for the bridge directory authority and the Tor
network directory authorities, the user can learn whether he's being
given a real connection to the bridge authorities or not. (After all,
@@ -681,8 +706,8 @@
What about anonymity-breaking attacks from observing traffic, if the
blocked user doesn't start out knowing the identity key of his intended
-bridge? The vulnerabilities aren't so bad in this case either ---
-the adversary could do similar attacks just by monitoring the network
+bridge? The vulnerabilities aren't so bad in this case either---the
+adversary could do similar attacks just by monitoring the network
traffic.
% cue paper by steven and george
@@ -710,7 +735,7 @@
In this section we describe four approaches to adding discovery
components for our design, in order of increasing complexity. Note that
-we can deploy all four schemes at once --- bridges and blocked users can
+we can deploy all four schemes at once---bridges and blocked users can
use the discovery approach that is most appropriate for their situation.
\subsection{Independent bridges, no central discovery}
@@ -763,7 +788,7 @@
\subsection{Social networks with directory-side support}
-Pick some seeds --- trusted people in the blocked area --- and give
+Pick some seeds---trusted people in the blocked area---and give
them each a few hundred bridge addresses. Run a website next to the
bridge authority, where they can log in (they only need persistent
pseudonyms). Give them tokens slowly over time. They can use these
@@ -803,9 +828,9 @@
Google cache or some open proxy servers, or they let file-sharing or
Skype or World-of-Warcraft connections through.
For users who can't use any of these techniques, hopefully they know
-a friend who can --- for example, perhaps the friend already knows some
+a friend who can---for example, perhaps the friend already knows some
bridge relay addresses.
-(If they can't get around it at all, then we can't help them --- they
+(If they can't get around it at all, then we can't help them---they
should go meet more people.)
Some techniques are sufficient to get us an IP address and a port,
@@ -879,9 +904,9 @@
\subsection{How to allocate bridge addresses to users}
Hold a fraction in reserve, in case our currently deployed tricks
-all fail at once --- so we can move to new approaches quickly.
+all fail at once---so we can move to new approaches quickly.
(Bridges that sign up and don't get used yet will be sad; but this
-is a transient problem --- if bridges are on by default, nobody will
+is a transient problem---if bridges are on by default, nobody will
mind not being used.)
Perhaps each bridge should be known by a single bridge directory
@@ -984,7 +1009,7 @@
\subsection{Possession of Tor in oppressed areas}
Many people speculate that installing and using a Tor client in areas with
-particularly extreme firewalls is a high risk --- and the risk increases
+particularly extreme firewalls is a high risk---and the risk increases
as the firewall gets more restrictive. This is probably true, but there's
a counter pressure as well: as the firewall gets more restrictive, more
ordinary people use Tor for more mainstream activities, such as learning
@@ -1021,7 +1046,7 @@
learn about some of them, and for some people just the fact that they're
running one might signal to an attacker that they place a high value
on their anonymity. Second, there are some more esoteric attacks on Tor
-relays that are not as well-understood or well-tested --- for example, an
+relays that are not as well-understood or well-tested---for example, an
attacker may be able to ``observe'' whether the bridge is sending traffic
even if he can't actually watch its network, by relaying traffic through
it and noticing changes in traffic timing~\cite{attack-tor-oak05}. On
@@ -1044,7 +1069,7 @@
a USB-based Tor image would be smart. There's Torpark, and hopefully
there will be more thoroughly analyzed options down the road. Worries
about hardware or
-software keyloggers and other spyware --- and physical surveillance.
+software keyloggers and other spyware---and physical surveillance.
If the system lets you boot from a CD or from a USB key, you can gain
a bit more security by bringing a privacy LiveCD with you. Hardware
@@ -1069,10 +1094,10 @@
its private key~\cite{tor-design}. This step prevents the first node
in the path from just spoofing the rest of the path. Secondly, the
Tor directory authorities provide a signed list of servers along with
-their public keys --- so unless the adversary can control a threshold
+their public keys---so unless the adversary can control a threshold
of directory authorities, he can't trick the Tor client into using other
Tor servers. Thirdly, the location and keys of the directory authorities,
-in turn, is hard-coded in the Tor source code --- so as long as the user
+in turn, is hard-coded in the Tor source code---so as long as the user
got a genuine version of Tor, he can know that he is using the genuine
Tor network. And lastly, the source code and other packages are signed
with the GPG keys of the Tor developers, so users can confirm that they
@@ -1091,8 +1116,8 @@
\subsection{Security through obscurity: publishing our design}
Many other schemes like dynaweb use the typical arms race strategy of
-not publishing their plans. Our goal here is to produce a design ---
-a framework --- that can be public and still secure. Where's the tradeoff?
+not publishing their plans. Our goal here is to produce a design---a
+framework---that can be public and still secure. Where's the tradeoff?
\section{Performance improvements}
\label{sec:performance}
@@ -1131,7 +1156,8 @@
``consumer'' networks and also from traditionally ``producer'' networks.
The second answer (not so good) would be to encourage more use of consumer
-networks for popular and useful websites.
+networks for popular and useful websites. (But P2P exists; minor websites
+exist; gaming exists; IM exists; ...)
Other attack: China pressures Verizon to discourage its users from
running bridges.
@@ -1141,7 +1167,7 @@
If it's trivial to verify that we're a bridge, and we run on a predictable
port, then it's conceivable our attacker would scan the whole Internet
looking for bridges. (In fact, he can just scan likely networks like
-cablemodem and DSL services --- see Section~\ref{block-cable} for a related
+cablemodem and DSL services---see Section~\ref{block-cable} for a related
attack.) It would be nice to slow down this attack. It would
be even nicer to make it hard to learn whether we're a bridge without
first knowing some secret.
@@ -1152,6 +1178,9 @@
bridge too, and wait to present the password until we've TLSed, else the
adversary can pretend to be the bridge and MITM him to learn the password.
+We could some kind of ID-based knocking protocol, or we could act like an
+unconfigured HTTPS server if treated like one.
+
\subsection{How to motivate people to run bridge relays}
One of the traditional ways to get people to run software that benefits
@@ -1161,7 +1190,7 @@
the fact that these users are already interested in protecting their
own Internet traffic, so they will install and run the software.
-Make all Tor users become bridges if they're reachable -- needs more work
+Make all Tor users become bridges if they're reachable---needs more work
on usability first, but we're making progress.
Also, we can make a snazzy network graph with Vidalia that emphasizes
@@ -1218,7 +1247,7 @@
operation, can we have some bridge relays inside the blocked area too,
and more established users can use them as relays so they don't need to
communicate over the firewall directly at all? A simple example here is
-to make new blocked users into internal bridges also -- so they sign up
+to make new blocked users into internal bridges also---so they sign up
on the BDA as part of doing their query, and we give out their addresses
rather than (or along with) the external bridge addresses. This design
is a lot trickier because it brings in the complexity of whether the
More information about the tor-commits
mailing list