In 8a0ea3ee43 we added a
temp_service_list local variable to rend_config_services, but we
didn't add a corresponding "free" for it to all of the exit paths.
Fixes bug 20987; bugfix on 0.3.0.1-alpha.
Add the "sr/current" and "sr/previous" keys for the GETINFO command in order
to get through the control port the shared random values from the consensus.
Closes#19925
Signed-off-by: David Goulet <dgoulet@torproject.org>
These relays need to be contacted over their ORPorts using a begindir
connection, and relays try not to use begindir connections.
Fixes bug 20711; bugfix on 0.2.8.2-alpha.
We switched these to be "if (1) " a while back, so we could keep
the indentation and avoid merge conflicts. But it's nice to clean
up from time to time.
Previously we were marking directory guards up in
..._process_inbuf(), but that's wrong: we call that function on
close as well as on success. Instead, we're marking the dirguard up
only after we parse the HTTP headers. Closes 20974.
When marking for close a circuit, the reason value, a integer, was assigned to
a uint16_t converting any negative reasons (internal) to the wrong value. On
the HS side, this was causing the client to flag introduction points to be
unreachable as the internal reason was wrongfully converted to a positive
16bit value leading to flag 2 out of 3 intro points to be unreachable.
Fixes#20307 and partially fixes#21056
Signed-off-by: David Goulet <dgoulet@torproject.org>
First, this commit moves the code used to prune the service list when
reloading Tor (HUP signal for instance) to a function from
rend_config_services().
Second, fix bug #21054, improve the code by using the newly added
circuit_get_next_service_intro_circ() function instead of poking at the global
list directly and add _many_ more comments.
Fixes#21054.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.
It also closes TROVE-2016-10-001 (aka bug 20384).
Replace the 81 remaining fallbacks of the 100 originally introduced
in Tor 0.2.8.3-alpha in March 2016, with a list of 177 fallbacks
(123 new, 54 existing, 27 removed) generated in December 2016.
Resolves ticket 20170.
In get_token(), we could read one byte past the end of the
region. This is only a big problem in the case where the region
itself is (a) potentially hostile, and (b) not explicitly
nul-terminated.
This patch fixes the underlying bug, and also makes sure that the
one remaining case of not-NUL-terminated potentially hostile data
gets NUL-terminated.
Fix for bug 21018, TROVE-2016-12-002, and CVE-2016-1254
They broke stem, and breaking application compatibility is usually a
bad idea.
This reverts commit 6e10130e18,
commit 78a13df158, and
commit 62f52a888a.
We might re-apply this later, if all the downstream tools can handle
it, and it turns out to be useful for some reason.
Since both the client and service will use that data structure to store the
descriptor decoded data, only the public keys are common to both.
Fixes#20572.
Signed-off-by: David Goulet <dgoulet@torproject.org>
The "sig_len" fields was moved below the "end_sig_fields" in the trunnel
specification so when signing the cell content, the function generating such a
cell needed to be adjust.
Closes#20991
Signed-off-by: David Goulet <dgoulet@torproject.org>
Previously, we had NumEntryGuards kind of hardwired to 1. Now we
have the code (but not the configuarability) to choose randomly from
among the first N primary guards that would work, where N defaults
to 1.
Part of 20831 support for making NumEntryGuards work again.
Since we already had a separate function for getting the universe of
possible guards, all we had to do was tweak it to handle very the
GS_TYPE_RESTRICTED case.
asn found while testing that this function can be reached with
GUARD_STATE_COMPLETE circuits; I believe this happens when
cannibalization occurs.
The added complexity of handling one more state made it reasonable
to turn the main logic here into a switch statement.
Letting the maximum sample size grow proportionally to the number of
guards defeats its purpose to a certain extent. Noted by asn during
code review.
Fixes bug 20920; bug not in any released (or merged) version of Tor.
- Correctly maintain the previous guard selection in choose_guard_selection().
- Print bridge identifier instead of nothing in entry_guard_describe()._
If a complete circuit C2 doesn't obey the restrictions of C1, then
C2 cannot block C1.
The patch here is a little big-ish, since we can no longer look
through all the complete circuits and all the waiting circuits on a
single pass: we have to find the best waiting circuit first.
This is an important thing I hadn't considered when writing prop271:
sometimes you have to restrict what guard you use for a particular
circuit. Most frequently, that would be because you plan to use a
certain node as your exit, and so you can't choose that for your
guard.
This change means that the upgrade-waiting-circuits algorithm needs
a slight tweak too: circuit A cannot block circuit B from upgrading
if circuit B needs to follow a restriction that circuit A does not
follow.
I had been asking myself, "hey, doesn't the new code need to look at
this "info" parameter? The old code did!" But it turns out that the
old code hasn't, since 05f7336624.
So instead of "support this!" the comment now says "we can remove
this!"
George pointed out that (-1,0,1) for (never usable, maybe usable
later, usable right now) was a pretty rotten convention that made
the code harder to read.
Here we handle most (all?) of the remaining tasks, and fix some
bugs, in the prop271 bridge implementation.
* We record bridge identities as we learn them.
* We only call deprecated functions from bridges.c when the
deprecated guard algorithm is in use.
* We update any_bridge_descriptors_known() and
num_bridges_usable() to work correctly with the new backend
code. (Previously, they called into the guard selection logic.
* We update bridge directory fetches to work with the new
guard code.
* We remove some erroneous assertions where we assumed that we'd
never load a guard that wasn't for the current selection.
Also, we fix a couple of typos.
Still missing is functionality for picking bridges when we don't
know a descriptor for them yet, and functionality for learning a
bridge ID.
Everything else remains (basically) the same. Neat!
This includes:
* making bridge_info_t exposed but opaque
* allowing guards where we don't know an identity
* making it possible to learn the identity of a guard
* creating a guard that lacks a node_t
* remembering a guard's address and port.
* Looking up a guard by address and port.
* Only enforcing the rule that we need a live consensus to update
the "listed" status for guards when we are not using bridges.
This is safe, because no entry_guard_t ever outlives its
guard_selection_t.
I want this because now that multiple guard selections can be active
during one tor session, we should make sure that any information we
register about guards is with respect to the selection that they came
from.
Currently, this code doesn't actually have the contexts behave
differently, (except for the legacy context), but it does switch
back and forth between them nicely.
If a guard becomes primary as a result of confirming it, consider
the circuit through that guard as a primary circuit.
Also, note open questions on behavior when confirming nonprimary guards
Some of these will get torrc options to override them too; this
is just the mechanical conversion.
Also, add documentation for a couple of undocumented (but now used)
parameters.
The new HS circuitmap API replaces old public functions as follows:
circuit_clear_rend_token -> hs_circuitmap_remove_circuit
circuit_get_rendezvous -> hs_circuitmap_get_rend_circ
circuit_get_intro_point -> hs_circuitmap_get_intro_circ_v2
circuit_set_rendezvous_cookie -> hs_circuitmap_register_rend_circ
circuit_set_intro_point_digest -> hs_circuitmap_register_intro_circ_v2
This commit also removes the old rendinfo code that is now unused.
It also fixes the broken rendinfo unittests.
The HS circuitmap is a hash table that maps introduction and rendezvous
tokens to specific circuits such that given a token it's easy to find
the corresponding circuit. It supports rend circuits and v2/v3 intro
circuits.
It will be used by the prop224 ESTABLISH_INTRO code to register and
lookup v3 introduction circuits.
The next commit after this removes the old code and fixes the unittests.
Please consult both commits while reviewing functionality differences
between the old and new code. Let me know if you want this rebased
differently :)
WRT architectural differences, this commit removes the rendinfo pointer
from or_circuit_t. It then adds an hs_token_t pointer and a hashtable
node for the HS circuitmap. IIUC, this adds another pointer to the
weight of or_circuit_t. Let me know if you don't like this, or if you
have suggestions on improving it.
Back when Roger had do do most of our testing on the moria host, we
needed a higher limit for the number of relays running on a single
IP address when that limit was shared with an authority. Nowadays,
the idea is pretty obsolete.
Also remove the router_addr_is_trusted_dir() function, which served
no other purpose.
Closes ticket 20960.
In c35fad2bde, merged in
0.2.4.7-alpha, we removed the code to parse v1 directory
objects. When we did so, we removed everything that could set the
CST_CHECK_AUTHORITY flag for check_signature_token().
So in this code, we remove the flag itself, the code to handle the
flag, and a function that only existed to handle the flag.
The signed_descriptor_move() was not releasing memory inside the destination
object before overwriting it with the source object. This commit adds a reset
function that free that memory inside a signed descriptor object and zero it.
Closes#20715.
Signed-off-by: David Goulet <dgoulet@torproject.org>
If a node can prove its Ed25519 identity, don't consider connections
to it canonical unless they match both identities.
Includes link handshake changes needed to avoid crashing with bug
warnings, since the tests now reach more parts of the code.
Closes ticket 20355
(Only run the connection_or_group_set_badness_() function on groups
of channels that have the same RSA and Ed25519 identities.)
There's a possible opportunity here where we might want to set a
channel to "bad" if it has no ed25519 identity and some other
channel has some. Also there's an opportunity to add a warning if
we ever have an Ed mismatch on open connections with the same RSA
ID.
This function has never gotten testing for the case where an
identity had been set, and then got set to something else. Rather
than make it handle those cases, we forbid them.
If there is some horrible bug in our ed25519 link authentication
code that causes us to label every single ed25519-having node as
non-running, we'll be glad we had this. Otherwise we can remove it
later.
This patch makes two absolutely critical changes:
- If an ed25519 identity is not as expected when creating a channel,
we call that channel unsuccessful and close it.
- When a client creating a channel or an extend cell for a circuit, we
only include the ed25519 identity if we believe that the node on
the other side supports ed25519 link authentication (from
#15055). Otherwise we will insist on nodes without the right
link protocol authenticating themselves.
- When deciding to extend to another relay, we only upgrade the
extend to extend by ed25519 ID when we know the ed25519 ID _and_
we know that the other side can authenticate.
This patch also tells directory servers, when probing nodes, to
try to check their ed25519 identities too (if they can authenticate
by ed25519 identity).
Also, handle the case where we connect by RSA Id, and learn the
ED25519 ID for the node in doing so.
I need to be able to turn on Ed25519 support in client generation
of extend cells so I can test it, but leave it off-by-default until
enough clients support it for us to turn it on for a bunch at once.
This is part of #15056 / prop#220.
- forbid extending to the previous hop by Ed25519 ID.
- If we know the Ed25519 ID for the next hop and the client doesn't,
insist on the one from the consensus.
Right now, there's only a mechanism to look for a channel where the
RSA ID matches *and* the ED ID matches. We can add a separate map
later if we want.
This resolves two issues:
* the checks in rend_add_services were only being performed when adding
the service, and not when the service was validated,
(this meant that duplicate checks were not being performed, and some SETCONF
commands appeared to succeed when they actually failed), and
* if one service failed while services were being added, then the service
list would be left in an inconsistent state (tor dies when this happens,
but the code is cleaner now).
Fixes#20860.
When computing old Tor protocol line version in protover, we were looking at
0.2.7.5 twice instead of the specific case for 0.2.9.1-alpha.
Fixes#20810
Signed-off-by: David Goulet <dgoulet@torproject.org>
newconn->address is strdup'ed twice when new_type == CONN_TYPE_AP
and conn->socket_family == AF_UNIX. Whilst here, juggle code to
make sure newconn->port is assigned from an initialised value in
the above case.
Instead, refuse to start tor until the misconfigurations have been corrected.
Fixes bug 20559; bugfix on multiple commits in 0.2.7.1-alpha and earlier.
Instead, refuse to start tor if any hidden service key has been used in
a different hidden service anonymity mode.
Fixes bug 20638; bugfix on 17178 in 0.2.9.3-alpha; reported by ahf.
The original single onion service poisoning code checked poisoning state
in options_validate, and poisoned in options_act. This was problematic,
because the global array of hidden services had not been populated in
options_validate (and there were ordrering issues with hidden service
directory creation).
This patch fixes this issue in rend_service_check_dir_and_add, which:
* creates the directory, or checks permissions on an existing directory, then
* checks the poisoning state of the directory, then
* poisons the directory.
When validating, only the permissions checks and the poisoning state checks
are perfomed (the directory is not modified).
To do this, it makes sense to treat legacy guards as a separate
guard_selection_t *, and handle them separately. This also means we
add support here for having multiple guard selections.
Note that we don't persist pathbias information yet; that will take
some refactoring.
This patch doesn't cover every case; omitted cases are marked with
"XXXX prop271", as usual. It leaves both the old interface and the
new interface for guard status notification, since they don't
actually work in the same way: the new API wants to be told when a
circuit has failed or succeeded, whereas the old API wants to know
when a channel has failed or succeeded.
I ran into some trouble with directory guard stuff, since when we
pick the directory guard, we don't actually have a circuit to
associate it with. I solved that by allowing guard states to be
associated with directory connections, not just circuits.
I expect we'll be ripping this out somewhere in 0.3.0, but let's
keep it around for a little while in case it turns out to be the
only way to avert disaster?
This state corresponds to the WAITING_FOR_BETTER_GUARD state; it's
for circuits that are 100% constructed, but which we won't use until
we are sure that we wouldn't use circuits with a better guard.
When a nonprimary guard's circuit is complete, we don't call it
actually usable until we are pretty sure that every better guard
is indeed not going to give us a working circuit.
Here we add a little bit of state to origin circuits, and set up
the necessary functions for the circuit code to call in order to
find guards, use guards, and decide when circuits can be used.
There's also an incomplete function for the hard part of the
circuit-maintenance code, where we figure out whether any waiting
guards are ready to become usable.
(This patch finally uses the handle.c code to make safe handles to
entry_guard_t objects, so that we are allowed to free an
entry_guard_t without checking whether any origin_circuit_t is
holding a reference to it.)
This code handles:
* Maintaining the sampled set, the filtered set, and the
usable_filtered set.
* Maintaining the confirmed and primary guard lists.
* Picking guards for circuits, and updating guard state when
circuit state changes.
Additionally, I've done code structure movement: even more constants
and structures from entrynodes.c have become ENTRYNODES_PRIVATE
fields of entrynodes.h.
I've also included a bunch of documentation and a bunch of unit
tests. Coverage on the new code is pretty high.
I've noted important things to resolve before this branch is done
with the /XXXX.*prop271/ regex.
These are taken from the proposal, and defined there. Some of them
should turn into consensus parameters.
Also, remove some dead code that was there to make compilation work,
and use ATTR_UNUSED like a normal person.
The previous commit, in moving a bunch of functions to bridges.c,
broke compilation because bridges.c required two entry points to
entrynodes.c it didn't have.
This patch is just:
* Code movement
* Adding headers here and there as needed
* Adding a bridges_free_all() with a call to it.
It breaks compilation, since the bridge code needed to make exactly
2 calls into entrynodes.c internals. I'll fix those in the next
commit.
The encoding code is very straightforward. The decoding code is a
bit tricky, but clean-ish. The sampling code is untested and
probably needs more work.
This was a relatively mechanical change. First, I added an accessor
function for the pathbias-state field of a guard. Then I did a
search-and-replace in circpathbias.c to replace "guard->pb." with
"pb->". Finally, I made sure that "pb" was declared whenever it was
needed.
The entry_guard_t structure should really be opaque, so that we
can change its contents and have the rest of Tor not care.
This commit makes it "mostly opaque" -- circpathbias.c can still see
inside it. (I'm making circpathbias.c exempt since it's the only
part of Tor outside of entrynodes.c that made serious use of
entry_guard_t internals.)
This affects clients with FetchUselessDescriptors 1.
It might also cause subtle bugs on directory mirrors and authorities,
causing them to consider all full descriptors as failed or old.
Improve the messages logged when Tor wants or needs to load the master ed25519 identity key so the user is explicitly informed when further action is required or not. Fixes ticket #20650.
(We only create HS directories if we are acting on the config.)
Log a BUG warning if the directories aren't present immediately before they
are used, then fail.
For relays that don't know their own address, avoid attempting
a local hostname resolve for each descriptor we download. Also cut
down on the number of "Success: chose address 'x.x.x.x'" log lines.
Fixes bugs 20423 and 20610; bugfix on 0.2.8.1-alpha.
Single onion services and Tor2web deliberately create long-term one-hop
circuits to their intro and rend points, respectively.
These log messages are intended to diagnose issue 8387, which relates to
circuits hanging around forever for no reason.
Fixes bug 20613; bugfix on 0.2.9.1-alpha. Reported by "pastly".
This field indicates if the service is a Single Onion Service if present in
the descriptor.
Closes#19642
Signed-off-by: David Goulet <dgoulet@torproject.org>
Because as Teor puts it: "[Resetting on 503] is exactly what we
don't want when relays are busy - imagine clients doing an automatic
reset every time they DoS a relay..."
Fixes bug 20593.
As of #19899, we decided to allow any relay understanding the onion service
version 3 protocol to be able to use it. The service and client will be the
one controlled by a consensus parameter (different one for both of them) but
if you are a relay and you can understand a protocol, basically you should use
the feature.
Closes#19899
Signed-off-by: David Goulet <dgoulet@torproject.org>
It's only safe to remove the failure limit (per 20536) if we are in
fact waiting a bit longer each time we try to download.
Fixes bug 20534; bugfix on 0.2.9.1-alpha.
If a consensus expires while we are waiting for certificates to download,
stop waiting for certificates.
If we stop waiting for certificates less than a minute after we started
downloading them, do not consider the certificate download failure a
separate failure.
Fixes bug 20533; bugfix on commit e0204f21 in 0.2.0.9-alpha.
Relays do not deliberately launch multiple attempts, so the impact of this
bug should be minimal. This fix also defends against bugs like #20499.
Bugfix on 0.2.8.1-alpha.
Note that the "signed key" in the signing key certificate is the
signing key. The "signing key" in the signing key certificate is
the key that signs the certificate -- that is, the blinded key.
This parameter controls if onion services version 3 (first version of prop224)
is enabled or not. If disabled, the tor daemon will not support the protocol
for all components such as relay, directory, service and client. If the
parameter is not found, it's enabled by default.
Closes#19899
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
This implements the proposal 224 directory descriptor cache store and lookup
functionalities. Furthermore, it merges the OOM call for the HSDir cache with
current protocol v2 and the new upcoming v3.
Add hs_cache.{c|h} with store/lookup API.
Closes#18572
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
Add hs_descriptor.{c|h} with the needed ABI to represent a descriptor and
needed component.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
In order to implement proposal 224, we need the data structure rend_data_t to
be able to accomodate versionning that is the current version of hidden
service (2) and the new version (3) and future version.
For that, we implement a series of accessors and a downcast function to get
the v2 data structure. rend_data_t becomes a top level generic place holder.
The entire rend_data_t API has been moved to hs_common.{c|h} in order to
seperate code that is shared from between HS versions and unshared code (in
rendcommon.c).
Closes#19024
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
This function is allowed to return NULL if the certified key isn't
RSA. But in a couple of places we were treating this as a bug or
internal error, and in one other place we weren't checking for it at
all!
Caught by Isis during code review for #15055. The serious bug was
only on the 15055 branch, thank goodness.
This was a stopgap method, designed on the theory that some routers
might support it before they could support Ed25519. But it looks
like everybody who supports RFC5705 will also have an Ed25519 key,
so there's not a lot of reason to have this even supported.
This code stores the ed certs as appropriate, and tries to check
them. The Ed25519 result is not yet used, and (because of its
behavior) this will break RSA authenticate cells. That will get
fixed as we go, however.
This should implement 19157, but it needs tests, and it needs
to get wired in.
In particular, these functions are the ones that set the identity of
a given connection or channel, and/or confirm that we have learned
said IDs.
There's a lot of stub code here: we don't actually need to use the
new keys till we start looking up connections/channels by Ed25519
IDs. Still, we want to start passing the Ed25519 IDs in now, so it
makes sense to add these stubs as part of 15055.
The impact here isn't too bad. First, the only affected certs that
expire after 32-bit signed time overflows in Y2038. Second, it could
only make it seem that a non-expired cert is expired: it could never
make it seem that an expired cert was still live.
Fixes bug 20027; bugfix on 0.2.7.2-alpha.
Also, adjust signing approach to more closely match the signing
scheme in the proposal.
(The format doesn't quite match the format in the proposal, since
RSA signatures aren't fixed-length.)
Closes 19020.
See proposal 244. This feature lets us stop looking at the internals
of SSL objects, *and* should let us port better to more SSL libraries,
if they have RFC5705 support.
Preparatory for #19156
We no longer generate certs cells by pasting the certs together one
by one. Instead we use trunnel to generate them.
Preliminary work for 19155 (send CERTS cell with ed certs)
