| Commit message (Collapse) | Author | Age |
|\ |
|
| |
| |
| |
| | |
Add changes file
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://trac.torproject.org/projects/tor/ticket/1859
Use router_get_by_digest() instead of router_get_by_hexdigest()
in circuit_discard_optional_exit_enclaves() and
rend_client_get_random_intro(), per Nick's comments.
Using router_get_by_digest() in rend_client_get_random_intro() will
break hidden services published by Tor versions pre 0.1.2.18 and
0.2.07-alpha as they only publish by nickname. This is acceptable
however as these versions only publish to authority tor26 and
don't work for versions in the 0.2.2.x series anyway.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://trac.torproject.org/projects/tor/ticket/1859
There are two problems in this bug:
1. When an OP makes a .exit request specifying itself as the exit, and the exit
is not yet listed, Tor gets all the routerinfos needed for the circuit but
discovers in circuit_is_acceptable() that its own routerinfo is not in the
routerdigest list and cannot be used. Tor then gets locked in a cycle of
repeating these two steps. When gathering the routerinfos for a circuit,
specifically when the exit has been chosen by .exit notation, Tor needs to
apply the same rules it uses later on when deciding if it can build a
circuit with those routerinfos.
2. A different bug arises in the above situation when the Tor instance's
routerinfo *is* listed in the routerlist, it shares its nickname with a
number of other Tor nodes, and it does not have 'Named' rights to its
nickname.
So for example, if (i) there are five nodes named Bob in the network, (ii) I
am running one of them but am flagged as 'Unnamed' because someone else
claimed the 'Bob' nickname first, and (iii) I run my Tor as both client
and exit the following can happen to me:
- I go to www.evil.com
- I click on a link www.evil.com.bob.exit
- My request will exit through my own Tor node rather than the 'Named'
node Bob or any of the others.
- www.evil.com now knows I am actually browsing from the same computer
that is running my 'Bob' node
So to solve both issues we need to ensure:
- When fulfilling a .exit request we only choose a routerinfo if it exists in
the routerlist, even when that routerinfo is ours.
- When getting a router by nickname we only return our own router information
if it is not going to be used for building a circuit.
We ensure this by removing the special treatment afforded our own router in
router_get_by_nickname(). This means the function will only return the
routerinfo of our own router if it is in the routerlist built from authority
info and has a unique nickname or is bound to a non-unique nickname.
There are some uses of router_get_by_nickname() where we are looking for the
router by name because of a configuration directive, specifically local
declaration of NodeFamilies and EntryNodes and other routers' declaration of
MyFamily. In these cases it is not at first clear if we need to continue
returning our own routerinfo even if our router is not listed and/or has a
non-unique nickname with the Unnamed flag.
The patch treats each of these cases as follows:
Other Routers' Declaration of MyFamily
This happens in routerlist_add_family(). If another router declares our router
in its family and our router has the Unnamed flag or is not in the routerlist
yet, should we take advantage of the fact that we know our own routerinfo to
add us in anyway? This patch says 'no, treat our own router just like any
other'. This is a safe choice because it ensures our client has the same view
of the network as other clients. We also have no good way of knowing if our
router is Named or not independently of the authorities, so we have to rely on
them in this.
Local declaration of NodeFamilies
Again, we have no way of knowing if the declaration 'NodeFamilies
Bob,Alice,Ringo' refers to our router Bob or the Named router Bob, so we have
to defer to the authorities and treat our own router like any other.
Local declaration of NodeFamilies
Again, same as above. There's also no good reason we would want our client to
choose it's own router as an entry guard if it does not meet the requirements
expected of any other router on the network.
In order to reduce the possibility of error, the patch also replaces two
instances where we were using router_get_by_nickname() with calls to
router_get_by_hexdigest() where the identity digest of the router
is available.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
There are no relay left that run version 0.2.1.3 through 0.2.1.18, so
changing this behaviour should be safe now.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
We want to fetch directory info more aggressively if we need it to
refuseunknownexits. Thus, we'll want it if our exit policy is _NOT_
reject *.
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | |
| | | |
Found by rransom while working on issue #988. Bugfix on
0.2.2.17-alpha. Fixes bug 2097.
|
| | |
| | |
| | |
| | |
| | | |
-Wpointer-sign is implied with -Wall, which we use when building with
--enable-gcc-warnings.
|
| | |
| | |
| | |
| | |
| | |
| | | |
When configuring with --enable-gcc-warnings, we use -Wformat=2 which
automatically enables the available -Wformat switches, so adding them
again in the --enable-gcc-hardening case doesn't make sense..
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We used to enable ssp-buffer-size=1 only when building with
--enable-gcc-warnings. That would result in warnings (and no
protection for small arrays) when building with
--enable-gcc-hardening without enabling warnings, too. Fixes bug
2031.
Also remove an XXX: We now allow to build with -fstack-protector
by using --enable-gcc-hardening.
|
| |
| |
| |
| |
| | |
3d6e2830876 silenced the autogen.sh warnings as it was supposed to, but
introduced two bugs. Fix them.
|
| |
| |
| |
| |
| |
| | |
It looks like autoconf 2.68 introduced a bunch of new warnings when it
didn't like the syntax you used or forgot to use
AC_LANG_(SOURCE|PROGRAM).
|
| |
| |
| |
| |
| |
| | |
Whether or not OpenSSL reference-counts SSL_CTX objects is irrelevant;
what matters is that Tor reference-counts its wrapper objects for
SSL_CTXs.
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
|/| |
| | |
| | | |
also put in release blurbs
|
| | | |
|
| | |
| | |
| | |
| | | |
all rpm-based distributions
|
| | |
| | |
| | |
| | | |
needs higher permissions.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When picking bridges (or other nodes without a consensus entry (and
thus no bandwidth weights)) we shouldn't just trust the node's
descriptor. So far we believed anything between 0 and 10MB/s, where 0
would mean that a node doesn't get any use from use unless it is our
only one, and 10MB/s would be a quite siginficant weight. To make this
situation better, we now believe weights in the range from 20kB/s to
100kB/s. This should allow new bridges to get use more quickly, and
means that it will be harder for bridges to see almost all our traffic.
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This won't change any behavior, since it will still be rounded back
up to 2seconds, but should reduce the chances of some extra warns.
|
|\ \ \ \ |
|
| |/ / / |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the first 100 circuits, our timeout_ms and close_ms
are the same. So we shouldn't transition circuits to purpose
CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT, since they will just timeout again
next time we check.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Also, cap the measurement timeout to 2X the max we've seen.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We really should ignore any timeouts that have *no* network activity for their
entire measured lifetime, now that we have the 95th percentile measurement
changes. Usually this is up to a minute, even on fast connections.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
If we really want all this complexity for these stages here, we need to handle
it better for people with large timeouts. It should probably go away, though.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Rechecking the timeout condition was foolish, because it is checked on the
same codepath. It was also wrong, because we didn't round.
Also, the liveness check itself should be <, and not <=, because we only have
1 second resolution.
|
|\| | | |
|
| | | | |
|