Commit 2c6c1067 authored by Hiro's avatar Hiro 🏄
Browse files

Merge branch 'master' of

parents daf7ec26 2eaf8ff0
image: debian:buster-slim
# This template should be usable on any system that's based on apt.
# taken from tor gitlabci
.apt-template: &apt-template |
export LC_ALL=C.UTF-8
echo Etc/UTC > /etc/timezone
mkdir -p apt-cache
export APT_CACHE_DIR="$(pwd)/apt-cache"
echo 'quiet "1";' \
'APT::Install-Recommends "0";' \
'APT::Install-Suggests "0";' \
'APT::Acquire::Retries "20";' \
'APT::Get::Assume-Yes "true";' \
'Dpkg::Use-Pty "0";' \
"Dir::Cache::Archives \"${APT_CACHE_DIR}\"; " \
>> /etc/apt/apt.conf.d/99gitlab
apt-get update -qq
apt-get upgrade -qy
TRANSLATION_BRANCH: "support-portal"
- build
- test_l10n
- packages
- lego
- apt-cache
- venv
- .cache/pip
- .cache/lektor/builds/
stage: build
- *apt-template
- DEBIAN_FRONTEND=noninteractive apt-get install gettext python3-babel python3-pip git python3-inifile python3-dev python3-setuptools python3-openssl python3-cryptography i18nspector apt-utils ca-certificates -y
- pip3 install virtualenv
- virtualenv venv
- source venv/bin/activate
- pip3 install lektor
- echo 'checking out translations'
- rm -rf i18n
- git clone --branch $TRANSLATION_BRANCH i18n
- echo 'reinstall lektor plugins'
- lektor project-info --output-path
- lektor plugins reinstall
- echo 'building lektor 3 more times to get translations in place'
- lektor build --output-path public && lektor build --output-path public && lektor build --output-path public
- public
- i18n
- when: always
- packages
- lego
- apt-cache
- venv
- .cache/pip
stage: test_l10n
needs: [pages]
allow_failure: true
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: '$CI_COMMIT_BRANCH == "translations"'
when: never
- changes:
- content/**/*.lr
- templates/**/*
- *apt-template
- DEBIAN_FRONTEND=noninteractive apt-get install gettext git python3-dev python3-setuptools i18nspector python3-polib python3-requests ca-certificates apt-utils -y
- git clone
- echo 'lets see if there are any updates in the strings for translation'
- public
- i18n
- l10n
allow_failure: true
- packages
- lego
- apt-cache
- venv
- i18n
- .cache/pip
stage: test_l10n
needs: [pages]
- translations
- DEBIAN_FRONTEND=noninteractive apt-get install gettext i18nspector python3-polib ca-certificates -y
- echo 'lets see if there are any broken links on the translations'
- l10n/bin/ i18n/
# Tor Project Support
This repository contains the code for the portal dedicated to answering FAQs and providing information necessary for safe and optimal usage of Tor.
[![pipeline status](](
The site is accessible at the following locations:
- http://rzuwtpc4wb3xdzrj3yeajsvm3fkq4vbeubm2tdxaqruzzzgs5dwemlad.onion/
......@@ -9,16 +11,16 @@ The site is accessible at the following locations:
## Reporting Bugs or Feedback
Bugs and feedback issues can be submitted on [GitLab](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/web/support/-/issues). To create a new issue, please [request a new account]( to access Tor Project's GitLab instance. The process for an account creation may require a couple of hours before another human approves it.
Bugs about this page and feedback can be submitted on [GitLab]( To create a new issue, please [request a new account]( to access Tor Project's GitLab instance. The process for an account creation may require a couple of hours before another human approves it.
## What is Lektor?
Lektor is the static site generator behind this website. Documentation can be found [here.](
## Contributing
- [Compile a local version of the site](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/web/tpo/wikis/Compiling-a-local-version-of-the-website) (clone the correct repository).
- [Developing on the site](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/web/tpo/wikis/How-to-develop-on-the-website)
- [How to write the content - edition tips and best practices for content creation](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/torproject/web/tpo/wikis/Writing-the-content)
- [Documentation on how to install, modify and use websites from the Tor project.](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/web/wiki)
- [Compile a local version of the site]( (clone the correct repository).
- [Developing on the site](
- [How to write the content - edition tips and best practices for content creation](
- [Documentation on how to install, modify and use websites from the Tor project.](
## Translations
title: What attacks remain against onion routing?
As mentioned above, it is possible for an observer who can view both you and either the destination website or your Tor exit node to correlate timings of your traffic as it enters the Tor network and also as it exits.
Tor does not defend against such a threat model.
In a more limited sense, note that if a censor or law enforcement agency has the ability to obtain specific observation of parts of the network, it is possible for them to verify a suspicion that you talk regularly to your friend by observing traffic at both ends and correlating the timing of only that traffic.
Again, this is only useful to verify that parties already suspected of communicating with one another are doing so.
In most countries, the suspicion required to obtain a warrant already carries more weight than timing correlation would provide.
Furthermore, since Tor reuses circuits for multiple TCP connections, it is possible to associate non anonymous and anonymous traffic at a given exit node, so be careful about what applications you run concurrently over Tor.
Perhaps even run separate Tor clients for these applications.
seo_slug: attacks-on-onion-routing
_slug: attacks-on-onion-routing
title: How often does Tor change its paths?
key: 10
Tor will reuse the same circuit for new TCP streams for 10 minutes, as long as the circuit is working fine.
(If the circuit fails, Tor will switch to a new circuit immediately.)
But note that a single TCP stream (e.g. a long IRC connection) will stay on the same circuit forever.
We don't rotate individual streams from one circuit to the next.
Otherwise, an adversary with a partial view of the network would be given many chances over time to link you to your destination, rather than just one chance.
seo_slug: change-paths
_slug: change-paths
title: What are Entry Guards?
key: 8
Tor (like all current practical low-latency anonymity designs) fails when the attacker can see both ends of the communications channel.
For example, suppose the attacker controls or watches the Tor relay you choose to enter the network, and also controls or watches the website you visit.
In this case, the research community knows no practical low-latency design that can reliably stop the attacker from correlating volume and timing information on the two sides.
So, what should we do?
Suppose the attacker controls, or can observe, C relays.
Suppose there are N relays total.
If you select new entry and exit relays each time you use the network, the attacker will be able to correlate all traffic you send with probability around (c/n)2.
But profiling is, for most users, as bad as being traced all the time: they want to do something often without an attacker noticing, and the attacker noticing once is as bad as the attacker noticing more often.
Thus, choosing many random entries and exits gives the user no chance of escaping profiling by this kind of attacker.
The solution is "entry guards": each Tor client selects a few relays at random to use as entry points, and uses only those relays for their first hop.
If those relays are not controlled or observed, the attacker can't win, ever, and the user is secure.
If those relays are observed or controlled by the attacker, the attacker sees a larger fraction of the user's traffic - but still the user is no more profiled than before.
Thus, the user has some chance (on the order of (n-c)/n) of avoiding profiling, whereas they had none before.
You can read more at [An Analysis of the Degradation of Anonymous Protocols](, [Defending Anonymous Communication Against Passive Logging Attacks](, and especially [Locating Hidden Servers](
Restricting your entry nodes may also help against attackers who want to run a few Tor nodes and easily enumerate all of the Tor user IP addresses.
(Even though they can't learn what destinations the users are talking to, they still might be able to do bad things with just a list of users.)
However, that feature won't really become useful until we move to a "directory guard" design as well.
seo_slug: entry-guards
_slug: entry-guards
title: Tell me about all the keys Tor uses
key: 9
Tor uses a variety of different keys, with three goals in mind: 1) encryption to ensure privacy of data within the Tor network, 2) authentication so clients know they're talking to the relays they meant to talk to, and 3) signatures to make sure all clients know the same set of relays.
**Encryption**: first, all connections in Tor use TLS link encryption, so observers can't look inside to see which circuit a given cell is intended for.
Further, the Tor client establishes an ephemeral encryption key with each relay in the circuit; these extra layers of encryption mean that only the exit relay can read the cells.
Both sides discard the circuit key when the circuit ends, so logging traffic and then breaking into the relay to discover the key won't work.
**Authentication**: Every Tor relay has a public decryption key called the "onion key".
Each relay rotates its onion key once a week.
When the Tor client establishes circuits, at each step it [demands that the Tor relay prove knowledge of its onion key](
That way the first node in the path can't just spoof the rest of the path.
Because the Tor client chooses the path, it can make sure to get Tor's "distributed trust" property: no single relay in the path can know about both the client and what the client is doing.
**Coordination**: How do clients know what the relays are, and how do they know that they have the right keys for them?
Each relay has a long-term public signing key called the "identity key".
Each directory authority additionally has a "directory signing key".
The directory authorities [provide a signed list]( of all the known relays, and in that list are a set of certificates from each relay (self-signed by their identity key) specifying their keys, locations, exit policies, and so on.
So unless the adversary can control a majority of the directory authorities (as of 2021 there are 10 directory authorities), they can't trick the Tor client into using other Tor relays.
How do clients know what the directory authorities are?
The Tor software comes with a built-in list of location and public key for each directory authority.
So the only way to trick users into using a fake Tor network is to give them a specially modified version of the software.
How do users know they've got the right software?
When we distribute the source code or a package, we digitally sign it with [GNU Privacy Guard]( See the [instructions on how to check Tor Browser's signature](
In order to be certain that it's really signed by us, you need to have met us in person and gotten a copy of our GPG key fingerprint, or you need to know somebody who has.
If you're concerned about an attack on this level, we recommend you get involved with the security community and start meeting people.
seo_slug: key-management
_slug: key-management
title: What protections does Tor provide?
Internet communication is based on a store-and-forward model that can be understood in analogy to postal mail: Data is transmitted in blocks called IP datagrams or packets.
Every packet includes a source IP address (of the sender) and a destination IP address (of the receiver), just as ordinary letters contain postal addresses of sender and receiver.
The way from sender to receiver involves multiple hops of routers, where each router inspects the destination IP address and forwards the packet closer to its destination.
Thus, every router between sender and receiver learns that the sender is communicating with the receiver.
In particular, your local ISP is in the position to build a complete profile of your Internet usage.
In addition, every server in the Internet that can see any of the packets can profile your behavior.
The aim of Tor is to improve your privacy by sending your traffic through a series of proxies.
Your communication is encrypted in multiple layers and routed via multiple hops through the Tor network to the final receiver.
More details on this process can be found in this [visualization](
Note that all your local ISP can observe now is that you are communicating with Tor nodes.
Similarly, servers in the Internet just see that they are being contacted by Tor nodes.
Generally speaking, Tor aims to solve three privacy problems:
First, Tor prevents websites and other services from learning your location, which they can use to build databases about your habits and interests.
With Tor, your Internet connections don't give you away by default -- now you can have the ability to choose, for each connection, how much information to reveal.
Second, Tor prevents people watching your traffic locally (such as your ISP or someone with access to your home wifi or router) from learning what information you're fetching and where you're fetching it from.
It also stops them from deciding what you're allowed to learn and publish -- if you can get to any part of the Tor network, you can reach any site on the Internet.
Third, Tor routes your connection through more than one Tor relay so no single relay can learn what you're up to.
Because these relays are run by different individuals or organizations, distributing trust provides more security than the old [one hop proxy]( approach.
Note, however, that there are situations where Tor fails to solve these privacy problems entirely: see the entry below on [remaining attacks](
seo_slug: protections
_slug: protections
......@@ -25,7 +25,7 @@ You need to decide whether banning the Tor network is worth losing the contribut
At this point, you should also ask yourself what you do about other services that aggregate many users behind a few IP addresses.
Tor is not so different from AOL in this respect.
Lastly, please remember that Tor relays have [individual exit policies](
Lastly, please remember that Tor relays have [individual exit policies](/relay-operators/exit-policies/).
Many Tor relays do not allow exiting connections at all.
Many of those that do allow some exit connections might already disallow connections to your service.
When you go about banning nodes, you should parse the exit policies and only block the ones that allow these connections; and you should keep in mind that exit policies can change (as well as the overall list of nodes in the network).
_model: redirect
target: /operators/exit-policies
target: /relay-operators/exit-policies
_discoverable: no
title: Exit policies should be able to block websites, not just IP addresses.
It would be nice to let relay operators say things like `reject` in their exit policies, rather than requiring them to learn all the IP address space that could be covered by the site (and then also blocking other sites at those IP addresses).
There are two problems, though.
First, users could still get around these blocks.
For example, they could request the IP address rather than the hostname when they exit from the Tor network.
This means operators would still need to learn all the IP addresses for the destinations in question.
The second problem is that it would allow remote attackers to censor arbitrary sites.
For example, if a Tor operator blocks, and then some attacker poisons the Tor relay's DNS or otherwise changes that hostname to resolve to the IP address for a major news site, then suddenly that Tor relay is blocking the news site.
seo_slug: block-websites
_slug: block-websites
_model: topic
title: Alternate Designs We Don't Do (Yet)
seo_slug: alternate-designs
key: 20
title: You should let the network pick the path, not the client.
No, you cannot trust the network to pick the path.
Malicious relays could route you through their colluding friends.
This would give an adversary the ability to watch all of your traffic end to end.
seo_slug: let-the-network-pick-the-path
_slug: let-the-network-pick-the-path
title: You should make every Tor user be a relay.
Requiring every Tor user to be a relay would help with scaling the network to handle all our users, and [running a Tor relay may help your anonymity](../../relay-operators/better-anonymity).
However, many Tor users cannot be good relays — for example, some Tor clients operate from behind restrictive firewalls, connect via modem, or otherwise aren't in a position where they can relay traffic.
Providing service to these clients is a critical part of providing effective anonymity for everyone, since many Tor users are subject to these or similar constraints and including these clients increases the size of the anonymity set.
That said, we do want to encourage Tor users to run relays, so what we really want to do is simplify the process of setting up and maintaining a relay.
We've made a lot of progress with easy configuration in the past few years: Tor is good at automatically detecting whether it's reachable and how much bandwidth it can offer.
There are four steps we need to address before we can do this though:
- First, we still need to get better at automatically estimating the right amount of bandwidth to allow.
It might be that [switching to UDP transport](../transport-all-ip-packets) is the simplest answer here — which alas is not a very simple answer at all.
- Second, we need to work on scalability, both of the network (how to stop requiring that all Tor relays be able to connect to all Tor relays) and of the directory (how to stop requiring that all Tor users know about all Tor relays).
Changes like this can have large impact on potential and actual anonymity.
See Section 5 of the [Challenges]( paper for details.
Again, UDP transport would help here.
- Third, we need to better understand the risks from letting the attacker send traffic through your relay while you're also initiating your own anonymized traffic.
[Three]( [different]( [research]( papers describe ways to identify the relays in a circuit by running traffic through candidate relays and looking for dips in the traffic while the circuit is active.
These clogging attacks are not that scary in the Tor context so long as relays are never clients too.
But if we're trying to encourage more clients to turn on relay functionality too (whether as [bridge relays](../../censorship/censorship-7) or as normal relays), then we need to understand this threat better and learn how to mitigate it.
- Fourth, we might need some sort of incentive scheme to encourage people to relay traffic for others, and/or to become exit nodes.
[Here are our current thoughts on Tor incentives](
Please help on all of these!
seo_slug: make-every-user-a-relay
title: You should transport all IP packets, not just TCP packets.
This would be handy for a number of reasons:
It would make Tor better able to handle new protocols like VoIP.
It could solve the whole need to socksify applications.
[Exit relays](../../glossary/exit) would also not need to allocate a lot of file descriptors for all the exit connections.
We're heading in this direction. Some of the hard problems are:
1. IP packets reveal OS characteristics.
We would still need to do IP-level packet normalization, to stop things like TCP fingerprinting attacks.
Given the diversity and complexity of TCP stacks, along with device fingerprinting attacks, it looks like our best bet is shipping our own user-space TCP stack.
2. Application-level streams still need scrubbing.
We will still need user-side applications like Torbutton.
So it won't become just a matter of capturing packets and anonymizing them at the IP layer.
3. Certain protocols will still leak information.
For example, we must rewrite DNS requests so they are delivered to an unlinkable DNS server rather than the DNS server at a user's ISP; thus, we must understand the protocols we are transporting.
4. DTLS (datagram TLS) basically has no users, and IPsec sure is big.
Once we've picked a transport mechanism, we need to design a new end-to-end Tor protocol for avoiding tagging attacks and other potential anonymity and integrity issues now that we allow drops, resends, et cetera.
5. Exit policies for arbitrary IP packets mean building a secure Intrusion Detection System (IDS).
Our node operators tell us that exit policies are one of the main reasons they're willing to run Tor.
Adding an IDS to handle exit policies would increase the security complexity of Tor, and would likely not work anyway, as evidenced by the entire field of IDS and counter-IDS papers.
Many potential abuse issues are resolved by the fact that Tor only transports valid TCP streams (as opposed to arbitrary IP including malformed packets and IP floods.)
Exit policies become even more important as we become able to transport IP packets.
We also need to compactly describe exit policies in the Tor directory, so clients can predict which nodes will allow their packets to exit.
Clients also need to predict all the packets they will want to send in a session before picking their exit node!
6. The Tor-internal name spaces would need to be redesigned.
We support onion service ".onion" addresses by intercepting the addresses when they are passed to the Tor client.
Doing so at the IP level will require a more complex interface between Tor and the local DNS resolver.
seo_slug: transport-all-ip-packets
......@@ -34,25 +34,25 @@ To enable all package managers using the libapt-pkg library to access metadata a
# apt install apt-transport-https
#### 2. Add the following entries to `/etc/apt/sources.list` or a new file in `/etc/apt/sources.list.d/`
#### 2. Create a new file in `/etc/apt/sources.list.d/` named `tor.list`. Add the following entries:
deb-src <DISTRIBUTION> main
deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] <DISTRIBUTION> main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] <DISTRIBUTION> main
If you want to try experimental packages, add these **in addition** to the lines from above (Note, use whatever is the current experimental version instead of 0.4.6.x from the example below):
deb tor-experimental-0.4.6.x-<DISTRIBUTION> main
deb-src tor-experimental-0.4.6.x-<DISTRIBUTION> main
deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] tor-experimental-0.4.6.x-<DISTRIBUTION> main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] tor-experimental-0.4.6.x-<DISTRIBUTION> main
Or nightly builds:
deb tor-nightly-master-<DISTRIBUTION> main
deb-src tor-nightly-master-<DISTRIBUTION> main
deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] tor-nightly-master-<DISTRIBUTION> main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] tor-nightly-master-<DISTRIBUTION> main
Replace `<DISTRIBUTION>` with your Operating System codename. Run `lsb_release -c` or `cat /etc/debian_version` to check the Operating System version.
......@@ -60,8 +60,8 @@ Replace `<DISTRIBUTION>` with your Operating System codename. Run `lsb_release -
**Note:** Ubuntu Focal dropped support for 32-bit, so instead use:
deb [arch=amd64] focal main
deb-src [arch=amd64] focal main
deb [arch=amd64 signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] focal main
deb-src [arch=amd64 signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] focal main
Warning symptom, when running sudo apt update:
......@@ -70,11 +70,10 @@ Warning symptom, when running sudo apt update:
Skipping acquire of configured file 'main/binary-i386/Packages' as repository ' focal InRelease' doesn't support architecture 'i386'
#### 3. Then add the gpg key used to sign the packages by running the following commands at your command prompt
#### 3. Then add the gpg key used to sign the packages by running the following command at your command prompt:
# wget -qO- | gpg --import
# gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
# wget -O- | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
#### 4. Install tor and tor debian keyring
......@@ -4,7 +4,7 @@ title: Our website is blocked by a censor. Can Tor Browser help users access our
seo_slug: our-website-is-blocked-by-a-censor
key: 1
key: 4
Tor Browser can certainly help people access your website in places where it is blocked.
_model: redirect
target: /gettor/gettor-1
key: 3
_discoverable: no
......@@ -4,7 +4,7 @@ title: I can’t connect to Tor Browser, is my network censored?
seo_slug: cannot-connect-to-tor-browser-network-censored
key: 4
key: 11
You might be on a network that is blocking the Tor network, and so you should try using bridges.
_model: question
title: How to circumvent the Great Firewall and connect to Tor from China?
seo_slug: connecting-from-china
key: 11
Users in China need to take a few steps to circumvent the [Great Firewall]( and connect to the Tor network.
First, get an updated version of Tor Browser: send an email to []( with the subject "windows zh-cn" or other operating system (linux or macos)
After installing Tor Browser, you will probably not be able to connect directly to the Tor network, because the Great Firewall is blocking Tor.
Therefore, the second step will be to obtain a bridge that works in China.
There are three options to unblock Tor in China:
1. **meek-azure:** it looks like you are browsing a Microsoft website instead of using Tor.
However, because it has a bandwidth limitation, this option will be quite slow.
You can select meek-azure from Tor Browser's built-in bridges dropdown.
1. **[Snowflake](/censorship/what-is-snowflake/):** uses ephemeral proxies to connect to the Tor network.
It's available in Tor Browser stable version (Desktop and Android).
You can select Snowflake from Tor Browser's [built-in bridge dropdown](/censorship/how-can-i-use-snowflake/).
1. **Private and unlisted obfs4 bridges:** users will need to request a private bridge to []( or, if they are tech-savvy, they can run their own [obfs4 bridge]( from outside China.
It's important to note that bridges distributed by BridgeDB ([HTTPS](, email), and built-in obfs4 bridges bundled in Tor Browser most likely won't work.
If one of these options below is not working, check your [Tor logs]( and try another option.
......@@ -4,7 +4,7 @@ title: How do I download Tor Browser if the is blocked?
seo_slug: how-to-download-tor-browser-if-torproject-org-is-blocked
key: 1
If you can't download Tor Browser through our [website](, you can get a copy of Tor Browser delivered to you via [GetTor](
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment