mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 22:03:31 +01:00
Merge branch 'tor-gitlab/mr/126'
This commit is contained in:
commit
1089ac6f22
3
changes/ticket40101
Normal file
3
changes/ticket40101
Normal file
@ -0,0 +1,3 @@
|
||||
o Documentation:
|
||||
- Replace URLs from our old bugtracker so that they refer to the
|
||||
new bugtracker and wiki. Closes ticket 40101.
|
@ -156,7 +156,7 @@ it).
|
||||
|
||||
This document focuses primarily on the circuit padding framework's cover
|
||||
traffic features, and will only briefly touch on the potential obfuscation and
|
||||
application layer coupling points of the framework. Explicit layer coupling
|
||||
application layer coupling points of the framework. Explicit layer coupling
|
||||
points can be created by adding either new [machine application
|
||||
events](#62-machine-application-events) or new [internal machine
|
||||
events](#63-internal-machine-events) to the circuit padding framework, so that
|
||||
@ -178,7 +178,7 @@ Most importantly: this framing allows cover traffic defenses to be modeled as
|
||||
an optimization problem search space, expressed as fields of a C structure
|
||||
(which is simultaneously a compact opaque bitstring as well as a symbolic
|
||||
vector in an abstract feature space). This kind of space is particularly well
|
||||
suited to search by gradient descent, GAs, and GANs.
|
||||
suited to search by gradient descent, GAs, and GANs.
|
||||
|
||||
When performing this optimization search, each padding machine should have a
|
||||
fitness function, which will allow two padding machines to be compared for
|
||||
@ -186,7 +186,7 @@ relative effectiveness. Optimization searches work best if this fitness can be
|
||||
represented as a single number, for example the total amount by which it
|
||||
reduces the [Balanced
|
||||
Accuracy](https://en.wikipedia.org/wiki/Precision_and_recall#Imbalanced_Data)
|
||||
of an adversary's classifier, divided by an amount of traffic overhead.
|
||||
of an adversary's classifier, divided by an amount of traffic overhead.
|
||||
|
||||
Before you begin the optimization phase for your defense, you should
|
||||
also carefully consider the [features and
|
||||
@ -1024,11 +1024,11 @@ would gladly accept patches that do so.
|
||||
|
||||
The following list gives an overview of these improvements, but as this
|
||||
document ages, it may become stale. The canonical list of improvements that
|
||||
researchers may find useful is tagged in our bugtracker with
|
||||
[circpad-researchers](https://trac.torproject.org/projects/tor/query?keywords=~circpad-researchers),
|
||||
researchers may find useful is labeled in our bugtracker with
|
||||
[Padding Research](https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Padding%20Research),
|
||||
and the list of improvements that are known to be necessary for some research
|
||||
areas are tagged with
|
||||
[circpad-researchers-want](https://trac.torproject.org/projects/tor/query?keywords=~circpad-researchers-want).
|
||||
areas are labeled with
|
||||
[Padding Research Requires](https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Padding%20Research%20Requires).
|
||||
|
||||
Please consult those lists for the latest status of these issues. Note that
|
||||
not all fixes will be backported to all Tor versions, so be mindful of which
|
||||
|
@ -7,7 +7,7 @@ circuit padding framework from scratch. Notes were taken as part of porting
|
||||
[Adaptive Padding Early
|
||||
(APE)](https://www.cs.kau.se/pulls/hot/thebasketcase-ape/) from basket2 to the
|
||||
circuit padding framework. The goal is just to document the process and provide
|
||||
useful pointers along the way, not create a useful machine.
|
||||
useful pointers along the way, not create a useful machine.
|
||||
|
||||
The quick and dirty plan is to:
|
||||
1. clone and compile tor
|
||||
@ -29,7 +29,7 @@ fixes that have since been merged to origin/master. If you need the newest
|
||||
framework features, you should use that master instead.
|
||||
|
||||
```console
|
||||
$ sh autogen.sh
|
||||
$ sh autogen.sh
|
||||
$ ./configure
|
||||
$ make
|
||||
```
|
||||
@ -73,7 +73,7 @@ We have one more step left before we move on the machine: configure TB to always
|
||||
use our middle relay. Edit `Browser/TorBrowser/Data/Tor/torrc` and set
|
||||
`MiddleNodes <fingerprint>`, where `<fingerprint>` is the fingerprint of the
|
||||
relay. Start TB, visit a website, and manually confirm that the middle is used
|
||||
by looking at the circuit display.
|
||||
by looking at the circuit display.
|
||||
|
||||
## Add a bare-bones APE padding machine
|
||||
|
||||
@ -89,10 +89,10 @@ might be broken in the future, just search for the headings):
|
||||
[circuitpadding_machines.h](https://gitweb.torproject.org/tor.git/tree/src/core/or/circuitpadding_machines.h).
|
||||
|
||||
Please consult the above links for details. Moving forward, the focus is to
|
||||
describe what was done, not necessarily explaining all the details why.
|
||||
describe what was done, not necessarily explaining all the details why.
|
||||
|
||||
Since we plan to make changes to tor, create a new branch `git checkout -b
|
||||
circuit-padding-ape-machine tor-0.4.1.5`.
|
||||
circuit-padding-ape-machine tor-0.4.1.5`.
|
||||
|
||||
We start with declaring two functions, one for the machine at the client and one
|
||||
at the relay, in `circuitpadding_machines.h`:
|
||||
@ -107,8 +107,8 @@ The definitions go into `circuitpadding_machines.c`:
|
||||
```c
|
||||
/**************** Adaptive Padding Early (APE) machine ****************/
|
||||
|
||||
/**
|
||||
* Create a relay-side padding machine based on the APE design.
|
||||
/**
|
||||
* Create a relay-side padding machine based on the APE design.
|
||||
*/
|
||||
void
|
||||
circpad_machine_relay_wf_ape(smartlist_t *machines_sl)
|
||||
@ -137,14 +137,14 @@ circpad_machine_relay_wf_ape(smartlist_t *machines_sl)
|
||||
// register the machine
|
||||
relay_machine->machine_num = smartlist_len(machines_sl);
|
||||
circpad_register_padding_machine(relay_machine, machines_sl);
|
||||
|
||||
|
||||
log_info(LD_CIRC,
|
||||
"Registered relay WF APE padding machine (%u)",
|
||||
relay_machine->machine_num);
|
||||
}
|
||||
|
||||
/**
|
||||
* Create a client-side padding machine based on the APE design.
|
||||
/**
|
||||
* Create a client-side padding machine based on the APE design.
|
||||
*/
|
||||
void
|
||||
circpad_machine_client_wf_ape(smartlist_t *machines_sl)
|
||||
@ -191,13 +191,13 @@ circpad_machine_client_wf_ape(origin_padding_machines);
|
||||
circpad_machine_relay_wf_ape(relay_padding_machines);
|
||||
```
|
||||
|
||||
We run `make` to get a new `tor` binary and copy it to our local TB.
|
||||
We run `make` to get a new `tor` binary and copy it to our local TB.
|
||||
|
||||
## Run the machine
|
||||
|
||||
To be able
|
||||
to view circuit info events in the console as we launch TB, we add `Log
|
||||
[circ]info notice stdout` to `torrc` of TB.
|
||||
[circ]info notice stdout` to `torrc` of TB.
|
||||
|
||||
Running TB to visit example.com we first find in the log:
|
||||
|
||||
@ -224,13 +224,13 @@ Aug 30 18:36:55.000 [info] circpad_handle_padding_negotiated(): Middle node did
|
||||
We see that our middle support padding (since we upgraded to tor-0.4.1.5), that
|
||||
we attempt to negotiate, our machine starts on the client, transitions to the
|
||||
end state, and is freed. The last line shows that the middle doesn't have a
|
||||
padding machine that can run.
|
||||
padding machine that can run.
|
||||
|
||||
Next, we follow the same steps as earlier and replace the modified `tor` at our
|
||||
middle relay. We don't update the logging there to avoid logging on the info
|
||||
level on the live network. Looking at the client log again we see that
|
||||
negotiation works as before except for the last line: it's missing, so the
|
||||
machine is running at the middle as well.
|
||||
machine is running at the middle as well.
|
||||
|
||||
## Implementing the APE state machine
|
||||
|
||||
@ -239,14 +239,14 @@ more machines (for the receive portion of WTFP-PAD, beyond AP), and pick
|
||||
reasonable parameters for the distributions (I completely winged it now, as when
|
||||
implementing APE). The [circuit-padding-ape-machine
|
||||
branch](https://github.com/pylls/tor/tree/circuit-padding-ape-machine) contains
|
||||
the commits for the full machines with plenty of comments.
|
||||
the commits for the full machines with plenty of comments.
|
||||
|
||||
Some comments on the process:
|
||||
|
||||
- `tor-0.4.1.5` does not support two machines on the same circuit, the following
|
||||
fix has to be made: https://trac.torproject.org/projects/tor/ticket/31111 .
|
||||
- `tor-0.4.1.5` did not support two machines on the same circuit, the following
|
||||
fix had to be made: https://bugs.torproject.org/tpo/core/tor/31111 .
|
||||
The good news is that everything else seems to work after the small change in
|
||||
the fix.
|
||||
the fix.
|
||||
- APE randomizes its distributions. Currently, this can only be done during
|
||||
start of `tor`. This makes sense in the censorship circumvention setting
|
||||
(`obfs4`), less so for WF defenses: further randomizing each circuit is likely
|
||||
|
@ -130,4 +130,4 @@ $ src/test/fuzz/fuzz-http --debug < /path/to/test.case
|
||||
Please report any issues discovered using the process in Tor's security issue
|
||||
policy:
|
||||
|
||||
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerDevMeeting/Notes/SecurityIssuePolicy
|
||||
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPolicy
|
||||
|
@ -71,10 +71,11 @@ Once you've reached this point, here's what you need to know.
|
||||
Many people have gotten started by looking for an area where they
|
||||
personally felt Tor was underperforming, and investigating ways to
|
||||
fix it. If you're looking for ideas, you can head to
|
||||
[trac](https://trac.torproject.org) our bug tracking tool and look for
|
||||
tickets that have received the "easy" tag: these are ones that developers
|
||||
[gitlab](https://gitlab.torproject.org) our bug tracking tool and look for
|
||||
tickets that have received the "First Contribution" label: these are ones
|
||||
that developers
|
||||
think would be pretty simple for a new person to work on. For a bigger
|
||||
challenge, you might want to look for tickets with the "lorax"
|
||||
challenge, you might want to look for tickets with the "Project Ideas"
|
||||
keyword: these are tickets that the developers think might be a
|
||||
good idea to build, but which we have no time to work on any time
|
||||
soon.
|
||||
@ -140,10 +141,10 @@ Once you've reached this point, here's what you need to know.
|
||||
8. Submitting your patch
|
||||
|
||||
We review patches through tickets on our bugtracker at
|
||||
[trac](https://trac.torproject.org). You can either upload your patches there, or
|
||||
[gitlab](https://gitlab.torproject.org). You can either upload your patches there, or
|
||||
put them at a public git repository somewhere we can fetch them
|
||||
(like gitlab, github or bitbucket) and then paste a link on the appropriate
|
||||
trac ticket.
|
||||
ticket.
|
||||
|
||||
Once your patches are available, write a short explanation of what
|
||||
you've done on trac, and then change the status of the ticket to
|
||||
|
@ -215,7 +215,7 @@ $ git push origin tag tor-0.4.x.y-<status>
|
||||
can vary.
|
||||
|
||||
For templates to use when announcing, see:
|
||||
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/AnnouncementTemplates
|
||||
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/AnnouncementTemplates
|
||||
|
||||
## V. Aftermath and cleanup
|
||||
|
||||
|
15
doc/TUNING
15
doc/TUNING
@ -1,13 +1,13 @@
|
||||
Most operating systems limit an amount of TCP sockets that can be used
|
||||
Most operating systems limit an amount of TCP sockets that can be used
|
||||
simultaneously. It is possible for a busy Tor relay to run into these
|
||||
limits, thus being unable to fully utilize the bandwidth resources it
|
||||
limits, thus being unable to fully utilize the bandwidth resources it
|
||||
has at its disposal. Following system-specific tips might be helpful
|
||||
to alleviate the aforementioned problem.
|
||||
|
||||
Linux
|
||||
-----
|
||||
|
||||
Use 'ulimit -n' to raise an allowed number of file descriptors to be
|
||||
Use 'ulimit -n' to raise an allowed number of file descriptors to be
|
||||
opened on your host at the same time.
|
||||
|
||||
FreeBSD
|
||||
@ -17,7 +17,7 @@ Tune the followind sysctl(8) variables:
|
||||
* kern.maxfiles - maximum allowed file descriptors (for entire system)
|
||||
* kern.maxfilesperproc - maximum file descriptors one process is allowed
|
||||
to use
|
||||
* kern.ipc.maxsockets - overall maximum numbers of sockets for entire
|
||||
* kern.ipc.maxsockets - overall maximum numbers of sockets for entire
|
||||
system
|
||||
* kern.ipc.somaxconn - size of listen queue for incoming TCP connections
|
||||
for entire system
|
||||
@ -31,8 +31,8 @@ Mac OS X
|
||||
|
||||
Since Mac OS X is BSD-based system, most of the above hold for OS X as well.
|
||||
However, launchd(8) is known to modify kern.maxfiles and kern.maxfilesperproc
|
||||
when it launches tor service (see launchd.plist(5) manpage). Also,
|
||||
kern.ipc.maxsockets is determined dynamically by the system and thus is
|
||||
when it launches tor service (see launchd.plist(5) manpage). Also,
|
||||
kern.ipc.maxsockets is determined dynamically by the system and thus is
|
||||
read-only on OS X.
|
||||
|
||||
OpenBSD
|
||||
@ -79,8 +79,7 @@ Disclaimer
|
||||
|
||||
Do note that this document is a draft and above information may be
|
||||
technically incorrect and/or incomplete. If so, please open a ticket
|
||||
on https://trac.torproject.org or post to tor-relays mailing list.
|
||||
on https://gitlab.torproject.org or post to tor-relays mailing list.
|
||||
|
||||
Are you running a busy Tor relay? Let us know how you are solving
|
||||
the out-of-sockets problem on your system.
|
||||
|
||||
|
@ -211,9 +211,9 @@ backslash character (\) before the end of the line. Comments can be used in
|
||||
such multiline entries, but they must start at the beginning of a line.
|
||||
|
||||
Configuration options can be imported from files or folders using the %include
|
||||
option with the value being a path. This path can have wildcards. Wildcards are
|
||||
expanded first, then sorted using lexical order. Then, for each matching file or
|
||||
folder, the following rules are followed: if the path is a file, the options from
|
||||
option with the value being a path. This path can have wildcards. Wildcards are
|
||||
expanded first, then sorted using lexical order. Then, for each matching file or
|
||||
folder, the following rules are followed: if the path is a file, the options from
|
||||
the file will be parsed as if they were written where the %include option is. If
|
||||
the path is a folder, all files on that folder will be parsed following lexical
|
||||
order. Files starting with a dot are ignored. Files in subfolders are ignored.
|
||||
@ -3854,7 +3854,7 @@ https://spec.torproject.org. See also **torsocks**(1) and **torify**(1).
|
||||
== BUGS
|
||||
|
||||
Because Tor is still under development, there may be plenty of bugs. Please
|
||||
report them at https://trac.torproject.org/.
|
||||
report them at https://bugs.torproject.org/.
|
||||
|
||||
== AUTHORS
|
||||
|
||||
|
@ -2,5 +2,4 @@
|
||||
@brief app/config: Top-level configuration code
|
||||
|
||||
Refactoring this module is a work in progress, see
|
||||
[ticket 29211](https://trac.torproject.org/projects/tor/ticket/29211).
|
||||
|
||||
[ticket 29211](https://bugs.torproject.org/tpo/core/tor/29211)
|
||||
|
@ -3592,7 +3592,7 @@ options_validate_cb(const void *old_options_, void *options_, char **msg)
|
||||
"configured. This is bad because it's very easy to locate your "
|
||||
"entry guard which can then lead to the deanonymization of your "
|
||||
"hidden service -- for more details, see "
|
||||
"https://trac.torproject.org/projects/tor/ticket/14917. "
|
||||
"https://bugs.torproject.org/tpo/core/tor/14917. "
|
||||
"For this reason, the use of one EntryNodes with an hidden "
|
||||
"service is prohibited until a better solution is found.");
|
||||
return -1;
|
||||
@ -3609,7 +3609,7 @@ options_validate_cb(const void *old_options_, void *options_, char **msg)
|
||||
"be harmful to the service anonymity. Because of this, we "
|
||||
"recommend you either don't do that or make sure you know what "
|
||||
"you are doing. For more details, please look at "
|
||||
"https://trac.torproject.org/projects/tor/ticket/21155.");
|
||||
"https://bugs.torproject.org/tpo/core/tor/21155.");
|
||||
}
|
||||
|
||||
/* Single Onion Services: non-anonymous hidden services */
|
||||
|
@ -2148,7 +2148,7 @@ count_acceptable_nodes, (const smartlist_t *nodes, int direct))
|
||||
* The alternative is building the circuit in reverse. Reverse calls to
|
||||
* onion_extend_cpath() (ie: select outer hops first) would then have the
|
||||
* property that you don't gain information about inner hops by observing
|
||||
* outer ones. See https://trac.torproject.org/projects/tor/ticket/24487
|
||||
* outer ones. See https://bugs.torproject.org/tpo/core/tor/24487
|
||||
* for this.
|
||||
*
|
||||
* (Note further that we still exclude the exit to prevent A - B - A
|
||||
|
@ -2144,7 +2144,7 @@ circuit_mark_all_dirty_circs_as_unusable(void)
|
||||
* This function is in the critical path of circuit_mark_for_close().
|
||||
* It must be (and is) O(1)!
|
||||
*
|
||||
* See https://trac.torproject.org/projects/tor/ticket/23512.
|
||||
* See https://bugs.torproject.org/tpo/core/tor/23512
|
||||
*/
|
||||
void
|
||||
circuit_synchronize_written_or_bandwidth(const circuit_t *c,
|
||||
|
@ -1037,7 +1037,7 @@ options_validate_relay_mode(const or_options_t *old_options,
|
||||
"Tor is currently configured as a relay and a hidden service. "
|
||||
"That's not very secure: you should probably run your hidden service "
|
||||
"in a separate Tor process, at least -- see "
|
||||
"https://trac.torproject.org/8742");
|
||||
"https://bugs.torproject.org/tpo/core/tor/8742.");
|
||||
|
||||
if (options->BridgeRelay && options->DirPort_set) {
|
||||
log_warn(LD_CONFIG, "Can't set a DirPort on a bridge relay; disabling "
|
||||
|
@ -176,7 +176,7 @@ routerinfo_err_is_transient(int err)
|
||||
/**
|
||||
* For simplicity, we consider all errors other than
|
||||
* "not a server" transient - see discussion on
|
||||
* https://trac.torproject.org/projects/tor/ticket/27034
|
||||
* https://bugs.torproject.org/tpo/core/tor/27034.
|
||||
*/
|
||||
return err != TOR_ROUTERINFO_ERROR_NOT_A_SERVER;
|
||||
}
|
||||
|
@ -42,7 +42,7 @@ static inline int strcasecmp(const char *a, const char *b) {
|
||||
* (If --enable-fragile-hardening is passed to configure, we use the hardened
|
||||
* variants, which do not suffer from this issue.)
|
||||
*
|
||||
* See https://trac.torproject.org/projects/tor/ticket/15205
|
||||
* See https://bugs.torproject.org/tpo/core/tor/15205.
|
||||
*/
|
||||
#undef strlcat
|
||||
#undef strlcpy
|
||||
|
@ -1013,7 +1013,7 @@ test_options_validate__relay_with_hidden_services(void *ignored)
|
||||
"Tor is currently configured as a relay and a hidden service. "
|
||||
"That's not very secure: you should probably run your hidden servi"
|
||||
"ce in a separate Tor process, at least -- see "
|
||||
"https://trac.torproject.org/8742\n");
|
||||
"https://bugs.torproject.org/tpo/core/tor/8742.\n");
|
||||
|
||||
done:
|
||||
teardown_capture_of_logs();
|
||||
|
Loading…
Reference in New Issue
Block a user