| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Otherwise, relays publish a descriptor with DirPort 0 when the DirPort
reachability test takes longer than the ORPort reachability test.
Closes bug #18050. Reported by "starlight", patch by "teor".
Bugfix on 0.1.0.1-rc, commit a1f1fa6ab on 27 Feb 2005.
|
|
ExitPolicyRejectPrivate now rejects more local addresses by default:
* the relay's published IPv6 address (if any), and
* any publicly routable IPv4 or IPv6 addresses on any local interfaces.
This resolves a security issue for IPv6 Exits and multihomed Exits that
trust connections originating from localhost.
Resolves ticket 17027. Patch by "teor".
Patch on 42b8fb5a1523 (11 Nov 2007), released in 0.2.0.11-alpha.
|
|
This should simplify the callgraph a little more.
|
|
(Mark them as obsolete)
Closes 16543.
|
|
|
|
|
|
Fixed numerous conflicts, and ported code to use new base64 api.
|
|
We need this to prevent some annoying chutney crash-at-starts
|
|
(Our link protocol assumes that the link cert certifies the TLS key,
and there is an RSA->Ed25519 crosscert)
|
|
Extrainfo documents are now ed-signed just as are router
descriptors, according to proposal 220. This patch also includes
some more tests for successful/failing parsing, and fixes a crash
bug in ed25519 descriptor parsing.
|
|
With this patch:
* Authorities load the key-pinning log at startup.
* Authorities open a key-pinning log for writing at startup.
* Authorities reject any router with an ed25519 key where they have
previously seen that ed25519 key with a different RSA key, or vice
versa.
* Authorities warn about, but *do not* reject, RSA-only descriptors
when the RSA key has previously gone along with an Ed25519 key.
(We should make this a 'reject' too, but we can't do that until we're
sure there's no legit reason to downgrade to 0.2.5.)
|
|
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
|
|
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
|
|
Now that we have ed25519 keys, we can sign descriptors with them
and check those signatures as documented in proposal 220.
|
|
For prop220, we have a new ed25519 certificate type. This patch
implements the code to create, parse, and validate those, along with
code for routers to maintain their own sets of certificates and
keys. (Some parts of master identity key encryption are done, but
the implementation of that isn't finished)
|
|
|
|
|
|
|
|
Incidently, this fixes a bug where the maximum value was never used when
only using crypto_rand_int(). For instance this example below in
rendservice.c never gets to INTRO_POINT_LIFETIME_MAX_SECONDS.
int intro_point_lifetime_seconds =
INTRO_POINT_LIFETIME_MIN_SECONDS +
crypto_rand_int(INTRO_POINT_LIFETIME_MAX_SECONDS -
INTRO_POINT_LIFETIME_MIN_SECONDS);
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
Allow building a router descriptor without storing it to global state.
This is in preparation of a patch to export the created descriptors via
the control port.
|
|
Conflicts:
src/or/connection.c
src/or/or.h
src/or/relay.c
|
|
Also, apply this cocci script to transform accesses. (Plus manual
migration for accesses inside smartlist_foreach loops.)
@@
port_cfg_t *cfgx;
@@
cfgx->
+server_cfg.
\(
no_advertise
\|
no_listen
\|
all_addrs
\|
bind_ipv4_only
\|
bind_ipv6_only
\)
@@
port_cfg_t *cfgx;
@@
cfgx->
+entry_cfg.
\(
isolation_flags
\|
session_group
\|
socks_prefer_no_auth
\|
ipv4_traffic
\|
ipv6_traffic
\|
prefer_ipv6
\|
cache_ipv4_answers
\|
cache_ipv6_answers
\|
use_cached_ipv4_answers
\|
use_cached_ipv6_answers
\|
prefer_ipv6_virtaddr
\)
|
|
bug13111-empty-key-files-fn-empty
Conflicts:
src/or/connection_edge.c
Merged in favour of origin.
|
|
Conflicts:
src/or/router.c
Choose newer comment.
Merge changes to comment and function invocation.
|
|
|
|
|
|
Decrease minimum consensus interval to 10 seconds
when TestingTorNetwork is set. (Or 5 seconds for
the first consensus.)
Fix code that assumes larger interval values.
This assists in quickly bootstrapping a testing
Tor network.
Fixes bugs 13718 & 13823.
|
|
|
|
The two statistics are:
1. number of RELAY cells observed on successfully established
rendezvous circuits; and
2. number of .onion addresses observed as hidden-service
directory.
Both statistics are accumulated over 24 hours, obfuscated by rounding
up to the next multiple of a given number and adding random noise,
and written to local file stats/hidserv-stats.
Notably, no statistics will be gathered on clients or services, but
only on relays.
|
|
Specifically, only if we're creating secret_id_key do we log the
greeting (and then only if the key is actually created).
|
|
Instead, generate new keys, and overwrite the empty key files.
Adds FN_EMPTY to file_status_t and file_status.
Fixes bug 13111.
Related changes due to review of FN_FILE usage:
Stop generating a fresh .old RSA key file when the .old file is missing.
Avoid overwriting .old key files with empty key files.
Skip loading zero-length extra info store, router store, stats, state,
and key files.
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
|
|
By now, support in the network is widespread and it's time to require
more modern crypto on all Tor instances, whether they're clients or
servers. By doing this early in 0.2.6, we can be sure that at some point
all clients will have reasonable support.
|
|
When Tor first generates identity keypair, emit a log message that
thanks for their participation and points to new Tor relay lifecycle
document.
|
|
Ensure we securely wipe keys from memory after
crypto_digest_get_digest and init_curve25519_keypair_from_file
have finished using them.
Fixes bug 13477.
|
|
One pain point in evolving the Tor design and implementing has been
adding code that makes clients reject directory documents that they
previously would have accepted, if those descriptors actually exist.
When this happened, the clients would get the document, reject it,
and then decide to try downloading it again, ad infinitum. This
problem becomes particularly obnoxious with authorities, since if
some authorities accept a descriptor that others don't, the ones
that don't accept it would go crazy trying to re-fetch it over and
over. (See for example ticket #9286.)
This patch tries to solve this problem by tracking, if a descriptor
isn't parseable, what its digest was, and whether it is invalid
because of some flaw that applies to the portion containing the
digest. (This excludes RSA signature problems: RSA signatures
aren't included in the digest. This means that a directory
authority can still put another directory authority into a loop by
mentioning a descriptor, and then serving that descriptor with an
invalid RSA signatures. But that would also make the misbehaving
directory authority get DoSed by the server it's attacking, so it's
not much of an issue.)
We already have a mechanism to mark something undownloadable with
downloadstatus_mark_impossible(); we use that here for
microdescriptors, extrainfos, and router descriptors.
Unit tests to follow in another patch.
Closes ticket #11243.
|
|
Generally, we don't like to parse the same thing over and over; it's
best IMO to do it once at the start of the code.
|
|
Patch from "chobe". Closes ticket 961.
|
|
|
|
This implements the meat of #12899. This commit should simply remove the
parts of Tor dirauths used to check whether a relay was supposed to be
named or not, it doesn't yet convert to a new mechanism for
reject/invalid/baddir/badexiting relays.
|
|
When a tor relay starts up and has no historical information about its
bandwidth capability, it uploads a descriptor with a bw estimate of 0.
It then starts its bw selftest, but has to wait 20 minutes to upload the
next descriptor due to the MAX_BANDWIDTH_CHANGE_FREQ delay. This change
should mean that on average, relays start seeing meaningful traffic a
little quicker, since they will have a higher chance to appear in the
consensus with a nonzero bw.
Patch by Roger, changes file and comment by Sebastian.
|
|
|
|
Fixes bug 12728; bugfix on 0.2.1.7-alpha when the SPLIT_IGNORE_SPACE
option was added.
|
|
|
|
Fix for 12512.
|
|
(Whoops, thought I had committed this before)
Improvement to 11683 fix. Based on patch from Karsten.
|
|
|
|
|
