| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Since packed_cell and destroy_cell exist only to be queued, they go
in the same headers as the queues.
|
|
|
|
|
|
There are quite a few other places this could be used, but keeping it simple
for now.
|
|
|
|
* ADD new /src/common/crypto_rand.[ch] module.
* ADD new /src/common/crypto_util.[ch] module (contains the memwipe()
function, since all crypto_* modules need this).
* FIXES part of #24658: https://bugs.torproject.org/24658
|
|
When a relay is collecting internal statistics about how many
create cell requests it has seen of each type, accurately count the
requests from relays that temporarily fall out of the consensus.
(To be extra conservative, we were already ignoring requests from clients
in our counts, and we continue ignoring them here.)
Fixes bug 24910; bugfix on 0.2.4.17-rc.
|
|
some of these ought to have been noticed by the "misspell" tool,
so if anybody is debugging it, here are some bug reports :)
|
|
|
|
If the client address was detected as malicious, apply a defense which is at
this commit to return a DESTROY cell.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Add a function that notifies the DoS subsystem that a new CREATE cell has
arrived. The statistics are updated accordingly and the IP address can also be
marked as malicious if it is above threshold.
At this commit, no defense is applied, just detection with a circuit creation
token bucket system.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Fix a set of false positives where relays would consider connections
to other relays as being client-only connections (and thus e.g.
deserving different link padding schemes) if those relays fell out
of the consensus briefly.
Now we look only at the initial handshake and whether the connection
authenticated as a relay.
Fixes bug 24898; bugfix on 0.3.1.1-alpha.
|
|
|
|
Relays send it, and we may as well let them. Part of our fix for
22805.
|
|
|
|
|
|
|
|
|
|
https://gitlab.com/dgoulet/tor/merge_requests/24
|
|
This defense will cause Cisco, Juniper, Fortinet, and other routers operating
in the default configuration to collapse netflow records that would normally
be split due to the 15 second flow idle timeout.
Collapsing these records should greatly reduce the utility of default netflow
data for correlation attacks, since all client-side records should become 30
minute chunks of total bytes sent/received, rather than creating multiple
separate records for every webpage load/ssh command interaction/XMPP chat/whatever
else happens to be inactive for more than 15 seconds.
The defense adds consensus parameters to govern the range of timeout values
for sending padding packets, as well as for keeping connections open.
The defense only sends padding when connections are otherwise inactive, and it
does not pad connections used solely for directory traffic at all. By default
it also doesn't pad inter-relay connections.
Statistics on the total padding in the last 24 hours are exported to the
extra-info descriptors.
|
|
|
|
This means that we bail out earlier if asked to extend to a client.
Follow-up to 21407.
Fixes bug 21406; bugfix on 0.2.4.23.
|
|
|
|
This commit adds or improves the module-level documenation for:
buffers.c circuitstats.c command.c connection_edge.c control.c
cpuworker.c crypto_curve25519.c crypto_curve25519.h
crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
protover.c protover.h reasons.c rephist.c replaycache.c
routerlist.c routerparse.c routerset.c statefile.c status.c
tor_main.c workqueue.c
In particular, I've tried to explain (for each documented module)
what each module does, what's in it, what the big idea is, why it
belongs in Tor, and who calls it. In a few cases, I've added TODO
notes about refactoring opportunities.
I've also renamed an argument, and fixed a few DOCDOC comments.
|
|
|
|
* FIXES #16823: https://bugs.torproject.org/16823
If an OP were to send a CREATE_FAST cell to an OR, and that
CREATE_FAST cell had unparseable key material, then tor_free() would
be called on the create cell twice. This fix removes the second
(conditional on the key material being bad) call to tor_free(), so
that now the create cell is always freed once, regardless of the status of
the key material.
(This isn't actually a double-free bug, since tor_free() sets its
input to NULL, and has no effect when called with input NULL.)
|
|
Conflicts:
src/test/test.c
|
|
|
|
|
|
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.
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
Also, refactor the way we handle failed handshakes so that this
warning doesn't propagate itself to "onion_skin_client_handshake
failed" and "circuit_finish_handshake failed" and
"connection_edge_process_relay_cell (at origin) failed."
Resolves warning from 9635.
|
|
|
|
Those used to be normal to receive on hidden service circuits due to bug
1038, but the buggy Tor versions are long gone from the network so we
can afford to resume watching for them. Resolves the rest of bug 1038;
bugfix on 0.2.1.19.
|
|
Roger spotted this on tor-dev in his comments on proposal 221.
(Actually, detect DESTROY vs everything else, since arma likes
network timeout indicating failure but not overload indicating failure.)
|
|
And add a comment about why conditions that would cause us to drop a
cell should get checked before actions that would cause us to send a
destroy cell.
Spotted by 'cypherpunks'.
And note that these issues have been present since 0.0.8pre1 (commit
0da256ef), where we added a "shutting down" state, and started
responding to all create cells with DESTROY when shutting down.
|
|
This means that we never send a DESTROY cell in response to an attempt
to CREATE an existing circuit. Fixes bug 12191.
|
|
|
|
This code mis-handled the case where a circuit got the same circuit
ID in both directions. I found three instances of it in the
codebase, by grepping for [pn]_circ_id.
Because of the issue in command_process_relay_cell(), this would
have made roughly one circuit in a million completely nonfunctional.
Fixes bug 12195.
|
|
Conflicts:
src/or/or.h
|
|
Roger spotted this on tor-dev in his comments on proposal 221.
We etect DESTROY vs everything else, since arma likes network
timeout indicating failure but not overload indicating failure.
|
|
Conflicts:
doc/tor.1.txt
src/or/config.c
src/or/connection.h
src/or/control.c
src/or/control.h
src/or/or.h
src/or/relay.c
src/or/relay.h
src/test/test.c
|
|
we skip onionskins that came from non-relays, so we're less likely to
run into privacy troubles.
starts to implement ticket 9658.
|
|
- Move cell_command_to_string from control.c to command.c.
- Use accessor for global_circuitlist instead of extern.
- Add a struct for cell statistics by command instead of six arrays.
- Split up control_event_circuit_cell_stats by using two helper functions.
- Add TestingEnableCellStatsEvent option.
- Prepare functions for testing.
- Rename a few variables and document a few things better.
|
|
Now that circid_t is 4 bytes long, the default integer promotions will
leave it alone when sizeof(int) == 4, which will leave us formatting an
unsigned as an int. That's technically undefined behavior.
Fixes bug 8447 on bfffc1f0fc7616a25c32da2eb759dade4651659e. Bug not
in any released Tor.
|
|
Conflicts:
src/or/channel.h
src/or/connection_or.c
src/or/cpuworker.c
|
