tor-commits September 2015

tor-commits@lists.torproject.org

15 participants
1411 discussions

[torspec/master] Add proposal for padding negotiation.
by isis＠torproject.org 25 Sep '15

25 Sep '15

commit d159f9a820a2793f402de89782446e0833795267 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Sep 9 18:11:05 2015 -0700 Add proposal for padding negotiation. This is the version initially posted to tor-dev@lists. --- proposals/xxx-padding-negotiation.txt | 392 +++++++++++++++++++++++++++++++++ 1 file changed, 392 insertions(+) diff --git a/proposals/xxx-padding-negotiation.txt b/proposals/xxx-padding-negotiation.txt new file mode 100644 index 0000000..66d8991 --- /dev/null +++ b/proposals/xxx-padding-negotiation.txt @@ -0,0 +1,392 @@ +Filename: xxx-padding-negotiation.txt +Title: Padding Negotiation +Authors: Mike Perry +Created: 01 September 2015 +Status: Draft + + +0. Overview + +This proposal aims to describe mechanisms for requesting various types +of padding from relays. + +These padding primitives are general enough to use to defend against +both website traffic fingerprinting as well as hidden service circuit +setup fingerprinting. + + +1. Motivation + +Tor already supports both link-level padding via (CELL_PADDING cell +types), as well as circuit-level padding (via RELAY_COMMAND_DROP relay +cells). + +Unfortunately, there is no way for clients to request padding from +relays, or request that relays not send them padding to conserve +bandwidth. This proposal aims to create a mechanism for clients to do +both of these. + + +2. Link-level padding + +Padding is most urgently needed to defend against a malicious or +compromised guard node. However, link-level padding is still useful to +defend against an adversary that can merely observe a Guard node +externally. Right now, the only case where link-level padding is known +to defend against any realistic attacker is for low-resolution +netflow-based attacks. + +In that scenario, the primary mechanism we need is a way for mobile +clients to tell their Guards to stop padding, or to pad less often. The +following Trunnel payloads should cover the needed parameters: + + const CELL_PADDING_COMMAND_STOP = 1; + const CELL_PADDING_COMMAND_START = 2; + + /* This command tells the relay to stop sending any periodic + CELL_PADDING cells. */ + struct cell_padding_stop { + u8 command IN [CELL_PADDING_COMMAND_STOP]; + }; + + /* This command tells the relay to alter its min and max timeout + range values, and if needed, send + struct cell_padding_start { + u8 command IN [CELL_PADDING_COMMAND_START]; + + /* Min must not be lower than the current consensus parameter + nf_ito_low. */ + u16 ito_low_ms; + + /* Max must not be lower than ito_low_ms */ + u16 ito_high_ms; + }; + +If more scenarios are discovered, future command numbers could be used +to include the end-to-end padding command payloads below, or other +defense parameterizations. + + +3. End-to-end circuit padding + +For end-to-end padding, we need two types of additional features: the +ability to schedule additional incoming cells at one or more fixed +points in the future, and the ability to schedule a statistical +distribution of arbitrary padding to overlay on top of non-padding +traffic (aka "Adaptive Padding"). + +In both cases, these messages will be sent from clients to middle nodes +using "leaky pipe" property of the 'recognized' field of RELAY cells, +allowing padding to originate from middle nodes on a circuit in a way +that is not detectable from the Guard node. + +3.1. Fixed-schedule padding message (RELAY_COMMAND_PADDING_SCHEDULE) + +The fixed schedule padding will be encoded in a +RELAY_COMMAND_PADDING_SCHEDULE cell. It specifies a set of up to 80 +fixed time points in the future to send cells. + +XXX: 80 timers is a lot to allow every client to create. We may want to +have something that checks this structure to ensure it actually +schedules no more than N in practice, until we figure out how to +optimize either libevent or timer scheduling/packet delivery. + +The RELAY_COMMAND_PADDING_SCHEDULE body is specified in Trunnel as +follows: + + struct relay_padding_schedule { + /* Number of microseconds before sending cells (cumulative) */ + u32 when_send[80]; + + /* Number of cells to send at time point sum(when_send[0..i]) */ + u16 num_cells[80]; + + /* Adaptivity: If 1, and server-originating cells arrive before the + next when_send time, then decrement the next non-zero when_send + index, so we don't send a padding cell then, too */ + u8 adaptive IN [0,1]; + }; + +To allow both high-resolution time values, and the ability to specify +timeout values far in the future, the time values are cumulative. In +other words, sending a cell with when_send = [MAX_INT, MAX_INT, MAX_INT, +0...] and num_cells = [0, 0, 100, 0...] would cause the relay to reply +with 100 cells in 3*MAX_INT microseconds from the receipt of this cell. + +3.2. Adaptive Padding message (RELAY_COMMAND_PADDING_ADAPTIVE) + +The following message is derived from the Adaptive Padding defense +specified in "Timing Attacks and Defenses"[1]. + +The message encodes either one or two state machines, each of which +contain two histograms ("Burst" and "Gap") governing their behavior. + +The "Burst" histogram specifies the delay probabilities for sending a +padding packet after the arrival of a non-padding data packet. + +The "Gap" histogram specifies the delay probabilities for sending +another padding packet after a padding packet was just sent from this +node. This self-triggering property of the "Gap" histogram allows the +construction of multi-packet padding trains using a simple statistical +distribution. + +Both "Gap" and "Burst" histograms each have a special "Infinity" bin, +which means "We have decided not to send a packet". + +Each histograms is combined with state transition information, which +allows a client to specify the types of incoming packets that cause the +state machine to decide to schedule padding cells (and/or when to cease +scheduling them). + +The histograms and the associated state machines are specified in +Trunnel as follows: + + /* These constants form a bitfield to specify the types of events + * that can cause padding to start or stop from a given state. */ + const RELAY_PADDING_TRANSITION_EVENT_INFINITY_BIN = 0; // "Always set" + const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_RECV = 1; + const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT = 2; + const RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT = 4; + const RELAY_PADDING_TRANSITION_EVENT_PADDING_RECV = 8; + + const RELAY_PADDING_HISTOGRAM_INFINITY_BIN = 50; + /* + This encodes a histogram delay distribution representing the + probability of sending a single RELAY_DROP cell after a given + delay in response to a non-padding cell. + */ + struct burst_state { + u16 histogram[51]; + u32 start_usec; + u16 max_sec; + + /* This is a bitfield that specifies which direction and types + of traffic should cause us to schedule a padding packet + (and potentially transition to the Gap state). */ + u8 transition_events; + + /* Should we remove tokens from the histogram as packets are sent? */ + u8 remove_toks IN [0,1]; + }; + + /* + This histogram encodes a delay distribution representing the + probability of sending a single additional padding packet after + sending a padding packet that originated at this hop. + */ + struct gap_state { + u16 histogram[51]; + u32 start_usec; + u16 max_sec; + + /* + Integer value to add to the "Infinity" bin after each successive + padding packet is sent. Used to create an increasing likelihood + of hitting the termination condition with each successive padding + packet. */ + u16 decay_by; + + /* This is a bitfield which specifies which direction and types + of traffic should cause us to transition back to the burst + state. */ + u8 transition_events; + + /* Should we remove tokens from the histogram as packets are sent? */ + u8 remove_toks IN [0,1]; + }; + + struct adaptive_padding_machine { + struct burst_state burst; + struct gap_state gap; + }; + + /* This is the full payload of a RELAY_COMMAND_PADDING_ADAPTIVE + cell. */ + struct relay_command_padding_adaptive { + u8 num_machines IN [1,2]; + + struct adaptive_padding_machine machines[num_machines]; + }; + +3.2.1. Histogram state machine operation + +Each of pair of histograms ("Burst" and "Gap") together form a state +machine whose transitions are governed by incoming traffic and/or +locally generated padding traffic. + +Each state machine has a Start state S, a Burst state B, and a Gap state +G. + +The state machine starts idle (state S) until it receives a packet of a +type that matches the bitmask in burst.transition_events. + +This causes it to enter burst mode (state B), in which a delay t is +sampled from the Burst histogram, and a timer is scheduled to count down +until either another matching packet arrives, or t expires. + +If a matching packet arrives before t expires, a new delay is sampled +and the process is repeated again, i.e. it remains in burst mode. + +Otherwise, a padding message is sent to the other end and the machine +switches to state G (Gap mode). In state G, the machine samples from the +Gap histogram and sends padding messages when the time it samples +expires. An infinite delay can be sampled from the histograms. When an +infinite delay is sampled while being in state G we jump back to state +B. Similarly, a transition to S occurs when we sample an infinite time +in B. + +Optionally, a transition from G to B can also occur upon receiving a +packet, as specified by gap.transition_events bitmask. + +Clients are expected to maintain their own local version of the state +machines, for reacting to their own locally generated traffic, in +addition to sending one or more state machines to the middle relay. + +The histograms that the client uses locally will likely differ from the +ones it sends to the upstream relay. + +3.2.2. Histogram decoding/representation + +Each of the histograms' fields represent a probability distribution that +is expanded into bins representing time periods a[i]..b[i] as follows: + +start_usec,max_sec initialized from appropriate histogram type. + +a[0] = start_usec; +n = RELAY_PADDING_HISTOGRAM_INFINITY_BIN; + +a[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i) +b[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i-1) + +To sample the delay time to send a padding packet, perform the +following: + + i = 0; + curr_weight = histogram[0]; + + tot_weight = sum(histogram); + bin_choice = crypto_rand_int(tot_weight); + + while (curr_weight < bin_choice) { + curr_weight += histogram[i]; + i++; + } + + if (i == RELAY_PADDING_HISTOGRAM_INFINITY_BIN) + return; // Don't send a padding packet + + // Sample uniformly between a[i] and b[i] + send_padding_packet_at = a[i] + crypto_rand_int(b[i] - a[i]); + +In this way, the bin widths are exponentially increasing in width, where +the width is set at max_sec/2^(n-i) seconds. This exponentially +increasing bin width allows the histograms to most accurately represent +small interpacket delay (where accuracy is needed), and devote less +accuracy to larger timescales (where accuracy is not as important). + +3.2.3. Token removal and refill + +If the remove_tok field is set to true for a given state's histogram, +then whenever a padding packet is sent, the corresponding histogram +bin's token count is decremented by one. + +If a non-padding packet arrives from the server before the chosen +padding timer expires, then a token is removed from the nearest +non-empty bin corresponding to the delay since the last packet was sent, +and the padding packet timer is re-sampled from the histogram. + +If the entire histogram becomes empty, it is then refilled to the +original values. + +3.2.4. Constructing the histograms + +Care must be taken when constructing the histograms themselves, since +their non-uniform widths means that the actual underlying probability +distribution needs to be both normalized for total number of tokens, as +well as the non-uniform histogram bin widths. + +Care should also be taken with interaction with the token removal rules +from Section 3.2.3. Obviously using a large number of tokens will cause +token removal to have much less of an impact upon the adaptive nature of +the padding in the face of existing traffic. + +Actual optimal histogram construction for different traffic types is +expected to be a topic for further research. + + +4. Security considerations and mitigations + +The risks from this proposal are primarily DoS/resource exhaustion, and +side channels. + +4.1. Traffic handling + +Fully client-requested padding introduces a vector for resource +amplification attacks and general network overload due to +overly-aggressive client implementations requesting too much padding. + +Current research indicates that this form of statistical padding should +be effective at overhead rates of 50-60%. This suggests that clients +that use more padding than this are likely to be overly aggressive in +their behavior. + +We recommend that three consensus parameters be used in the event that +the network is being overloaded from padding to such a degree that +padding requests should be ignored: + + * CircuitPaddingMaxRatio + - The maximum ratio of padding traffic to non-padding traffic + (expressed as a percent) to allow on a circuit before ceasing + to pad. Ex: 75 means 75 padding packets for every 100 non-padding + packets. + - Default: 100 + * CircuitPaddingLimitCount + - The number of padding cells that must be transmitted before the + ratio limit is applied. + - Default: 500 + * CircuitPaddingLimitTime + - The time period in seconds over which to count padding cells for + application of the ratio limit. + - Default: 60 + +XXX: Should we cap padding at these rates, or fully disable it once +they're crossed? + +Proposal 251 introduced extra-info accounting at relays to enable us to +measure the total overhead of both link and circuit-level padding at +various relays. + +4.2. Libevent timer exhaustion + +As mentioned in section 3.1, scheduled padding may create an excessive +number of libevent timers. Care should be taken in the implementation to +devise a way to prevent clients from sending padding requests +specifically designed to impact the ability of relays to function by +causing too many timers to be scheduled at once. + +XXX: Can we suggest any specifics here? I can imagine a few ways of +lazily scheduling timers only when they are close to their expiry time, +and other ways of minimizing the number of pending timer callbacks at a +given time, but I am not sure which would be best for libevent. + +4.3. Side channels + +In order to prevent relays from introducing side channels by requesting +padding from clients, all of these commands should only be valid in the +outgoing (from the client/OP) direction. + +Clients should perform accounting on the amount of padding that they +receive, and if it exceeds the amount that they have requested, they +alert the user of a potentially misbehaving node, and/or close the +circuit. + +Similarly, if RELAY_DROP cells arrive from the last hop of a circuit, +rather than from the expected interior node, clients should alert the +user of the possibility of that circuit endpoint introducing a +side-channel attack, and/or close the circuit. + + +------------------- + + +1. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf

1 0

[torspec/master] Note potential memory exhaustion DoS.
by isis＠torproject.org 25 Sep '15

25 Sep '15

commit 2b0eb5172f7d3effae6d3aabb2e15efd36926b1d Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Fri Sep 11 17:09:28 2015 -0700 Note potential memory exhaustion DoS. Also clarify terminology and address some formatting issues. --- proposals/xxx-padding-negotiation.txt | 184 ++++++++++++++++++++------------- 1 file changed, 113 insertions(+), 71 deletions(-) diff --git a/proposals/xxx-padding-negotiation.txt b/proposals/xxx-padding-negotiation.txt index 005045a..4202540 100644 --- a/proposals/xxx-padding-negotiation.txt +++ b/proposals/xxx-padding-negotiation.txt @@ -26,19 +26,23 @@ relays, or request that relays not send them padding to conserve bandwidth. This proposal aims to create a mechanism for clients to do both of these. +It also establishes consensus parameters to limit the amount of padding +that relays will send, to prevent custom wingnut clients from requesting +too much. + 2. Link-level padding -Padding is most urgently needed to defend against a malicious or +Padding is most useful if it can defend against a malicious or compromised guard node. However, link-level padding is still useful to defend against an adversary that can merely observe a Guard node -externally. Right now, the only case where link-level padding is known -to defend against any realistic attacker is for low-resolution -netflow-based attacks (see Proposal 251[1]). +externally, such as for low-resolution netflow-based attacks (see +Proposal 251[1]). -In that scenario, the primary mechanism we need is a way for mobile -clients to tell their Guards to stop padding, or to pad less often. The -following Trunnel payloads should cover the needed parameters: +In that scenario, the primary negotiation mechanism we need is a way for +mobile clients to tell their Guards to stop padding, or to pad less +often. The following Trunnel payloads should cover the needed +parameters: const CELL_PADDING_COMMAND_STOP = 1; const CELL_PADDING_COMMAND_START = 2; @@ -49,9 +53,9 @@ following Trunnel payloads should cover the needed parameters: u8 command IN [CELL_PADDING_COMMAND_STOP]; }; - /* This command tells the relay to alter its min and max timeout - range values, and send padding at that rate (resuming if - stopped). */ + /* This command tells the relay to alter its min and max netflow + timeout range values, and send padding at that rate (resuming + if stopped). */ struct cell_padding_start { u8 command IN [CELL_PADDING_COMMAND_START]; @@ -63,25 +67,28 @@ following Trunnel payloads should cover the needed parameters: u16 ito_high_ms; }; -More complicated forms of link padding can still be specified using -the primitives in Section 3, by using "leaky pipe" topology to send -the RELAY commands to the Guard node instead of to later nodes in the -circuit. +More complicated forms of link-level padding can still be specified +using the primitives in Section 3, by using "leaky pipe" topology to +send the RELAY commands to the Guard node instead of to later nodes in +the circuit. 3. End-to-end circuit padding -For end-to-end padding, we need two types of additional features: the +For circuit-level padding, we need two types of additional features: the ability to schedule additional incoming cells at one or more fixed points in the future, and the ability to schedule a statistical distribution of arbitrary padding to overlay on top of non-padding traffic (aka "Adaptive Padding"). In both cases, these messages will be sent from clients to middle nodes -using "leaky pipe" property of the 'recognized' field of RELAY cells, -allowing padding to originate from middle nodes on a circuit in a way -that is not detectable from the Guard node. This same mechanism can also -be used to request padding from the Guard node itself. +using the "leaky pipe" property of the 'recognized' field of RELAY +cells, allowing padding to originate from middle nodes on a circuit in a +way that is not detectable from the Guard node. + +This same mechanism can also be used to request padding from the Guard +node itself, to achieve link-level padding without the additional +overhead requirements on middle nodes. 3.1. Fixed-schedule padding message (RELAY_COMMAND_PADDING_SCHEDULE) @@ -92,7 +99,8 @@ fixed time points in the future to send cells. XXX: 80 timers is a lot to allow every client to create. We may want to have something that checks this structure to ensure it actually schedules no more than N in practice, until we figure out how to -optimize either libevent or timer scheduling/packet delivery. +optimize either libevent or timer scheduling/packet delivery. See also +Section 4.3. The RELAY_COMMAND_PADDING_SCHEDULE body is specified in Trunnel as follows: @@ -121,8 +129,9 @@ with 100 cells in 3*MAX_INT microseconds from the receipt of this cell. The following message is a generalization of the Adaptive Padding defense specified in "Timing Attacks and Defenses"[2]. -The message encodes either one or two state machines, each of which -contain two histograms ("Burst" and "Gap") governing their behavior. +The message encodes either one or two state machines, each of which can +contain one or two histograms ("Burst" and "Gap") governing their +behavior. The "Burst" histogram specifies the delay probabilities for sending a padding packet after the arrival of a non-padding data packet. @@ -141,25 +150,34 @@ allows a client to specify the types of incoming packets that cause the state machine to decide to schedule padding cells (and/or when to cease scheduling them). -Note that our generalization of the Adaptive Padding state machine -actually gives clients full control over the state transition events, -even allowing them to specify a single-state state machine if desired. -See Sections 3.2.1 and 3.2.2 for details. +The client also maintains its own local histogram state machine(s), for +reacting to traffic on its end. + +Note that our generalization of the Adaptive Padding state machine also +gives clients full control over the state transition events, even +allowing them to specify a single-state Burst-only state machine if +desired. See Sections 3.2.1 and 3.2.2 for details. The histograms and the associated state machine packet layout is specified in Trunnel as follows: /* These constants form a bitfield to specify the types of events - * that can cause padding to start or stop from a given state. */ + * that can cause transitions between state machine states. + * + * Note that SENT and RECV are relative to this endpoint. For + * relays, SENT means packets destined towards the client and + * RECV means packets destined towards the relay. On the client, + * SENT means packets destined towards the relay, where as RECV + * means packets destined towards the client. + */ const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_RECV = 1; const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT = 2; const RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT = 4; const RELAY_PADDING_TRANSITION_EVENT_PADDING_RECV = 8; - /* - This encodes a histogram delay distribution representing the - probability of sending a single RELAY_DROP cell after a given - delay in response to a non-padding cell. + /* This payload encodes a histogram delay distribution representing + * the probability of sending a single RELAY_DROP cell after a + * given delay in response to a non-padding cell. */ struct burst_state { u8 histogram_len IN [2..51]; @@ -167,35 +185,31 @@ specified in Trunnel as follows: u32 start_usec; u16 max_sec; - /* - This is a bitfield that specifies which direction and types - of traffic that cause us to abort our scheduled packet and - return to waiting for another event from transition_burst_events. + /* This is a bitfield that specifies which direction and types + * of traffic that cause us to abort our scheduled packet and + * return to waiting for another event from transition_burst_events. */ u8 transition_start_events; - /* - This is a bitfield that specifies which direction and types - of traffic that cause us to remain in the burst state: Cancel the - pending padding packet (if any), and schedule another padding - packet from our histogram. + /* This is a bitfield that specifies which direction and types + * of traffic that cause us to remain in the burst state: Cancel the + * pending padding packet (if any), and schedule another padding + * packet from our histogram. */ u8 transition_reschedule_events; - /* - This is a bitfield that specifies which direction and types - of traffic that cause us to transition to the Gap state. - */ + /* This is a bitfield that specifies which direction and types + * of traffic that cause us to transition to the Gap state. */ u8 transition_gap_events; - /* Should we remove tokens from the histogram as packets are sent? */ + /* If true, remove tokens from the histogram upon padding and + * non-padding activity. */ u8 remove_toks IN [0,1]; }; - /* - This histogram encodes a delay distribution representing the - probability of sending a single additional padding packet after - sending a padding packet that originated at this hop. + /* This histogram encodes a delay distribution representing the + * probability of sending a single additional padding packet after + * sending a padding packet that originated at this hop. */ struct gap_state { u8 histogram_len IN [2..51]; @@ -204,31 +218,31 @@ specified in Trunnel as follows: u16 max_sec; /* This is a bitfield which specifies which direction and types - of traffic should cause us to transition back to the start - state (ie: abort scheduling packets completely). */ + * of traffic should cause us to transition back to the start + * state (ie: abort scheduling packets completely). */ u8 transition_start_events; /* This is a bitfield which specifies which direction and types - of traffic should cause us to transition back to the burst - state (and schedule a packet from the burst histogram). */ + * of traffic should cause us to transition back to the burst + * state (and schedule a packet from the burst histogram). */ u8 transition_burst_events; - /* - This is a bitfield that specifies which direction and types - of traffic that cause us to remain in the gap state: Cancel the - pending padding packet (if any), and schedule another padding - packet from our histogram. + /* This is a bitfield that specifies which direction and types + * of traffic that cause us to remain in the gap state: Cancel the + * pending padding packet (if any), and schedule another padding + * packet from our histogram. */ u8 transition_reschedule_events; - /* Should we remove tokens from the histogram as packets are sent? */ + /* If true, remove tokens from the histogram upon padding and + non-padding activity. */ u8 remove_toks IN [0,1]; }; struct adaptive_padding_machine { /* This is a bitfield which specifies which direction and types - of traffic should cause us to transition to the burst - state (and schedule a packet from the burst histogram). */ + * of traffic should cause us to transition to the burst + * state (and schedule a packet from the burst histogram). */ u8 transition_burst_events; struct burst_state burst; @@ -236,7 +250,7 @@ specified in Trunnel as follows: }; /* This is the full payload of a RELAY_COMMAND_PADDING_ADAPTIVE - cell. */ + * cell. */ struct relay_command_padding_adaptive { u8 num_machines IN [1,2]; @@ -307,16 +321,24 @@ single-state machine if desired. Clients are expected to maintain their own local version of the state machines, for reacting to their own locally generated traffic, in -addition to sending one or more state machines to the middle relay. +addition to sending one or more state machines to the middle relay. The +histograms that the client uses locally will differ from the ones it +sends to the upstream relay. -The histograms that the client uses locally will likely differ from the -ones it sends to the upstream relay. +On the client, the "SENT" direction means packets destined towards the +upstream, where as "RECV" means packets destined towards the client. +However, on the relay, the "SENT" direction means packets destined +towards the client, where as "RECV" means packets destined towards the +relay. 3.2.2. The original Adaptive Padding algorithm As we have noted, the state machines above represent a generalization of the original Adaptive Padding algorithm. To implement the original -behavior, the following flags should be set: +behavior, the following flags should be set in both the client and +the relay state machines: + + num_machines = 1; machines[0].transition_burst_events = RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT; @@ -338,6 +360,10 @@ The rest of the transition fields would be 0. Adding additional transition flags will either increase or decrease the amount of padding sent, depending on their placement. +The second machine slot is provided in the event that it proves useful +to have separate state machines reacting to both sent and received +traffic. + 3.2.3. Histogram decoding/representation Each of the histograms' fields represent a probability distribution that @@ -413,11 +439,18 @@ Actual optimal histogram and state transition construction for different traffic types is expected to be a topic for further research. Intuitively, the burst state is used to detect when the line is idle -(and should therefore have few or no tokens in low histogram bins), and -the gap state is used to fill in otherwise idle periods with artificial +(and should therefore have few or no tokens in low histogram bins). The +lack of tokens in the low histogram bins causes the system to remain in +the burst state until the actual application traffic either slows, +stalls, or has a gap. + +The gap state is used to fill in otherwise idle periods with artificial payloads from the server (and should have many tokens in low bins, and -possibly some also at higher bins). However, more complicated -interactions are also possible. +possibly some also at higher bins). + +It should be noted that due to our generalization of these states and +their transition possibilities, more complicated interactions are also +possible. 4. Security considerations and mitigations @@ -425,7 +458,7 @@ interactions are also possible. The risks from this proposal are primarily DoS/resource exhaustion, and side channels. -4.1. Traffic handling +4.1. Rate limiting Fully client-requested padding introduces a vector for resource amplification attacks and general network overload due to @@ -509,6 +542,15 @@ rather than from the expected interior node, clients should alert the user of the possibility of that circuit endpoint introducing a side-channel attack, and/or close the circuit. +4.5 Memory exhaustion + +Because interior nodes do not have information on the current circuits +SENDME windows, it is possible for malicious clients to consume the +buffers of relays by specifying padding, and then not reading from the +associated circuits. + +XXX: This is bad. We need to add padding-level flow control windows :( + ------------------- 1. https://gitweb.torproject.org/torspec.git/tree/proposals/251-netflow-paddin…

1 0

[torspec/master] Update proposal based on Teor's comments.
by isis＠torproject.org 25 Sep '15

25 Sep '15

commit 69c95087851a09602034b6614a0cc0cfa53f03a9 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Sun Sep 13 18:39:32 2015 -0700 Update proposal based on Teor's comments. Changes: * A zero machines.transition_burst_events means an immediate transition to the burst state. * Added RELAY_PADDING_TRANSITION_EVENT_BINS_EMPTY to allow a state transition when the bins become empty. * Change remove_tokens to allow client to specify removal direction for non-padding packets. * Make RELAY_COMMAND_PADDING_SCHEDULE take a variable number of scheduled times. * Increase and clarify rate limits. --- proposals/xxx-padding-negotiation.txt | 62 ++++++++++++++++++++++++--------- 1 file changed, 45 insertions(+), 17 deletions(-) diff --git a/proposals/xxx-padding-negotiation.txt b/proposals/xxx-padding-negotiation.txt index 0292f22..b7d4e75 100644 --- a/proposals/xxx-padding-negotiation.txt +++ b/proposals/xxx-padding-negotiation.txt @@ -106,11 +106,13 @@ The RELAY_COMMAND_PADDING_SCHEDULE body is specified in Trunnel as follows: struct relay_padding_schedule { + u8 schedule_length IN [1..80]; + /* Number of microseconds before sending cells (cumulative) */ - u32 when_send[80]; + u32 when_send[schedule_length]; /* Number of cells to send at time point sum(when_send[0..i]) */ - u16 num_cells[80]; + u16 num_cells[schedule_length]; /* Adaptivity: If 1, and server-originating cells arrive before the next when_send time, then decrement the next non-zero when_send @@ -124,6 +126,10 @@ other words, sending a cell with when_send = [MAX_INT, MAX_INT, MAX_INT, 0...] and num_cells = [0, 0, 100, 0...] would cause the relay to reply with 100 cells in 3*MAX_INT microseconds from the receipt of this cell. +This scheduled padding is non-periodic. For any forms of periodic +padding, implementations should use the RELAY_COMMAND_PADDING_ADAPTIVE +cell from Section 3.2 instead. + 3.2. Adaptive Padding message (RELAY_COMMAND_PADDING_ADAPTIVE) The following message is a generalization of the Adaptive Padding @@ -175,6 +181,13 @@ specified in Trunnel as follows: const RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT = 4; const RELAY_PADDING_TRANSITION_EVENT_PADDING_RECV = 8; const RELAY_PADDING_TRANSITION_EVENT_INFINITY = 16; + const RELAY_PADDING_TRANSITION_EVENT_BINS_EMPTY = 32; + + /* Token Removal rules. Enum, not bitfield. */ + const RELAY_PADDING_REMOVE_NO_TOKENS = 0; + const RELAY_PADDING_REMOVE_LOWER_TOKENS = 1; + const RELAY_PADDING_REMOVE_HIGHER_TOKENS = 2; + const RELAY_PADDING_REMOVE_CLOSEST_TOKENS = 3; /* This payload encodes a histogram delay distribution representing * the probability of sending a single RELAY_DROP cell after a @@ -205,7 +218,7 @@ specified in Trunnel as follows: /* If true, remove tokens from the histogram upon padding and * non-padding activity. */ - u8 remove_toks IN [0,1]; + u8 remove_tokens IN [0..3]; }; /* This histogram encodes a delay distribution representing the @@ -237,7 +250,7 @@ specified in Trunnel as follows: /* If true, remove tokens from the histogram upon padding and non-padding activity. */ - u8 remove_toks IN [0,1]; + u8 remove_tokens IN [0..3]; }; struct adaptive_padding_machine { @@ -253,6 +266,9 @@ specified in Trunnel as follows: /* This is the full payload of a RELAY_COMMAND_PADDING_ADAPTIVE * cell. */ struct relay_command_padding_adaptive { + /* Technically, we could allow more than 2 state machines here, + but only two are sure to fit. More than 2 seems excessive + anyway. */ u8 num_machines IN [1,2]; struct adaptive_padding_machine machines[num_machines]; @@ -268,7 +284,9 @@ Each state machine has a Start state S, a Burst state B, and a Gap state G. The state machine starts idle (state S) until it receives a packet of a -type that matches the bitmask in machines[i].transition_burst_events. +type that matches the bitmask in machines[i].transition_burst_events. If +machines[i].transition_burst_events is 0, transition to the burst state +happens immediately. This causes it to enter burst mode (state B), in which a delay t is sampled from the Burst histogram, and a timer is scheduled to count down @@ -382,7 +400,7 @@ n = histogram_len-1 INFINITY_BIN = n a[0] = start_usec; -b[0] = start_usec + max_sec*USEC_PER_SEC/2^(n); +b[0] = start_usec + max_sec*USEC_PER_SEC/2^(n-1); for(i=1; i < n; i++) { a[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i) b[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i-1) @@ -416,18 +434,25 @@ accuracy to larger timescales (where accuracy is not as important). 3.2.4. Token removal and refill -If the remove_tok field is set to true for a given state's histogram, -then whenever a padding packet is sent, the corresponding histogram -bin's token count is decremented by one. +If the remove_tokens field is set to a non-zero value for a given +state's histogram, then whenever a padding packet is sent, the +corresponding histogram bin's token count is decremented by one. If a packet matching the current state's transition_reschedule_events bitmask arrives from the server before the chosen padding timer expires, -then a token is removed from the nearest non-empty bin corresponding to +then a token is removed from a non-empty bin corresponding to the delay since the last packet was sent, and the padding packet timer is re-sampled from the histogram. +The three enums for the remove_tokens field govern if we take the token +out of the nearest lower non-empty bin, the nearest higher non-empty +bin, or simply the closest non-empty bin. + If the entire histogram becomes empty, it is then refilled to the -original values. +original values. This refill happens prior to any state transitions due +to RELAY_PADDING_TRANSITION_EVENT_BINS_EMPTY (but obviously does not +prevent the transition from happening). + 3.2.5. Constructing the histograms @@ -484,18 +509,19 @@ padding requests should be ignored: (expressed as a percent) to allow on a circuit before ceasing to pad. Ex: 75 means 75 padding packets for every 100 non-padding packets. - - Default: 100 + - Default: 120 * CircuitPaddingLimitCount - The number of padding cells that must be transmitted before the ratio limit is applied. - - Default: 500 + - Default: 5000 * CircuitPaddingLimitTime - The time period in seconds over which to count padding cells for - application of the ratio limit. + application of the ratio limit (ie: reset the limit count this + often). - Default: 60 XXX: Should we cap padding at these rates, or fully disable it once -they're crossed? +they're crossed? Probably cap? Proposal 251 introduced extra-info accounting at relays to enable us to measure the total overhead of both link and circuit-level padding at @@ -548,16 +574,18 @@ rather than from the expected interior node, clients should alert the user of the possibility of that circuit endpoint introducing a side-channel attack, and/or close the circuit. -4.5 Memory exhaustion +4.5. Memory exhaustion Because interior nodes do not have information on the current circuits SENDME windows, it is possible for malicious clients to consume the buffers of relays by specifying padding, and then not reading from the associated circuits. -XXX: This is bad. We need to add padding-level flow control windows :( +XXX: Tor already had a few flow-control related DoS's in the past[3]. Is +that defense sufficient here without any mods? It seems like it may be! ------------------- 1. https://gitweb.torproject.org/torspec.git/tree/proposals/251-netflow-paddin… 2. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf +3. https://blog.torproject.org/blog/new-tor-denial-service-attacks-and-defenses

1 0

[translation/tor-messenger-ircproperties_completed] Update translations for tor-messenger-ircproperties_completed
by translation＠torproject.org 25 Sep '15

25 Sep '15

commit 5f8a59696807c1cb76547374f491d938c443cc61 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Sep 25 07:16:31 2015 +0000 Update translations for tor-messenger-ircproperties_completed --- id/irc.properties | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) diff --git a/id/irc.properties b/id/irc.properties new file mode 100644 index 0000000..4fc394a --- /dev/null +++ b/id/irc.properties @@ -0,0 +1,205 @@ +# This Source Code Form is subject to the terms of the Mozilla Public +# License, v. 2.0. If a copy of the MPL was not distributed with this +# file, You can obtain one at http://mozilla.org/MPL/2.0/. + +# LOCALIZATION NOTE (irc.usernameHint): +# This is displayed inside the accountUsernameInfoWithDescription +# string defined in imAccounts.properties when the user is +# configuring an IRC account. +irc.usernameHint=nick + +# LOCALIZATION NOTE (connection.error.*): +# These will show in the account manager if the account is +# disconnected because of an error. +connection.error.lost=Sambungan dengan server terputus +connection.error.timeOut=Sambungan melewati batas waktu +connection.error.invalidUsername=%S bukan nama pengguna yang diizinkan +connection.error.invalidPassword=Sandi server tidak valid +connection.error.passwordRequired=Membutuhkan sandi + +# LOCALIZATION NOTE (joinChat.*): +# These show up on the join chat menu. An underscore is for the access key. +joinChat.channel=Sa_luran +joinChat.password=_Sandi + +# LOCALIZATION NOTE (options.*): +# These are the protocol specific options shown in the account manager and +# account wizard windows. +options.server=Server +options.port=Port +options.ssl=Gunakan SSL +options.encoding=Set Karakter +options.quitMessage=Pesan keluar +options.partMessage=Bagian pesan +options.showServerTab=Tampilkan pesan dari server +options.alternateNicks=Nick alternatif + +# LOCALIZATION NOTE (ctcp.version): +# %1$S is the nickname of the user whose version was requested. +# %2$S is the version response from the client. +ctcp.version=%1$S menggunakan "%2$S". +# LOCALIZATION NOTE (ctcp.time): +# %1$S is the nickname of the user whose time was requested. +# %2$S is the time response. +ctcp.time=Waktu untuk %1$S adalah %2$S. + +# LOCALZIATION NOTE (command.*): +# These are the help messages for each command, the %S is the command name +# Each command first gives the parameter it accepts and then a description of +# the command. +command.action=%S <action to perform>: melakukan tindakan +command.ctcp=%S <nick> <msg>: mengirim CTCP ke nama samaran. +command.chanserv=%S <command>: mengirim perintah ke ChanSrv. +command.deop=%S <nick1>[,<nick2>]*: Membuang status operator kanal seseorang. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.devoice=%S <nick1>[,<nick2>]*: Membuang status kanal suara seseorang, mencegahnya berbicara jika kanal dimoderasi (+m). Anda harus menjadi operator kanal untuk melakukan hal ini. +command.invite2=%S <nick>[ <nick>]* [<channel>]: mengundang satu atau lebih nama samaran untuk bergabung denganmu di kanal ini, atau bergabung dengan kanal tertentu. +command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Memasukan satu atau lebih kanal, optional menyediakan kunci kanal masing-masing jika dibutuhkan. +command.kick=%S <nick> [<message>]: Menghapus seseorang dari kanal. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.list=%S: Menampilkan daftar ruang ngobrol di jaringan. Awas, beberapa server mungkin memutus koneksimu jika melakukan hal ini. +command.memoserv=%S <command>: mengirim perintah ke MemoServ. +command.modeUser=%S (+|-)<new mode> [<nick>]: membuat atau merubah moda pemakai. +command.modeChannel=%S <channel>[ (+|-)<new mode> [<parameter>][,<parameter>]*]: Mengambil, menyusun atau merombak moda kanal. +command.msg=%S <nick> <message>: Mengirim pesan pribadi kepada pengguna (sebagai kebalikan dari pesan ke kanal) +command.nick=%S <new nickname>: Merubah nama samaran. +command.nickserv=%S <command>: Mengirim perintah ke NickServ. +command.notice=%S <target> <message>: Mengirim pemberitahuan ke pengguna atau kanal. +command.op=%S <nick1>[,<nick2>]*: Memberi status operator kanal pada seseorang. Anda harus menjadi operator kanal agar bisa melakukan hal ini. +command.operserv=%S <command>: mengirim satu perintah ke OperServ. +command.part=%S [message]: Meninggalkan kanal ini dengan pesan pilihan. +command.ping=%S [<nick>]: Menanyakan berapa banyak pengguna (atau server jika tidak ada pengguna) yang tertinggal, +command.quit=%S <message>: Memutus koneksi server, dengan pilihan pesan. +command.quote=%S <command>: Mengirim pesan belum terolah ke server. +command.time=%S: Menampilkan waktu setempat saat ini di server IRC. +command.topic=%S [<new topic>]: Membuat judul kanal. +command.umode=%S (+|-)<new mode>: membuat atau merubah moda pengguna. +command.version=%S <nick>: Meminta versi klien pengguna. +command.voice=%S <nick1>[,<nick2>]*: Memberi status kanal suara pada seseorang. Anda harus menjadi operator kanal untuk dapat melakukan hal ini. +command.whois2=%S [<nick>]: Meminta informasi pengguna. + +# LOCALIZATION NOTE (message.*): +# These are shown as system messages in the conversation. +# %1$S is the nick and %2$S is the nick and host of the user who joined. +message.join=%1$S [%2$S] masuk ke ruang. +message.rejoined=Anda telah bergabung kembali. +# %1$S is the nick of who kicked you. +# %2$S is message.kicked.reason, if a kick message was given. +message.kicked.you=Anda telah dikeluarkan oleh %1$S%2$S. +# %1$S is the nick that is kicked, %2$S the nick of the person who kicked +# %1$S. %3$S is message.kicked.reason, if a kick message was given. +message.kicked=%1$S telah dikeluarkan oleh %2$S%3$S. +# %S is the kick message +message.kicked.reason=: %S +# %1$S is the new mode, %2$S is the nickname of the user whose mode +# was changed, and %3$S is who set the mode. +message.usermode=Mode %1$S untuk %2$S ditetapkan oleh %3$S. +# %1$S is the new channel mode and %2$S is who set the mode. +message.channelmode=Mode saluran %1$S ditetapkan oleh %2$S. +# %S is the user's mode. +message.yourmode=Mode Anda adalah %S. +# Could not change the nickname. %S is the user's nick. +message.nick.fail=Nickname tidak dapat digunakan. Nick Anda masih %S. +# The parameter is the message.parted.reason, if a part message is given. +message.parted.you=Anda sudah keluar (Bagian%1$S). +# %1$S is the user's nick, %2$S is message.parted.reason, if a part message is given. +message.parted=%1$S sudah keluar (Bagian%2$S). +# %S is the part message supplied by the user. +message.parted.reason=: %S +# %1$S is the user's nick, %2$S is message.quit2 if a quit message is given. +message.quit=%1$S sudah keluar (Keluar%2$S). +# The parameter is the quit message given by the user. +message.quit2=: %S +# %1$S is the nickname of the user that invited us, %2$S is the conversation +# name. +message.inviteReceived=%1$S telah mengundang Anda ke %2$S. +# %1$S is the nickname of the invited user, %2$S is the conversation name +# they were invited to. +message.invited=%1$S telah dengan sukses diundang ke %2$S. +# %1$S is the nickname of the invited user, %2$S is the conversation name +# they were invited to but are already in +message.alreadyInChannel=%1$S sudah ada di dalam %2$S. +# %S is the nickname of the user who was summoned. +message.summoned=%S telah dipanggil. +# %S is the nickname of the user whose WHOIS information follows this message. +message.whois=Informasi WHOIS untuk %S: +# %1$S is the nickname of the (offline) user whose WHOWAS information follows this message. +message.whowas=%1$S sedang luring. Informasi WHOWAS untuk %1$S: +# %1$S is the entry description (from tooltip.*), %2$S is its value. +message.whoisEntry=\\ua0\\ua0\\ua0\\ua0%1$S: %2$S +# %S is the nickname that is not known to the server. +message.unknownNick=Nickname %S tidak diketahui. +# %1$S is the nickname of the user who changed the mode and %2$S is the new +# channel key (password). +message.channelKeyAdded=%1$S mengubah sandi saluran menjadi %2$S. +message.channelKeyRemoved=%S membuang sandi saluran. +# This will be followed by a list of ban masks. +message.banMasks=Pengguna yang terhubung dari lokasi berikut dicekal dari %S: +message.noBanMasks=Tidak ada lokasi yang dicekal untuk %S. +message.banMaskAdded=Pengguna tersambung dari lokasi %1$S yang telah dicekal oleh %2$S. +message.banMaskRemoved=Pengguna tersambung dari lokasi %1$S yang tidak lagi dicekal oleh %2$S. +# LOCALIZATION NOTE (message.ping): Semi-colon list of plural forms. +# See: http://developer.mozilla.org/en/docs/Localization_and_Plurals +# %1$S is the nickname of the user or the server that was pinged. +# #2 is the delay (in milliseconds). +message.ping=Balasan ping dari %1$S dalam #2 milidetik.;Balasan ping dari %1$S dalam #2 milidetik. + + +# LOCALIZATION NOTE (error.*): +# These are shown as error messages in the conversation or server tab. +# %S is the channel name. +error.noChannel=Tidak ada saluran: %S. +error.tooManyChannels=Tidak dapat bergabung ke %S; Anda telah bergabung dengan terlalu banyak saluran. +# %1$S is your new nick, %2$S is the kill message from the server. +error.nickCollision=Nick sudah dipakai, mengubah nick menjadi %1$S [%2$S]. +error.erroneousNickname=Nickname %S tidak diperbolehkan. +error.banned=Anda dicekal dari server ini. +error.bannedSoon=Anda akan segera dicekal dari server ini. +error.mode.wrongUser=Anda tidak dapat mengubah mode untuk pengguna lainnya. +# %S is the nickname or channel name that isn't available. +error.noSuchNick=%S sedang tidak daring. +error.wasNoSuchNick=Tidak ada nickname: %S +error.noSuchChannel=Tidak ada saluran: %S. +error.unavailable=%S sementara tidak tersedia. +# %S is the channel name. +error.channelBanned=Anda telah dicekal dari %S. +error.cannotSendToChannel=Anda tidak dapat mengirim pesan ke %S. +error.channelFull=Saluran %S sudah penuh. +error.inviteOnly=Anda harus diundang untuk bergabung ke %S. +error.nonUniqueTarget=%S bukan pengguna@hos atau namapendek yang unik atau Anda telah mencoba bergabung ke banyak saluran pada saat yang bersamaan. +error.notChannelOp=Anda bukan operator saluran %S. +error.notChannelOwner=Anda bukan pemilik saluran %S. +error.wrongKey=Tidak dapat bergabung ke %S, sandi saluran tidak valid. +error.sendMessageFailed=Sebuah galat terjadi saat mengirimkan pesan terakhir Anda. Mohon coba lagi ketika koneksi tersambung kembali. +# %1$S is the channel the user tried to join, %2$S is the channel +# he was forwarded to. +error.channelForward=Anda mungkin tidak bergabung ke %1$S, dan secara otomatis dialihkan ke %2$S. + +# LOCALIZATION NOTE (tooltip.*): +# These are the descriptions given in a tooltip with information received +# from a whois response. +# The human readable ("realname") description of the user. +tooltip.realname=Nama +tooltip.server=Terhubung ke +# The username and hostname that the user connects from (usually based on the +# reverse DNS of the user's IP, but often mangled by the server to +# protect users). +tooltip.connectedFrom=Terhubung dari +tooltip.registered=Terdaftar +tooltip.registeredAs=Terdaftar sebagai +tooltip.secure=Menggunakan sambungan aman +# The away message of the user +tooltip.away=Pergi +tooltip.ircOp=Operator IRC +tooltip.bot=Bot +tooltip.lastActivity=Aktivitas terakhir +# %S is the timespan elapsed since the last activity. +tooltip.timespan=%S yang lalu +tooltip.channels=Sedang on + +# %1$S is the server name, %2$S is some generic server information (usually a +# location or the date the user was last seen). +tooltip.serverValue=%1$S (%2$S) + +# LOCALIZATION NOTE (yes, no): +# These are used to turn true/false values into a yes/no response. +yes=Ya +no=Tidak

1 0

[translation/tor-messenger-ircproperties] Update translations for tor-messenger-ircproperties
by translation＠torproject.org 25 Sep '15

25 Sep '15

commit d699995e1d06eedb7132ad7795f541ab9780f4fe Author: Translation commit bot <translation(a)torproject.org> Date: Fri Sep 25 07:16:27 2015 +0000 Update translations for tor-messenger-ircproperties --- id/irc.properties | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/id/irc.properties b/id/irc.properties index 52eae2e..4fc394a 100644 --- a/id/irc.properties +++ b/id/irc.properties @@ -54,27 +54,27 @@ command.deop=%S <nick1>[,<nick2>]*: Membuang status operator kanal s command.devoice=%S <nick1>[,<nick2>]*: Membuang status kanal suara seseorang, mencegahnya berbicara jika kanal dimoderasi (+m). Anda harus menjadi operator kanal untuk melakukan hal ini. command.invite2=%S <nick>[ <nick>]* [<channel>]: mengundang satu atau lebih nama samaran untuk bergabung denganmu di kanal ini, atau bergabung dengan kanal tertentu. command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Memasukan satu atau lebih kanal, optional menyediakan kunci kanal masing-masing jika dibutuhkan. -command.kick=%S <nick> [<message>]: Remove someone from a channel. You must be a channel operator to do this. -command.list=%S: Display a list of chat rooms on the network. Warning, some servers may disconnect you upon doing this. -command.memoserv=%S <command>: Send a command to MemoServ. -command.modeUser=%S (+|-)<new mode> [<nick>]: Set or unset a user's mode. -command.modeChannel=%S <channel>[ (+|-)<new mode> [<parameter>][,<parameter>]*]: Get, set or unset a channel mode. -command.msg=%S <nick> <message>: Send a private message to a user (as opposed to a channel). -command.nick=%S <new nickname>: Change your nickname. -command.nickserv=%S <command>: Send a command to NickServ. -command.notice=%S <target> <message>: Send a notice to a user or channel. -command.op=%S <nick1>[,<nick2>]*: Grant channel operator status to someone. You must be a channel operator to do this. -command.operserv=%S <command>: Send a command to OperServ. -command.part=%S [message]: Leave the current channel with an optional message. -command.ping=%S [<nick>]: Asks how much lag a user (or the server if no user specified) has. -command.quit=%S <message>: Disconnect from the server, with an optional message. -command.quote=%S <command>: Send a raw command to the server. -command.time=%S: Displays the current local time at the IRC server. -command.topic=%S [<new topic>]: Set this channel's topic. -command.umode=%S (+|-)<new mode>: Set or unset a user mode. -command.version=%S <nick>: Request the version of a user's client. -command.voice=%S <nick1>[,<nick2>]*: Grant channel voice status to someone. You must be a channel operator to do this. -command.whois2=%S [<nick>]: Mendapat informasi ke seorang pengguna. +command.kick=%S <nick> [<message>]: Menghapus seseorang dari kanal. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.list=%S: Menampilkan daftar ruang ngobrol di jaringan. Awas, beberapa server mungkin memutus koneksimu jika melakukan hal ini. +command.memoserv=%S <command>: mengirim perintah ke MemoServ. +command.modeUser=%S (+|-)<new mode> [<nick>]: membuat atau merubah moda pemakai. +command.modeChannel=%S <channel>[ (+|-)<new mode> [<parameter>][,<parameter>]*]: Mengambil, menyusun atau merombak moda kanal. +command.msg=%S <nick> <message>: Mengirim pesan pribadi kepada pengguna (sebagai kebalikan dari pesan ke kanal) +command.nick=%S <new nickname>: Merubah nama samaran. +command.nickserv=%S <command>: Mengirim perintah ke NickServ. +command.notice=%S <target> <message>: Mengirim pemberitahuan ke pengguna atau kanal. +command.op=%S <nick1>[,<nick2>]*: Memberi status operator kanal pada seseorang. Anda harus menjadi operator kanal agar bisa melakukan hal ini. +command.operserv=%S <command>: mengirim satu perintah ke OperServ. +command.part=%S [message]: Meninggalkan kanal ini dengan pesan pilihan. +command.ping=%S [<nick>]: Menanyakan berapa banyak pengguna (atau server jika tidak ada pengguna) yang tertinggal, +command.quit=%S <message>: Memutus koneksi server, dengan pilihan pesan. +command.quote=%S <command>: Mengirim pesan belum terolah ke server. +command.time=%S: Menampilkan waktu setempat saat ini di server IRC. +command.topic=%S [<new topic>]: Membuat judul kanal. +command.umode=%S (+|-)<new mode>: membuat atau merubah moda pengguna. +command.version=%S <nick>: Meminta versi klien pengguna. +command.voice=%S <nick1>[,<nick2>]*: Memberi status kanal suara pada seseorang. Anda harus menjadi operator kanal untuk dapat melakukan hal ini. +command.whois2=%S [<nick>]: Meminta informasi pengguna. # LOCALIZATION NOTE (message.*): # These are shown as system messages in the conversation.

1 0

[translation/tor-messenger-ircproperties] Update translations for tor-messenger-ircproperties
by translation＠torproject.org 25 Sep '15

25 Sep '15

commit ba030347219d92da5782694889f7bf8ec29fef23 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Sep 25 06:46:38 2015 +0000 Update translations for tor-messenger-ircproperties --- id/irc.properties | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/id/irc.properties b/id/irc.properties index cfbd862..52eae2e 100644 --- a/id/irc.properties +++ b/id/irc.properties @@ -47,13 +47,13 @@ ctcp.time=Waktu untuk %1$S adalah %2$S. # These are the help messages for each command, the %S is the command name # Each command first gives the parameter it accepts and then a description of # the command. -command.action=%S <action to perform>: Perform an action. -command.ctcp=%S <nick> <msg>: Sends a CTCP message to the nick. -command.chanserv=%S <command>: Send a command to ChanServ. -command.deop=%S <nick1>[,<nick2>]*: Remove channel operator status from someone. You must be a channel operator to do this. -command.devoice=%S <nick1>[,<nick2>]*: Remove channel voice status from someone, preventing them from speaking if the channel is moderated (+m). You must be a channel operator to do this. -command.invite2=%S <nick>[ <nick>]* [<channel>]: Invite one or more nicks to join you in the current channel, or to join the specified channel. -command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Enter one or more channels, optionally providing a channel key for each if needed. +command.action=%S <action to perform>: melakukan tindakan +command.ctcp=%S <nick> <msg>: mengirim CTCP ke nama samaran. +command.chanserv=%S <command>: mengirim perintah ke ChanSrv. +command.deop=%S <nick1>[,<nick2>]*: Membuang status operator kanal seseorang. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.devoice=%S <nick1>[,<nick2>]*: Membuang status kanal suara seseorang, mencegahnya berbicara jika kanal dimoderasi (+m). Anda harus menjadi operator kanal untuk melakukan hal ini. +command.invite2=%S <nick>[ <nick>]* [<channel>]: mengundang satu atau lebih nama samaran untuk bergabung denganmu di kanal ini, atau bergabung dengan kanal tertentu. +command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Memasukan satu atau lebih kanal, optional menyediakan kunci kanal masing-masing jika dibutuhkan. command.kick=%S <nick> [<message>]: Remove someone from a channel. You must be a channel operator to do this. command.list=%S: Display a list of chat rooms on the network. Warning, some servers may disconnect you upon doing this. command.memoserv=%S <command>: Send a command to MemoServ.

1 0

[tor/master] Add test-network.sh to EXTRA_DIST
by nickm＠torproject.org 24 Sep '15

24 Sep '15

commit 7b1d2726e4eeebb2b92f7983da455b81f55c4cc8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 19:38:50 2015 -0400 Add test-network.sh to EXTRA_DIST --- src/test/include.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/test/include.am b/src/test/include.am index 9f142d5..a37fe23 100644 --- a/src/test/include.am +++ b/src/test/include.am @@ -194,4 +194,5 @@ EXTRA_DIST += \ src/test/zero_length_keys.sh \ src/test/test_keygen.sh \ src/test/test_zero_length_keys.sh \ - src/test/test_ntor.sh src/test/test_bt.sh + src/test/test_ntor.sh src/test/test_bt.sh \ + src/test/test-network.sh

1 0

[tor/master] Make our digest-mismatch warnings a touch better
by nickm＠torproject.org 24 Sep '15

24 Sep '15

commit 8d6bb3a5595cd4b9dbc175a43b93e8d7ca332635 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 17:45:29 2015 -0400 Make our digest-mismatch warnings a touch better --- src/or/routerlist.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 8bd8039..03729bd 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -4964,6 +4964,12 @@ routerinfo_incompatible_with_extrainfo(const routerinfo_t *ri, goto err; } + if (!digest256_matches && !digest_matches) { + if (msg) *msg = "Neither digest256 or digest matched " + "digest from routerdesc"; + goto err; + } + if (!digest256_matches) { if (msg) *msg = "Extrainfo digest did not match digest256 from routerdesc"; goto err; /* Digest doesn't match declared value. */

1 0

[tor/master] Put braces around reject-lines for IPv6 addrs
by nickm＠torproject.org 24 Sep '15

24 Sep '15

commit e62fe2f02d38958516026ce9042c3d1542b6c0a6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 16:51:25 2015 -0400 Put braces around reject-lines for IPv6 addrs Fixes bug 17149; bug not in any released Tor. --- src/or/policies.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/or/policies.c b/src/or/policies.c index 86eedd2..9c858ec 100644 --- a/src/or/policies.c +++ b/src/or/policies.c @@ -1037,7 +1037,7 @@ policies_parse_exit_policy_internal(config_line_t *cfg, smartlist_t **dest, "address", fmt_addr(ipv6_local_address)); } else { char buf6[POLICY_BUF_LEN]; - tor_snprintf(buf6, sizeof(buf6), "reject %s:*", + tor_snprintf(buf6, sizeof(buf6), "reject [%s]:*", fmt_addr(ipv6_local_address)); append_exit_policy_string(dest, buf6); log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for our " @@ -1075,7 +1075,7 @@ policies_parse_exit_policy_internal(config_line_t *cfg, smartlist_t **dest, * address */ if (ipv6_local_address == NULL || !tor_addr_eq(ipv6_local_address, a)) { - tor_snprintf(bufif, sizeof(bufif), "reject6 %s:*", + tor_snprintf(bufif, sizeof(bufif), "reject6 [%s]:*", fmt_addr(a)); append_exit_policy_string(dest, bufif); log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for a local "

1 0

[tor/master] Merge branch 'bug17149'
by nickm＠torproject.org 24 Sep '15

24 Sep '15

commit 9febbf0451ecd60fb78c1b4e5632d09bf3403fcc Merge: 4b2ae5a e62fe2f Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 17:19:21 2015 -0400 Merge branch 'bug17149' src/or/policies.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits September 2015