diff options
| -rw-r--r-- | changes/bug40400 | 2 | ||||
| -rw-r--r-- | changes/bug40400_part2 | 5 | ||||
| -rw-r--r-- | changes/bug40465 | 3 | ||||
| -rw-r--r-- | changes/ticket40480 | 3 | ||||
| -rw-r--r-- | changes/ticket40485 | 3 | ||||
| -rw-r--r-- | doc/man/tor.1.txt | 100 | ||||
| -rwxr-xr-x | scripts/ci/ci-driver.sh | 2 | ||||
| -rw-r--r-- | src/feature/dirauth/process_descs.c | 8 | ||||
| -rw-r--r-- | src/feature/rend/rendmid.c | 6 | ||||
| -rw-r--r-- | src/lib/sandbox/sandbox.c | 9 | ||||
| -rw-r--r-- | src/test/test_process_descs.c | 14 |
11 files changed, 113 insertions, 42 deletions
diff --git a/changes/bug40400 b/changes/bug40400 index 2ac5cf5dce..47bb1e6a1e 100644 --- a/changes/bug40400 +++ b/changes/bug40400 @@ -3,4 +3,4 @@ instead log it at DEBUG. In every case where we would want to log this as a protocol warning, we are already logging another warning from inside circuit_receive_relay_cell. Fixes part of bug 40400; - bugfix on 0.1.1.9. + bugfix on 0.1.1.9-alpha. diff --git a/changes/bug40400_part2 b/changes/bug40400_part2 new file mode 100644 index 0000000000..9b834d5ea1 --- /dev/null +++ b/changes/bug40400_part2 @@ -0,0 +1,5 @@ + o Minor bugfixes (usability): + - Do not log "RENDEZVOUS1 cell with unrecognized rendezvous cookie" + at LOG_PROTOCOL_WARN; instead log it at DEBUG. This warning can happen + naturally if a client gives up on a rendezvous circuit after sending + INTRODUCE1. Fixes part of bug 40400; bugfix on 0.1.1.13-alpha. diff --git a/changes/bug40465 b/changes/bug40465 new file mode 100644 index 0000000000..d4d225c62e --- /dev/null +++ b/changes/bug40465 @@ -0,0 +1,3 @@ + o Minor bugfixes (compilation): + - Fix compilation error when __NR_time is not defined. Fixes bug + 40465; bugfix on 0.2.5.5-alpha. Patch by Daniel Pinto. diff --git a/changes/ticket40480 b/changes/ticket40480 new file mode 100644 index 0000000000..525e848a1f --- /dev/null +++ b/changes/ticket40480 @@ -0,0 +1,3 @@ + o Minor feature (authority, relay): + - Reject End-Of-Life relays running version 0.4.2.x, 0.4.3.x, 0.4.4.x and + 0.4.5 alphas and rc. Closes ticket 40480. diff --git a/changes/ticket40485 b/changes/ticket40485 new file mode 100644 index 0000000000..849ee0719f --- /dev/null +++ b/changes/ticket40485 @@ -0,0 +1,3 @@ + o Testing (CI, chutney): + - Bump the data size that chutney transmit to 5MB in order to trigger flow + control and congestion window code. Closes ticket 40485. diff --git a/doc/man/tor.1.txt b/doc/man/tor.1.txt index 551ead7533..150c3715f3 100644 --- a/doc/man/tor.1.txt +++ b/doc/man/tor.1.txt @@ -2833,11 +2833,15 @@ details.) == DENIAL OF SERVICE MITIGATION OPTIONS -Tor has three built-in mitigation options that can be individually -enabled/disabled and fine-tuned, but by default Tor directory authorities will -define reasonable values for relays and no explicit configuration is required -to make use of these protections. The mitigations take place at relays, -and are as follows: +Tor has a series of built-in denial of service mitigation options that can be +individually enabled/disabled and fine-tuned, but by default Tor directory +authorities will define reasonable values for the network and no explicit +configuration is required to make use of these protections. + +The following is a series of configuration options for relays and then options +for onion services and how they work. + +The mitigations take place at relays, and are as follows: 1. If a single client address makes too many concurrent connections (this is configurable via DoSConnectionMaxConcurrentCount), hang up on further @@ -2988,6 +2992,68 @@ Denial of Service mitigation subsystem described above. (Default: auto) +As for onion services, only one possible mitigation exists. It was intended to +protect the network first and thus do not help the service availability or +reachability. + +The mitigation we put in place is a rate limit of the amount of introduction +that happens at the introduction point for a service. In other words, it rates +limit the number of clients that are attempting to reach the service at the +introduction point instead of at the service itself. + +The following options are per onion service: + +[[HiddenServiceEnableIntroDoSDefense]] **HiddenServiceEnableIntroDoSDefense** **0**|**1**:: + Enable DoS defense at the intropoint level. When this is enabled, the + rate and burst parameter (see below) will be sent to the intro point which + will then use them to apply rate limiting for introduction request to this + service. + + + The introduction point honors the consensus parameters except if this is + specifically set by the service operator using this option. The service + never looks at the consensus parameters in order to enable or disable this + defense. (Default: 0) + +//Out of order because it logically belongs after HiddenServiceEnableIntroDoSDefense. +[[HiddenServiceEnableIntroDoSBurstPerSec]] **HiddenServiceEnableIntroDoSBurstPerSec** __NUM__:: + The allowed client introduction burst per second at the introduction + point. If this option is 0, it is considered infinite and thus if + **HiddenServiceEnableIntroDoSDefense** is set, it then effectively + disables the defenses. (Default: 200) + +[[HiddenServiceEnableIntroDoSRatePerSec]] **HiddenServiceEnableIntroDoSRatePerSec** __NUM__:: + The allowed client introduction rate per second at the introduction + point. If this option is 0, it is considered infinite and thus if + **HiddenServiceEnableIntroDoSDefense** is set, it then effectively + disables the defenses. (Default: 25) + +The rate is the maximum number of clients a service will ask its introduction +points to allow every seconds. And the burst is a parameter that allows that +many within one second. + +For example, the default values of 25 and 200 respectively means that for every +introduction points a service has (default 3 but can be configured with +**HiddenServiceNumIntroductionPoints**), 25 clients per seconds will be allowed +to reach the service and 200 at most within 1 second as a burst. This means +that if 200 clients are seen within 1 second, it will take 8 seconds (200/25) +for another client to be able to be allowed to introduce due to the rate of 25 +per second. + +This might be too much for your use case or not, fine tuning these values is +hard and are likely different for each service operator. + +Why is this not helping reachability of the service? Because the defenses are +at the introduction point, an attacker can easily flood all introduction point +rendering the service unavailable due to no client being able to pass through. +But, the service itself is not overwhelmed with connetions allowing it to +function properly for the few clients that were able to go through or other any +services running on the same tor instance. + +The bottom line is that this protects the network by preventing an onion +service to flood the network with new rendezvous circuits that is reducing load +on the network. + + == DIRECTORY AUTHORITY SERVER OPTIONS The following options enable operation as a directory authority, and @@ -3266,30 +3332,6 @@ The next section describes the per service options that can only be set only owner is able to read the hidden service directory. (Default: 0) Has no effect on Windows. -[[HiddenServiceEnableIntroDoSDefense]] **HiddenServiceEnableIntroDoSDefense** **0**|**1**:: - Enable DoS defense at the intropoint level. When this is enabled, the - rate and burst parameter (see below) will be sent to the intro point which - will then use them to apply rate limiting for introduction request to this - service. - + - The introduction point honors the consensus parameters except if this is - specifically set by the service operator using this option. The service - never looks at the consensus parameters in order to enable or disable this - defense. (Default: 0) - -//Out of order because it logically belongs after HiddenServiceEnableIntroDoSDefense. -[[HiddenServiceEnableIntroDoSBurstPerSec]] **HiddenServiceEnableIntroDoSBurstPerSec** __NUM__:: - The allowed client introduction burst per second at the introduction - point. If this option is 0, it is considered infinite and thus if - **HiddenServiceEnableIntroDoSDefense** is set, it then effectively - disables the defenses. (Default: 200) - -[[HiddenServiceEnableIntroDoSRatePerSec]] **HiddenServiceEnableIntroDoSRatePerSec** __NUM__:: - The allowed client introduction rate per second at the introduction - point. If this option is 0, it is considered infinite and thus if - **HiddenServiceEnableIntroDoSDefense** is set, it then effectively - disables the defenses. (Default: 25) - [[HiddenServiceExportCircuitID]] **HiddenServiceExportCircuitID** __protocol__:: The onion service will use the given protocol to expose the global circuit identifier of each inbound client circuit. The only diff --git a/scripts/ci/ci-driver.sh b/scripts/ci/ci-driver.sh index d0b563a09b..ff4881dd8e 100755 --- a/scripts/ci/ci-driver.sh +++ b/scripts/ci/ci-driver.sh @@ -449,6 +449,8 @@ if [[ "${CHUTNEY}" = "yes" ]]; then start_section "Chutney" export CHUTNEY_TOR_SANDBOX=0 export CHUTNEY_ALLOW_FAILURES=2 + # Send 5MB for every verify check. + export CHUTNEY_DATA_BYTES=5000000 if runcmd make "${CHUTNEY_MAKE_TARGET}"; then hooray "Chutney tests have succeeded" else diff --git a/src/feature/dirauth/process_descs.c b/src/feature/dirauth/process_descs.c index eca987b8b5..5ea9d16850 100644 --- a/src/feature/dirauth/process_descs.c +++ b/src/feature/dirauth/process_descs.c @@ -412,11 +412,11 @@ dirserv_rejects_tor_version(const char *platform, return true; } - /* Series between Tor 0.3.6 and 0.4.1 inclusive are unsupported. Reject - * them. 0.3.6.0-alpha-dev only existed for a short time, before it was - * renamed to 0.4.0.0-alpha-dev. */ + /* Series between Tor 0.3.6.x and 0.4.5.5-rc inclusive are unsupported. + * Reject them. 0.3.6.0-alpha-dev only existed for a short time, before it + * was renamed to 0.4.0.0-alpha-dev. */ if (tor_version_as_new_as(platform,"0.3.6.0-alpha-dev") && - !tor_version_as_new_as(platform,"0.4.2.1-alpha")) { + !tor_version_as_new_as(platform,"0.4.5.6")) { if (msg) { *msg = please_upgrade_string; } diff --git a/src/feature/rend/rendmid.c b/src/feature/rend/rendmid.c index df838aa527..8f6a45dfef 100644 --- a/src/feature/rend/rendmid.c +++ b/src/feature/rend/rendmid.c @@ -131,7 +131,11 @@ rend_mid_rendezvous(or_circuit_t *circ, const uint8_t *request, rend_circ = hs_circuitmap_get_rend_circ_relay_side(request); if (!rend_circ) { - log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL, + /* Once this was a LOG_PROTOCOL_WARN, but it can happen naturally if a + * client gives up on a rendezvous circuit after sending INTRODUCE1, but + * before the onion service sends the RENDEZVOUS1 cell. + */ + log_fn(LOG_DEBUG, LD_PROTOCOL, "Rejecting RENDEZVOUS1 cell with unrecognized rendezvous cookie %s.", hexid); reason = END_CIRC_REASON_TORPROTOCOL; diff --git a/src/lib/sandbox/sandbox.c b/src/lib/sandbox/sandbox.c index a78e4a7ac7..aed7e3706f 100644 --- a/src/lib/sandbox/sandbox.c +++ b/src/lib/sandbox/sandbox.c @@ -346,6 +346,7 @@ sb_rt_sigaction(scmp_filter_ctx ctx, sandbox_cfg_t *filter) return rc; } +#ifdef __NR_time /** * Function responsible for setting up the time syscall for * the seccomp filter sandbox. @@ -354,13 +355,11 @@ static int sb_time(scmp_filter_ctx ctx, sandbox_cfg_t *filter) { (void) filter; -#ifdef __NR_time + return seccomp_rule_add_1(ctx, SCMP_ACT_ALLOW, SCMP_SYS(time), SCMP_CMP(0, SCMP_CMP_EQ, 0)); -#else - return 0; -#endif /* defined(__NR_time) */ } +#endif /* defined(__NR_time) */ /** * Function responsible for setting up the accept4 syscall for @@ -1264,7 +1263,9 @@ sb_kill(scmp_filter_ctx ctx, sandbox_cfg_t *filter) static sandbox_filter_func_t filter_func[] = { sb_rt_sigaction, sb_rt_sigprocmask, +#ifdef __NR_time sb_time, +#endif sb_accept4, #ifdef __NR_mmap2 sb_mmap2, diff --git a/src/test/test_process_descs.c b/src/test/test_process_descs.c index fa2657f6c2..5503fc69ee 100644 --- a/src/test/test_process_descs.c +++ b/src/test/test_process_descs.c @@ -39,12 +39,20 @@ test_process_descs_versions(void *arg) { "Tor 0.4.1.1-alpha", true }, { "Tor 0.4.1.4-rc", true }, { "Tor 0.4.1.5", true }, + { "Tor 0.4.2.1-alpha", true }, + { "Tor 0.4.2.4-rc", true }, + { "Tor 0.4.2.5", true }, + { "Tor 0.4.3.0-alpha-dev", true }, + { "Tor 0.4.3.8", true }, + { "Tor 0.4.4.9", true }, + { "Tor 0.4.5.5-rc", true }, // new enough to be supported { "Tor 0.3.5.7", false }, { "Tor 0.3.5.8", false }, - { "Tor 0.4.2.1-alpha", false }, - { "Tor 0.4.2.4-rc", false }, - { "Tor 0.4.3.0-alpha-dev", false }, + { "Tor 0.4.5.6", false }, + { "Tor 0.4.6.0-alpha-dev", false }, + { "Tor 0.4.6.5", false }, + { "Tor 0.4.7.0-alpha-dev", false }, // Very far in the future { "Tor 100.100.1.5", false }, }; |