tor-commits August 2013

tor-commits@lists.torproject.org

19 participants
1224 discussions

[tor/maint-0.2.4] Add a 30-day maximum on user-supplied MaxCircuitDirtiness
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit af7970b6bcc8e546cf15e943f1bec749cce18eed Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Aug 21 11:35:00 2013 -0400 Add a 30-day maximum on user-supplied MaxCircuitDirtiness Fix for bug 9543. --- changes/bug9543 | 4 ++++ src/or/config.c | 10 ++++++++++ 2 files changed, 14 insertions(+) diff --git a/changes/bug9543 b/changes/bug9543 new file mode 100644 index 0000000..753947f --- /dev/null +++ b/changes/bug9543 @@ -0,0 +1,4 @@ + o Minor bugfixes: + - Avoid overflows when the user sets MaxCircuitDirtiness to a + ridiculously high value, by imposing a (ridiculously high) 30-day + maximum on MaxCircuitDirtiness. diff --git a/src/or/config.c b/src/or/config.c index 72ceea3..793fd55 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -2266,6 +2266,10 @@ compute_publishserverdescriptor(or_options_t *options) * will generate too many circuits and potentially overload the network. */ #define MIN_MAX_CIRCUIT_DIRTINESS 10 +/** Highest allowable value for MaxCircuitDirtiness: prevents time_t + * overflows. */ +#define MAX_MAX_CIRCUIT_DIRTINESS (30*24*60*60) + /** Lowest allowable value for CircuitStreamTimeout; if this is too low, Tor * will generate too many circuits and potentially overload the network. */ #define MIN_CIRCUIT_STREAM_TIMEOUT 10 @@ -2786,6 +2790,12 @@ options_validate(or_options_t *old_options, or_options_t *options, options->MaxCircuitDirtiness = MIN_MAX_CIRCUIT_DIRTINESS; } + if (options->MaxCircuitDirtiness > MAX_MAX_CIRCUIT_DIRTINESS) { + log_warn(LD_CONFIG, "MaxCircuitDirtiness option is too high; " + "setting to %d days.", MAX_MAX_CIRCUIT_DIRTINESS/86400); + options->MaxCircuitDirtiness = MAX_MAX_CIRCUIT_DIRTINESS; + } + if (options->CircuitStreamTimeout && options->CircuitStreamTimeout < MIN_CIRCUIT_STREAM_TIMEOUT) { log_warn(LD_CONFIG, "CircuitStreamTimeout option is too short; "

1 0

[tor/maint-0.2.4] Merge remote-tracking branch 'public/bug9543' into maint-0.2.4
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit 3727a978b8ca5015c1d684a0151002cd70ab3426 Merge: 43f187e af7970b Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Aug 25 00:29:06 2013 -0400 Merge remote-tracking branch 'public/bug9543' into maint-0.2.4 changes/bug9543 | 4 ++++ src/or/config.c | 10 ++++++++++ 2 files changed, 14 insertions(+)

1 0

[tor/maint-0.2.4] Merge remote-tracking branch 'public/bug9546_023_v2' into maint-0.2.3
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit 8611195a005ed1624bdea0632404a8c00bb19586 Merge: 8bf2892 940cef3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Aug 25 00:32:27 2013 -0400 Merge remote-tracking branch 'public/bug9546_023_v2' into maint-0.2.3 changes/bug9546 | 11 +++++++++++ src/or/command.c | 14 ++++++++++++-- src/or/connection_or.c | 9 ++++++++- src/or/or.h | 3 +++ 4 files changed, 34 insertions(+), 3 deletions(-)

1 0

[tor/maint-0.2.4] Merge remote-tracking branch 'public/bug9366' into maint-0.2.4
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit 1ee1c8fb4fc2e4855dba4387a58162656b5b9f0f Merge: 3727a97 b9f9110 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Aug 25 00:29:49 2013 -0400 Merge remote-tracking branch 'public/bug9366' into maint-0.2.4 changes/bug9366 | 4 ++++ src/or/config.c | 7 +++++++ 2 files changed, 11 insertions(+)

1 0

[tor/maint-0.2.4] Merge remote-tracking branch 'origin/maint-0.2.3' into maint-0.2.4
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit a5610cfa64189db693dbad3efaa973d6720c42fe Merge: 4107ddd 8611195 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Aug 25 00:33:10 2013 -0400 Merge remote-tracking branch 'origin/maint-0.2.3' into maint-0.2.4 (Using "ours" strategy to avoid taking 9546 fix in 0.2.3; we just merged our own into 0.2.4)

1 0

[tor/maint-0.2.4] Merge remote-tracking branch 'public/bug9546_v2' into maint-0.2.4
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit 4107ddd003c6c0f1271ad73a40114350f600dbec Merge: 1ee1c8f cbc53a2 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Aug 25 00:31:51 2013 -0400 Merge remote-tracking branch 'public/bug9546_v2' into maint-0.2.4 changes/bug9546 | 11 +++++++++++ src/or/channeltls.c | 14 ++++++++++++-- src/or/connection_or.c | 9 ++++++++- src/or/or.h | 3 +++ 4 files changed, 34 insertions(+), 3 deletions(-)

1 0

[tor/maint-0.2.4] Send NETINFO on receiving a NETINFO if we have not yet sent one.
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit 1bb4a4f9bdf24706a459e4aefb2b0fb75622f7ac Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Aug 20 14:52:56 2013 -0400 Send NETINFO on receiving a NETINFO if we have not yet sent one. Relays previously, when initiating a connection, would only send a NETINFO after sending an AUTHENTICATE. But bridges, when receiving a connection, would never send AUTH_CHALLENGE. So relays wouldn't AUTHENTICATE, and wouldn't NETINFO, and then bridges would be surprised to be receiving CREATE cells on a non-open circuit. Fixes bug 9546. --- changes/bug9546 | 5 +++++ src/or/channeltls.c | 10 ++++++++++ src/or/connection_or.c | 7 +++++++ src/or/or.h | 3 +++ 4 files changed, 25 insertions(+) diff --git a/changes/bug9546 b/changes/bug9546 new file mode 100644 index 0000000..8596eac --- /dev/null +++ b/changes/bug9546 @@ -0,0 +1,5 @@ + o Major bugfixes: + + - When a relay is extending a circuit to a bridge, it needs to send a + NETINFO cell, even when the bridge hasn't sent an AUTH_CHALLENGE + cell. Fixes bug 9546; bugfix on ????. diff --git a/src/or/channeltls.c b/src/or/channeltls.c index d758d22..a7953e7 100644 --- a/src/or/channeltls.c +++ b/src/or/channeltls.c @@ -1474,6 +1474,16 @@ channel_tls_process_netinfo_cell(cell_t *cell, channel_tls_t *chan) /* XXX maybe act on my_apparent_addr, if the source is sufficiently * trustworthy. */ + if (! chan->conn->handshake_state->sent_netinfo) { + /* If we were prepared to authenticate, but we never got an AUTH_CHALLENGE + * cell, then we would not previously have sent a NETINFO cell. Do so + * now. */ + if (connection_or_send_netinfo(chan->conn) < 0) { + connection_or_close_for_error(chan->conn, 0); + return; + } + } + if (connection_or_set_state_open(chan->conn) < 0) { log_fn(LOG_PROTOCOL_WARN, LD_OR, "Got good NETINFO cell from %s:%d; but " diff --git a/src/or/connection_or.c b/src/or/connection_or.c index 3616363..31cc9c7 100644 --- a/src/or/connection_or.c +++ b/src/or/connection_or.c @@ -2042,6 +2042,12 @@ connection_or_send_netinfo(or_connection_t *conn) tor_assert(conn->handshake_state); + if (conn->handshake_state->sent_netinfo) { + log_warn(LD_BUG, "Attempted to send an extra netinfo cell on a connection " + "where we already sent one."); + return 0; + } + memset(&cell, 0, sizeof(cell_t)); cell.command = CELL_NETINFO; @@ -2083,6 +2089,7 @@ connection_or_send_netinfo(or_connection_t *conn) } conn->handshake_state->digest_sent_data = 0; + conn->handshake_state->sent_netinfo = 1; connection_or_write_cell_to_buf(&cell, conn); return 0; diff --git a/src/or/or.h b/src/or/or.h index 3dc96b9..8c6c1e3 100644 --- a/src/or/or.h +++ b/src/or/or.h @@ -1357,6 +1357,9 @@ typedef struct or_handshake_state_t { /* True iff we've received valid authentication to some identity. */ unsigned int authenticated : 1; + /* True iff we have sent a netinfo cell */ + unsigned int sent_netinfo : 1; + /** True iff we should feed outgoing cells into digest_sent and * digest_received respectively. *

1 0

[tor/maint-0.2.4] Don't allow all ORPort values to be NoAdvertise
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit b9f9110ac77876b0c8c4fda19b6bb138e60da655 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Aug 5 12:14:48 2013 -0400 Don't allow all ORPort values to be NoAdvertise Fix for bug #9366 --- changes/bug9366 | 4 ++++ src/or/config.c | 7 +++++++ 2 files changed, 11 insertions(+) diff --git a/changes/bug9366 b/changes/bug9366 new file mode 100644 index 0000000..acc919e --- /dev/null +++ b/changes/bug9366 @@ -0,0 +1,4 @@ + o Minor features (usability): + - Warn and fail if a server is configured not to advertise any + ORPorts at all. (We need *something* to put in our descriptor, or + we just won't work.) diff --git a/src/or/config.c b/src/or/config.c index 72ceea3..ef90f23 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -5509,6 +5509,13 @@ check_server_ports(const smartlist_t *ports, "listening on one."); r = -1; } + if (n_orport_listeners && !n_orport_advertised) { + log_warn(LD_CONFIG, "We are listening on an ORPort, but not advertising " + "any ORPorts. This will keep us from building a %s " + "descriptor, and make us impossible to use.", + options->BridgeRelay ? "bridge" : "router"); + r = -1; + } if (n_dirport_advertised && !n_dirport_listeners) { log_warn(LD_CONFIG, "We are advertising a DirPort, but not actually " "listening on one.");

1 0

[tor/maint-0.2.3] Send NETINFO on receiving a NETINFO if we have not yet sent one.
by nickm＠torproject.org 25 Aug '13

25 Aug '13

commit 0daa26a4732234333e67d04c9b215ff6704fa9cd Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Aug 20 14:52:56 2013 -0400 Send NETINFO on receiving a NETINFO if we have not yet sent one. (Backport to Tor 0.2.3) Relays previously, when initiating a connection, would only send a NETINFO after sending an AUTHENTICATE. But bridges, when receiving a connection, would never send AUTH_CHALLENGE. So relays wouldn't AUTHENTICATE, and wouldn't NETINFO, and then bridges would be surprised to be receiving CREATE cells on a non-open circuit. Fixes bug 9546. --- bug9546 | 5 +++++ src/or/command.c | 10 ++++++++++ src/or/connection_or.c | 7 +++++++ src/or/or.h | 3 +++ 4 files changed, 25 insertions(+) diff --git a/bug9546 b/bug9546 new file mode 100644 index 0000000..8596eac --- /dev/null +++ b/bug9546 @@ -0,0 +1,5 @@ + o Major bugfixes: + + - When a relay is extending a circuit to a bridge, it needs to send a + NETINFO cell, even when the bridge hasn't sent an AUTH_CHALLENGE + cell. Fixes bug 9546; bugfix on ????. diff --git a/src/or/command.c b/src/or/command.c index 8321e26..26e4e68 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -941,6 +941,16 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) * trustworthy. */ (void)my_apparent_addr; + if (! conn->handshake_state->sent_netinfo) { + /* If we were prepared to authenticate, but we never got an AUTH_CHALLENGE + * cell, then we would not previously have sent a NETINFO cell. Do so + * now. */ + if (connection_or_send_netinfo(conn) < 0) { + connection_mark_for_close(TO_CONN(conn)); + return; + } + } + if (connection_or_set_state_open(conn)<0) { log_fn(LOG_PROTOCOL_WARN, LD_OR, "Got good NETINFO cell from %s:%d; but " "was unable to make the OR connection become open.", diff --git a/src/or/connection_or.c b/src/or/connection_or.c index 5eecee0..56c6ed5 100644 --- a/src/or/connection_or.c +++ b/src/or/connection_or.c @@ -1975,6 +1975,12 @@ connection_or_send_netinfo(or_connection_t *conn) tor_assert(conn->handshake_state); + if (conn->handshake_state->sent_netinfo) { + log_warn(LD_BUG, "Attempted to send an extra netinfo cell on a connection " + "where we already sent one."); + return 0; + } + memset(&cell, 0, sizeof(cell_t)); cell.command = CELL_NETINFO; @@ -2009,6 +2015,7 @@ connection_or_send_netinfo(or_connection_t *conn) } conn->handshake_state->digest_sent_data = 0; + conn->handshake_state->sent_netinfo = 1; connection_or_write_cell_to_buf(&cell, conn); return 0; diff --git a/src/or/or.h b/src/or/or.h index dd95c34..b8f334e 100644 --- a/src/or/or.h +++ b/src/or/or.h @@ -1161,6 +1161,9 @@ typedef struct or_handshake_state_t { /* True iff we've received valid authentication to some identity. */ unsigned int authenticated : 1; + /* True iff we have sent a netinfo cell */ + unsigned int sent_netinfo : 1; + /** True iff we should feed outgoing cells into digest_sent and * digest_received respectively. *

1 0

[tor/maint-0.2.3] Merge remote-tracking branch 'public/bug9546_023_v2' into maint-0.2.3
by nickm＠torproject.org 25 Aug '13

25 Aug '13

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits August 2013