Nick Mathewson [Sun, 20 Aug 2017 16:35:26 +0000 (12:35 -0400)]
Add stream isolation support for HTTP CONNECT tunnels
I'm doing this using the Proxy-Authorization: header to support
clients that understand it, and with a new tor-specific header that
makes more sense for our use.
Nick Mathewson [Tue, 8 Aug 2017 19:54:15 +0000 (15:54 -0400)]
Refactor buffer APIs to put a buf_t first.
By convention, a function that frobs a foo_t should be called
foo_frob, and it should have a foo_t * as its first argument. But
for many of the buf_t functions, the buf_t was the final argument,
which is silly.
Nick Mathewson [Tue, 8 Aug 2017 19:16:39 +0000 (15:16 -0400)]
Repair buffer API so everything starts with buf_.
Our convention is that functions which manipulate a type T should be
named T_foo. But the buffer functions were super old, and followed
all kinds of conventions. Now they're uniform.
Nick Mathewson [Tue, 8 Aug 2017 16:07:25 +0000 (12:07 -0400)]
Make buf_pullup() expose the pulled-up data.
This lets us drop the testing-only function buf_get_first_chunk_data(),
and lets us implement proto_http and proto_socks without looking at
buf_t internals.
David Goulet [Fri, 25 Aug 2017 18:03:15 +0000 (14:03 -0400)]
hs: Don't enter the HS v3 subsystem without a live consensus
The service needs the latest SRV and set of relays for the best accurate
hashring to upload its descriptor to so it needs a live consensus thus don't
do anything until we have it.
Fixes #23331
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Wed, 30 Aug 2017 12:34:02 +0000 (08:34 -0400)]
hs: Remove dead code and uneeded feature
When merging #20657, somehow hs_service_dir_info_changed() became unused
leading to not use the re-upload to HSDir when we were missing information
feature.
Turns out that it is not possible to pick an HSDir with a missing descriptor
because in order to compute the HSDir index, the descriptor is mandatory to
have so we can know its position on the hashring.
This commit removes that dead feature and fix the
hs_service_dir_info_changed() not being used.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Mon, 4 Sep 2017 15:54:49 +0000 (11:54 -0400)]
22752: Improve comments to explain why we're doing this fix.
Based on questions and comments from dgoulet, I've tried to fill
in the reasoning about why these functions work in the way that they
do, so that it will be easier for future programmers to understand
why this code exists and works the way it does.
prop224: Clear list of prev hsdirs before we upload all descs.
This fixes a serious bug in our hsdir set change logic:
We used to add nodes in the list of previous hsdirs everytime we
uploaded to a new hsdir and we only cleared the list when we built a new
descriptor. This means that our prev_hsdirs list could end up with 7
hsdirs, if for some reason we ended up uploading our desc to 7 hsdirs
before rebuilding our descriptor (e.g. this can happen if the set of
hsdirs changed).
After our previous hdsir set had 7 nodes, then our old algorithm would
always think that the set has changed since it was comparing a smartlist
with 7 elements against a smartlist with 6 elements.
This commit fixes this bug, by clearning the prev_hsdirs list before we
upload to all hsdirs. This makes sure that our prev_hsdirs list always
contains the latest hsdirs!
Our logic for detecting hsdir set changes was needlessly compicated: we
had to sort smartlists and compare them.
Instead, we can simplify things by employing the following logic:
"We should reupload our descriptor if the latest HSDir set contains
nodes that were not previously there"
Nick Mathewson [Tue, 29 Aug 2017 17:03:36 +0000 (13:03 -0400)]
On windows, allow many entries in conscache directories
Since we can't be sure that we can unlink enough files on windows
here, let's let the number of permitted entries grow huge if it
really must.
We do this by letting the storagedir hold lots of entries, but still
trying to keep the number of entries under the configured limit. We
also have to tell consdiffmgr not to freak out if it can't actually
remove enough entries.
David Goulet [Mon, 28 Aug 2017 18:31:32 +0000 (14:31 -0400)]
hs: Fix the intro circuit max retry
Some parentheses were missing making the rend_max_intro_circs_per_period()
return a lower value than it was suppose to.
The calculation is that a service at most will open a number of intro points
that it wants which is 3 by default or HiddenServiceNumIntroductionPoints. Two
extra are launched for performance reason. Finally, this can happen twice for
two descriptors for the current and next time period.
From:
2 * n_intro_wanted + 2
...which resulted in 8 for 3 intro points, this commit fixes it to:
(n_intro_wanted + 2) * 2
... resulting in 12 possible intro point circuit which is the correct maximum
intro circuit allowed per period.
Last, this commit rate limits the the log message if we ever go above that
limit else over a INTRO_CIRC_RETRY_PERIOD, we can print it often!
Fixes #22159
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Mon, 28 Aug 2017 14:11:49 +0000 (10:11 -0400)]
In test_establish_intro_wrong_purpose, use tt_i64_op on ssize_t
Since ssize_t is signed and might be 64 bits, we should use
tt_i64_op to make sure it's positive. Otherwise, if it is negative,
and we use tt_u64_op, we'll be treating it as a uint64_t, and we
won't detect negative values.
This fixes CID 1416338 and 1416339. Bug not in any released Tor.
prop224: Fix length check when purging hidserv requests.
That check was wrong:
a) We should be making sure that the size of `key` is big enough before
proceeding, since that's the buffer that we would overread with the
tor_memeq() below.
The old check used to check that `req_key_str` is big enough which is
not right, since we won't read deep into that buffer.
The new check makes sure that `key` has enough size to survive the
tor_memeq(), and if not it moves to the next element of the strmap.
b) That check shouldn't be a BUG since that strmap contains
variable-sized elements and we should not be bugging out if we happen
to compare a small sized element (v2) to a bigger one (v3).
David Goulet [Fri, 25 Aug 2017 17:39:40 +0000 (13:39 -0400)]
hs: Note the connection attempt if descriptor is unusable
This way, we can clear off the directory requests from our cache and thus
allow the next client to query those HSDir again at the next SOCKS connection.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Fri, 25 Aug 2017 16:35:38 +0000 (12:35 -0400)]
Restore documentation for approved-routers
We removed this documentation in 607724c696a6e, when we removed
Naming Authoritative Directories, but actually this file is still
used by authorities to indicate rejected and invalid fingerprints.
prop224: When HUPing, move HS state from old to new service.
We used to not copy the state which means that after HUP we would forget
if we are in overlap mode or not. That caused bugs where the service
would enter overlap mode twice, and rotate its descs twice, causing all
sorts of bugs.
David Goulet [Fri, 28 Jul 2017 15:47:32 +0000 (11:47 -0400)]
prop224: Don't move intro points but rather descriptors
Apart from the fact that a newly allocated service doesn't have descriptors
thus the move condition can never be true, the service needs the descriptor
signing key to cross-certify the authentication key of each intro point so we
need to move the descriptors between services and not only the intro points.
Fixes #23056
Signed-off-by: David Goulet <dgoulet@torproject.org>
We refactor the descriptor reupload logic to be similar to the v2 logic
where we update a global 'consider_republishing_rend_descriptors' flag
and then we use that to check for hash ring changes during the global
hidden service callbacks.
This fixes bugs where we would inspect the hash ring immediately as we
receive new dirinfo (e.g. consensus) but before running the hidden
service housekeeping events. That was leaving us in an inconsistent
state wrt hsdir indices and causing bugs all around.
The problem was that when we went from overlap mode to non-overlap mode,
we were not wiping the 'desc_next' descriptor and instead we left it on
the service. This meant that all functions that iterated service
descriptors were also inspecting the useless 'desc_next' descriptor that
should have been deleted.
This commit refactors rotate_all_descriptors() so that it rotates
descriptor both when entering overlap mode and also when leaving it.
projects / thirdparty / tor.git / log
